2

ポイントツーポイント MQ 通信でトランスポート層を使用する既存のアプリケーションに取り組んでいます。

指定されたアカウントのリストごとに、いくつかの情報を取得する必要があります。

現在、MQ と通信するために次のようなものがあります。

responseObject getInfo(requestObject){
    code to send message to MQ
    code to retrieve message from MQ
}

ご覧のとおり、次のアカウントに進む前に、完全に終了するまで待ちます。パフォーマンスの問題のため、再加工する必要があります。

現時点で考えられるシナリオは 2 つあります。

1) アプリケーション内で、アカウントごとにトランスポート アダプターを実行する一連のスレッドを作成します。次に、各タスクからデータを取得します。私はこの方法を好みますが、一部のチーム メンバーは、このような変更にはトランスポート層が適していると主張しており、アプリケーションではなく MQ に余分な負荷をかける必要があります。

2) パブリッシュ/サブスクライブ モデルを使用するようにトランスポート層を作り直します。理想的には、次のようなものが必要です。

void send (requestObject){
  code to send message to MQ
}

responseObject receive()
{
  code to retrieve message from MQ
}

次に、ループ内でリクエストを送信し、後でループ内でデータを取得します。アイデアは、最初のリクエストがバックエンド システムによって処理されている間、応答を待つ必要はなく、代わりに次のリクエストを送信するというものです。

私の質問は、現在の順次検索よりもはるかに高速になるということですか?

4

3 に答える 3

3

質問のタイトルは、これを P2P と pub/sub の間の選択肢として組み立てていますが、質問の本文では、スレッド処理とパイプライン処理の間の選択肢として組み立てています。これらは2つの完全に異なるものです。

提供されたコード スニペットは、P2P または pub/sub を使用してメッセージの送受信を簡単に行うことができます。決定は速度に基づいて行うべきではなく、問題のインターフェイスが単一のメッセージを複数の受信者に配信する必要があるかどうかに基づいて決定する必要があります。答えが「いいえ」の場合は、アプリケーションのスレッド モデルに関係なく、ポイント ツー ポイントを使用することをお勧めします。

ちなみに、タイトルの質問に対する答えは「いいえ」です。ポイントツーポイント モデルを使用すると、メッセージはすぐに宛先または送信キューに解決され、WebSphere MQ はそこからメッセージをルーティングします。pub/sub を使用すると、メッセージは内部ブローカー プロセスに渡され、ゼロから多数の可能な宛先が解決されます。このステップの後にのみ、パブリッシュされたメッセージがキューに入れられ、残りの行程では、他のポイント ツー ポイント メッセージと同様に処理されます。pub/sub は通常、ポイント ツー ポイントよりも著しく遅くはありませんが、コード パスが長くなるため、他のすべての条件が同じであれば、レイテンシが少し増加します。

質問の他の部分は、並列処理についてです。要求と応答が別々に処理されるように、多くのスレッドをスピンアップするか、アプリを分割することを提案しました。3 番目のオプションは、複数のアプリケーション インスタンスを実行することです。これらの一部またはすべてをデザインに組み合わせることができます。たとえば、複数の要求スレッドと複数の応答スレッドをスピンアップして、複数のキュー マネージャーに対してアプリケーション インスタンスを処理させることができます。

この問題の鍵は、メッセージが相互に親和性を持っているかどうか、依存関係を順序付けするため、またはメッセージを作成したアプリケーション インスタンスまたはスレッドに類似性を持っているかどうかです。たとえば、リクエスト/リプライで HTTP リクエストに応答している場合、HTTP セッションに接続されたスレッドは、おそらくリプライを受信するスレッドである必要があります。しかし、応答が完全に非同期で、データベースを応答データで更新するだけでよい場合は、要求スレッドと応答スレッドを別々にすると便利です。

どちらの場合でも、インスタンス数を動的にスピンアップまたはスピンダウンする機能は、ピーク ワークロードの管理に役立ちます。これがスレッド化のみで達成される場合、パフォーマンスのスケーラビリティは単一サーバーの上限に制限されます。これが、同じまたは異なるサーバー/QMgr で新しいアプリケーション インスタンスをスピンアップすることによって達成される場合、スケーラビリティとワークロード バランシングの両方が得られます。

これらの主題に関するより詳しい考察については、次の記事を参照してください: Mission:Messaging: Migration, failover, and scaling in a WebSphere MQ cluster

また、WebSphere MQ SupportPacsページにアクセスして、ご使用のプラットフォームと WMQ バージョンの Performance SupportPac を探してください。これらは MP** で始まる名前のものです。これらは、接続されたアプリケーション インスタンスの数が変化するときのパフォーマンス特性を示します。

于 2011-05-18T11:36:09.573 に答える
1

あなたがこれについて正しい方法で考えているようには聞こえません。使用するモデル (ポイント ツー ポイントまたはパブリッシュ/サブスクライブ) に関係なく、バックエンド システムが遅いためにパフォーマンスが制限されている場合は、どちらもプロセスを高速化するのに役立ちません。ただし、理論的にはバックエンド システムに対して一度に複数のリクエストを発行でき、スピードアップが期待できる場合でも、ポイント ツー ポイントまたはパブリッシュ/サブスクライブを行うかどうかはあまり気にしません。あなたが本当に気にしているのは、同期と非同期です。

データを取得するための現在のアプローチは明らかに同期的です。要求メッセージを送信し、対応する応答メッセージを待ちます。すべての要求メッセージを 1 つのメソッドで連続して (おそらくループで) 送信し、別のメソッド (できれば別のスレッド) で受信トピックの応答を監視するだけで、通信を非同期に行うことができます。これにより、コードが個々のリクエストでブロックされなくなります。(これはオプション 2 にほぼ対応しますが、pub/sub はありません。)

オプション 1 は、実際に行う必要があるリクエストの数によってはかなり扱いにくくなる可能性があると思いますが、pub/sub チャネルに切り替えることなく実装することもできます。

于 2011-05-17T17:36:26.490 に答える
0

作り直されたアプローチでは、使用するスレッドが少なくなります。それがアプリケーションを高速化するかどうかは、現在多くのスレッドを管理するオーバーヘッドが原因で速度が低下しているかどうかによって異なります。スレッド数が 1000 未満の場合 (これは非常に大まかな見積もりです!)、おそらくそうではないと思います。それ以上あれば、大丈夫かもしれません。

于 2011-05-17T17:34:34.823 に答える