1

リモート コンピューターから .xml ページを取得し、それらを Java オブジェクトに変換し、それぞれを mysql データベースに永続化する JavaEE 6 / EJB3.1 / Glassfish 3.1.2 アプリケーションがあります。これらの .xml ページは数万あり、私はそれらを少しずつ追加しています。
これはうまく機能していますが、非常に遅いことを除けば (70 ミリ秒のページ取得 + エンティティの変換と永続化にわずかな時間がかかります)。

この作業を並行して実行して速度を上げたいのですが、どの方法が最適ですか?

注目に値する可能性があります: ページを取得するたびに、ページを取得するために使用している OAuth 資格情報の mysql データベース内のカウントが更新されます。最大数の場合は続行されません (例外がスローされます)。これが問題を複雑にするかどうか、またはどれだけ複雑になるかはわかりませんが、2 つのスレッドが最大値を下回っていることを確認した場合は、カウントを更新する前にページを取得して、最大値を超える可能性があります。

これまでの私の調査では、2 つの可能性に絞り込まれました (ただし、他の可能性を自由に追加してください)。

  1. メッセージ駆動型 Bean - おそらく間違っていると思いますが、メッセージ キューがいっぱいになるまで (10 個の URL が追加されたとします)、セッション Bean が URL メッセージを送信し、キューがいっぱいになるまでブロックすることを想像します。Glassfish は、私が作成したメッセージ Bean の 10 個のインスタンスを作成し、それぞれが URL の 1 つから .xml の 1 つを取得し、OAuth カウントを更新し、この .xml を別のキューにメッセージとして送信し、別のメッセージ Bean を変換して永続化します。このキューからの xmls。
  2. @Asynchronousメソッドを使用して、独自のスレッド セーフ キューを作成しますか? これははるかに単純で、私がやっていることにより適している可能性がありますが、それをどのように実装するか正確にはわかりません.

アドバイスをいただければ幸いです。

4

2 に答える 2

1

あなたはリモートサーバーを扱っているので、それがどれだけうまく拡張できるか知っていますか? 10 スレッドでヒットした場合、応答時間は 700 ミリ秒になりますか、それとも 70 ミリ秒で安定しますか?

リモートサーバーがスケーリングすると仮定すると、MDB のアイデアにぴったりだと思います。ただし、それについてのあなたの考えのいくつかは不正確です。キューに送信するセッション Bean を作成します。私たちが違うところは、作業が利用可能になるとすぐにキューをロードしたいと思うということです。キューのサイズを設定し、そのサイズが満たされた場合に最も古いものまたは最も新しいものを破棄するかどうかを指定できます。すべてのメッセージを消費したいと考えていますが、それも可能です。何十万ものメッセージが入ったキューを実行しています。メッセージをできるだけタイトにすることで管理できるキューのメモリ内サイズに実際に制限されています。

消費側では、MDB プールを 10 Bean などに制限します。これは、リモート サーバーがスケーリングできるものと、サーバーがスケーリングできるものに依存します。2 つのキューを使用するのではなく (これは、説明した問題に基づいています)、1 つだけを使用します。現在行っているすべてのことを行う MDB を作成します。つまり、xml を取得して永続化します。最後に、スケーリングが必要な場合は、クラスターを作成してノードを追加するだけです。各ノードには、動作する MDB プールがあります。

非同期に関しては、どのようにプール サイズを制御し、MDB が提供する他のすべてのものを制御しますか? できなかったと言っているわけではありませんが、車輪の再発明をしているようです.

于 2012-11-21T11:10:18.850 に答える
0

プレストンに完全に同意します。さらに、ノードを追加してスケーリングする必要があることに気付いた場合は、複数のコンシューマーを受け入れる方法で JMS キューを構成してください。これは、作業がワーカーにディスパッチされる「アプリケーション レベル」のロード バランサーの一般的な設定です。

于 2012-11-22T16:15:12.140 に答える