100以上のチャンネルのビデオストリームをすべて同時に処理する必要があります。ビデオをキャプチャし、サムネイルを生成して、それらをWebサービスとして提供する必要があります。サムネイルの生成には、JMFなどを使用できます（生成とアクセスの方法について話している別の投稿があることに気付きました：より大きな画像ファイルからのより良い品質のサムネイル）。しかし、私の懸念は、どのようにスケーリングするかということです。Java EE EJBまたは単にJavaSEスレッド？短所と長所は何ですか？EJBを使用して水平方向にスケーリングするにはどうすればよいですか？
私はスケーラビリティの問題にそれほど精通していません。あなたの親切な提案に本当に感謝しています。
ありがとう。
同意する...スレッドは、単一のマシンでのスケーリングに役立つはずです。異なるマシン間でスケーリングする場合は、Terracottaを使用してください。
正式なJ2EEスタックは残しておきます。
むしろ、コンシューマーとしてY個のスレッドを実行しているX個のJVMとJMSを通信する優れたメッセージキュー。
Java SEスレッドは、単一のマシンでのスケーリングに役立ちますが、異なるマシン間で水平方向にスケーリングする必要がある場合は、EJBがそれを行う1つの方法になります。
私の場合は、必要な数のマシンで実行できる別のWebサービス層にファームアウトして、それらのマシン間の負荷分散を行うことになるでしょう。
この状況でEJBを使用する理由はわかりません。ボトルネックはどこにあるのかを自問する必要があります。私の賭けはビデオ処理になります。アプリケーションのプロファイルを作成し、処理中よりもタイムスライスの待機に多くの時間を費やす前に、処理できるスレッドの数を確認します。ある時点以降、スレッドを追加してもスループットは増加しません。その時点で、マシンが何を実行し、特定のスループットを維持するために必要なマシンの数がわかります。マシン全体でどのようにスケーリングするかは別の問題です。
これらは2つの明確な問題です。
キャプチャ/処理は、レンダーファームのような問題のように聞こえます。それらは水平方向に自明にスケーリングされます。ほとんどのソリューションにはジョブのキューが含まれ、Javaでこれを行う必要はありません。好きな簡単な解決策を見つけてください。「レンダーファームffmpeg」またはそのようなものはGoogleで結果をもたらすはずです。
「Webサービスとして機能する」部分はやや未定義です。これらのビデオにアクセスできるようにする場合は、HTTPサーバーに配置するだけでよい場合があります。これらのビデオは簡単に負荷分散できるため、水平方向にスケーラブルです。ストレージ速度またはネットワーク帯域幅が最初のボトルネックになる可能性があります。