私はMQサーバー7.1をmachine1で実行しています。マシン2で実行されているJavaアプリがあり、JMSを使用してマシン1のキューにメッセージを書き込みます。Javaアプリは1秒あたり数百のメッセージを処理します（他の場所からのデータ）。現在、キューにメッセージを書き込むには、200のテキストメッセージ（平均サイズ600バイト）または1秒あたり2000のメッセージに約100ミリ秒かかります。これは妥当なパフォーマンスですか。パフォーマンスをさらに向上させるためにできることのいくつかは何ですか。つまり、より速く？
6374 次
2 に答える
8
WebSphere MQパフォーマンス・レポートには、いくつかの詳細な推奨事項があります。これらはSupportPacsとして公開されています。SupportPacランディングページから始める場合、必要なものはすべてMPxxという名前で、プラットフォームごとおよびバージョンごとに利用できます。
SupportPacsからわかるように、WMQは、さまざまなメッセージサイズとタイプにわたって、速度と信頼性のバランスが取れるように調整されています。構成および設計/アーキテクチャを通じて調整するためのかなりの自由度があります。
構成の観点からは、永続メッセージと非永続メッセージのバッファー、ディスク書き込みの整合性をトリプル書き込みからシングル書き込みに減らすオプション、ログファイルのサイズと数の調整、接続の多重化などがあります。このことから、QMgrが特定のトラフィック特性に合わせて調整されるほど、QMgrをより速く実行できることが推測されます。これの裏側は、タイトにチューニングされたQMgrは、チューニング仕様の範囲外の新しいタイプのトラフィックが表示された場合に、悪い反応を示す傾向があることです。
また、WMQファイルシステムを個別のスピンドルに割り当てると、パフォーマンスが大幅に向上します。永続メッセージが書き込まれると、キューファイルとログファイルの両方に送信されます。これらのファイルシステムの両方が同じディスク読み取り/書き込みヘッドに対して競合している場合、パフォーマンスが低下する可能性があります。これが、WMQが、ほぼ同じサイズの仮想マシンまたはサーバーよりも高性能ラップトップで実行速度が低下する場合がある理由です。ラップトップに物理的な回転ディスクがあり、WMQファイルシステムが両方とも割り当てられていて、サーバーにSANがある場合、比較はできません。
設計の観点からは、並列処理から多くのパフォーマンスを得ることができます。パフォーマンスレポートは、クライアント接続を追加するとパフォーマンスが大幅に向上し、その後は横ばいになり、最終的には低下し始めることを示しています。幸い、フォールオフする前のクライアントの最大数は非常に多く、Webアプリサーバーは通常、必要なJavaスレッドの数だけで、WMQよりも先にダウンします。
大きな違いを生む可能性のあるもう1つの実装の詳細は、コミット間隔です。一度に多くのメッセージを送信または取得できるアプリの場合は、そうすることでパフォーマンスが向上します。同期点での永続メッセージは、COMMIT発生するまでディスクにフラッシュする必要はありません。単一の作業単位で複数のメッセージを書き込むことにより、WMQは制御をプログラムにすばやく戻し、書き込みをバッファーに入れて、一度に1つのメッセージを書き込むよりもはるかに効率的に最適化できます。
Of Mice and Elephantsの記事には、チューニングオプションに関する追加の詳細な説明が含まれています。これはdeveloperWorksMission ：Messagingシリーズの一部であり、チューニングについても触れている他の記事がいくつか含まれています。
于 2012-02-01T19:12:16.507 に答える
1
これを確認することをお勧めします：WindowsおよびUNIXでのパフォーマンスのためのWebSphereMQの構成と調整
于 2014-01-13T06:20:01.103 に答える