質問

すべて同時に処理するビデオストリームのチャネルが100以上あります。ビデオをキャプチャし、サムネイルを生成し、Webサービスとして提供する必要があります。サムネイルの生成には、JMFなどを使用できます(生成およびアクセスする方法について話している別の投稿があることに気付きました:大きな画像ファイルからの高品質のサムネイル)。しかし、私の懸念は次のとおりです。 Java EE EJBまたは単にJava SEスレッド?短所と長所は何ですか? EJBを使用して水平方向にスケーリングする方法

私はスケーラビリティの問題にそれほど精通していません。あなたの親切な提案に本当に感謝しています。

ありがとう。

役に立ちましたか?

解決

同意します...スレッドは、単一マシンでのスケーリングに役立ちます。異なるマシンに拡張したい場合は、Terracottaを使用します。

他のヒント

Java SEスレッドは単一のマシンでのスケーリングに役立ちますが、異なるマシン間で水平方向にスケーリングする必要がある場合、EJBがそれを実現する1つの方法になります。

それが私なら、おそらく必要な数のマシンで実行できる別のWebサービス層にファームアウトし、それらのマシン間で負荷を分散します。

この状況でEJBを使用する理由はわかりません。ボトルネックはどこにあるのかを自問する必要があります。私の賭けはビデオ処理になります。アプリケーションのプロファイルを作成し、処理中よりもタイムスライスの待機に多くの時間を費やす前に、処理できるスレッドの数を確認します。ある時点の後、スレッドを追加してもスループットは追加されません。その時点で、特定のスループットを維持するために必要なマシンの数とマシンの数がわかります。マシン全体でどのようにスケーリングするかは別の質問です。

これらは2つの明確な問題です。

サウンドのキャプチャ/処理は、レンダリングファームのような問題のようです。これらは水平方向に簡単にスケーリングされます。ほとんどのソリューションにはジョブのキューが含まれますが、Javaでこれを行う必要さえありません。好きなシンプルなソリューションを見つけてください。 " render farm ffmpeg"またはそのようなものはGoogleで結果をもたらすはずです。

「Webサービスとしてのサービス」の部分は未定義です。これらのビデオをアクセス可能にする場合は、HTTPサーバーに配置するだけで済みます。負荷分散が容易で、水平方向にスケーラブルになります。ストレージ速度またはネットワーク帯域幅が最初のボトルネックになるでしょう。

正式なJ2EEスタックを残します。

むしろ、コンシューマとしてY個のスレッドを実行しているX個のJVMとJMSを通信する素敵なメッセージキュー。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top