Как масштабироваться в Java

У меня есть более 100 каналов видеопотоков для одновременной обработки. Мне нужно захватить видео, создать эскизы и предоставить их в качестве веб-службы. Для создания эскиза я могу использовать JMF и т. Д. (Я заметил, что есть еще один пост, в котором говорится о том, как создавать и получать доступ: миниатюры лучшего качества из больших файлов изображений). Но меня беспокоит: как масштабировать? Java EE EJB или просто потоки Java SE? Какие минусы и плюсы? Как масштабировать по горизонтали с помощью EJB?

Я не так хорошо знаком с проблемой масштабируемости, и я очень ценю ваши добрые предложения.

Спасибо.


java video-processing
person Lily    schedule 16.06.2009    source источник
comment
Не существует единого ответа на вопрос о масштабируемости, равно как и простого способа обеспечить его соблюдение. Это все равно, что спросить, как мне добиться того, чтобы я разрабатывал хорошую программу?   -  person matt b    schedule 16.06.2009
comment
Тогда как я могу поставить заголовок более правильным образом? Я не эксперт в этой области, и спасибо за ваши предложения.   -  person Lily    schedule 16.06.2009

Ответы (5)


arrow_upward
4
arrow_downward

Согласитесь... потоки должны помочь масштабироваться на одной машине. Если вы хотите масштабироваться на разных машинах — используйте Terracotta.

person Eugene Ryzhikov    schedule 16.06.2009

arrow_upward
0
arrow_downward

Потоки Java SE могут помочь вам масштабироваться на одной машине, но если вам нужно горизонтально масштабироваться на разных машинах, EJB будет одним из способов сделать это.

Если бы это был я, я бы, вероятно, выделил отдельный уровень веб-службы, который мог бы работать на любом количестве машин, а затем распределил нагрузку между этими машинами.

person Spike Williams    schedule 16.06.2009
comment
Уильямс, не могли бы вы подробнее объяснить, как это передать отдельному уровню веб-сервиса, спасибо. - person Lily; 16.06.2009
comment
Выясните, какую наименьшую единицу работы вы бы выполняли в рамках одного потока. Создайте веб-сервис вокруг этой единицы работы. Этот сервис можно было бы запускать параллельно на нескольких разных машинах, и перед ним должен быть балансировщик нагрузки для равномерного распределения работы. Перед этим у вашего основного веб-сервиса будет задача разделить работу на однозадачные подразделения и перенаправить эти блоки в однозадачный сервис через балансировщик нагрузки. Он будет собирать результаты и отправлять их обратно запрашивающему клиенту. - person Spike Williams; 17.06.2009

arrow_upward
0
arrow_downward

Я не вижу причин использовать EJB в этой ситуации. Вы должны спросить себя, где узкое место. Моя ставка будет на обработку видео. Я бы профилировал ваше приложение и посмотрел, сколько потоков может быть обработано, прежде чем они потратят больше времени на ожидание своего кванта времени, чем на обработку. После определенного момента добавление большего количества потоков не увеличит пропускную способность. В этот момент вы знаете, что будет делать машина и сколько машин вам потребуется для поддержания определенной пропускной способности. Как вы масштабируете машину — это другой вопрос.

person Javamann    schedule 16.06.2009
comment
Это очень хороший момент! Поэкспериментируйте, прежде чем покупать оборудование, это кажется лучшим решением. - person Lily; 16.06.2009

arrow_upward
0
arrow_downward

Это две разные проблемы.

Захват/обработка звучит как проблема с фермой рендеринга. Они тривиально масштабируются по горизонтали. Большинство решений включают в себя очередь заданий, вам даже не нужно делать это в Java; просто найдите простое решение, которое вам нравится. «рендеринг фермы ffmpeg» или что-то в этом роде должно давать результаты в Google.

Ваша часть «работа в качестве веб-сервиса» несколько не определена. Если вы хотите, чтобы эти видео были доступны, вам может потребоваться просто разместить их на HTTP-сервере — их можно легко сбалансировать по нагрузке и, следовательно, горизонтально масштабировать — скорость хранения или пропускная способность сети, вероятно, будут вашими первыми узкими местами.

person alex    schedule 16.06.2009

arrow_upward
0
arrow_downward

Оставьте формальный стек J2EE позади.

Скорее, хорошая очередь сообщений, которая общается с JMS с X количеством JVM, выполняющим Y количество потоков в качестве потребителей.

person Jé Queue    schedule 02.11.2009