私は100以上のチャンネルのビデオストリームを同時に処理します。私は、ビデオをキャプチャし、サムネイルを生成し、それらをWebサービスとして提供する必要があります。サムネイルの生成については、JMFなどを使用することができます（私は、生成およびアクセスの方法について話している別の投稿があることに気づきました：better quality thumbnails from larger image files）。しかし、私の懸念は、どのようにスケールするのですか？ Java EE EJBまたは単にJava SEスレッド？短所と賛否は何ですか？ EJBを使って水平方向にスケールする方法は？Javaでスケールアップする方法
私はスケーラビリティの問題に精通していません。本当にありがとうと思います。
ありがとうございました。
同意する...スレッドは、単一のマシンで拡大縮小するのに役立ちます。異なるマシン間でスケールしたい場合は、Terracottaを使用してください。
Java SEスレッドを使用すると、1台のマシン上でスケーリングできますが、異なるマシン間で水平方向にスケーリングする必要がある場合は、EJBを使用する方法があります。
私の場合は、必要な数のマシン上で動作し、それらのマシン間で負荷バランスをとることができる別個のWebサービス層にファームウェアをインストールします。
ウィリアムズ、「別のWebサービス層にそれを農場で」詳しく説明できますか、ありがとう。 – Lily
あなたが行っている作業の最小単位が1つのスレッド内でどのように機能するかを解説します。その作業単位の周りにWebサービスを作成します。このサービスは、複数の異なるマシン上で並行して実行することができ、作業を均等に分散するために、その前にロードバランサを配置します。その前に、メインWebサービスでは、作業をシングルタスクサブユニットに分割し、それらのユニットをロードバランサーを介してシングルタスクサービスに転送するタスクがあります。結果を収集し、要求元のクライアントに送り返します。 –
この場合、EJBを使用する理由はありません。どこにボトルネックがあるのか自分に尋ねなければなりません。私の賭けはビデオ処理になります。私はあなたのアプリケーションをプロファイリングし、彼らが処理しているよりも自分のタイムスライスを待っている時間を過ごす前に、処理できるスレッドの数を確認します。より多くのスレッドを追加しても、スループットは向上しません。その時点で、マシンが何をするのか、一定のスループットを維持するために必要なマシンの数が分かります。マシンをどのように拡大するかは別の質問です。
それはとても良い点です！ハードウェアを購入する前にいくつかの実験を行ってください。 – Lily
これは2つの異なる問題です。
レンダリングのようなサウンドをキャプチャ/処理すると、問題が発生します。これらは水平に単純に拡大縮小されています。ほとんどのソリューションにはジョブのキューが含まれていますが、Javaでこれを行う必要はありません。あなたが好きなシンプルなソリューションを見つけるだけです。 "render farm ffmpeg"やそのようなものはGoogleに結果をもたらすはずです。
あなたの「ウェブサービスとしての提供」の部分は、いくぶん未定です。これらのビデオを簡単にアクセスできるようにするには、負荷分散が容易で水平方向に拡張可能なHTTPサーバーに格納する必要があります。ストレージの速度やネットワーク帯域幅はおそらく最初のボトルネックになります。
正式なJ2EEスタックは残しておいてください。
代わりに、Y個のスレッドをコンシューマとして実行しているX個のJVMを使用してJMSを会話する素敵なメッセージキュー。
スケーラビリティへの単一の答えはありません。 「良いプログラムを設計するにはどうすればよいのですか」と尋ねるようなものです。 –
それでは、もっと適切な方法でタイトルを挿入するにはどうすればいいですか？私はこの分野の専門家ではなく、あなたの提案に感謝します。 – Lily