6

現在の状態のスナップショットを定期的に送信する必要があるアプリケーションがあります。これは現在、約 500,000 の 64 バイト メッセージで表されます。ZMQ を使用して、これほど多くのメッセージを迅速かつ確実に送受信するのに苦労しています。

現在、これを行うために tcp 経由で PUB/SUB を使用していますが、仕事が完了する限り、パターンにもプロトコルにも執着していません。私の実験では、送信と受信の最高水準点、送信と受信のバッファ設定をいじり、送信ループにスリープを追加して少し遅くすることに焦点を当てました。私には非常に寛大に見える設定 (500K HWM、10MB バッファ) で、ループバック接続のみを使用しても、すべてのメッセージが一貫して受信されるわけではありません。

私は、これらまたはその他のチューニング パラメーターの適切な設定に興味があります。また、さまざまな設定がもたらす効果をどのように判断するかについて、より広範に興味があります。

適切な回答を提供するのに役立つ可能性のある詳細情報:

  • 配布は 1 対多です。募集人数は20名程度を予定しております。

  • 各メッセージは、異なる金融商品に関する一連の情報を表し、すべて同時に観察されます。私の考えでは、それらを 1 つの大きなメッセージに結合すること (すべてのメッセージのセットが論理的に 1 つの完全なスナップショットを構成する) と、それらを分離しておくこと (クライアントは潜在的に一部の手段にのみ関心がある可能性があり、これは役立つと思います) の両方について議論することができます。それらをより簡単にフィルタリングします）。

  • メッセージの意図された頻度は、基本的に 20 ミリ秒ごとより速くなく、5 秒より遅くありません。実際に到達する場所は、おそらくパフォーマンスの考慮事項 (つまり、サーバーが実際にメッセージを送り出す速度と、クライアントにとって圧倒されるデータ レートの種類) の影響を受けるでしょう。

4

2 に答える 2

5

これを分解しましょう。

まず、HWM が「機能していない」理由:

HWM は正確な制限ではありません。内部バッファーは 2 つの別々のスレッドによって満たされたり空にされたりするためです。アクティビティが多いと、使用可能なスペースのカウントが大幅に遅れる可能性があります。0MQ zmq_setsockopt のマニュアル ページには、「0MQ は、ソケットが ZMQ_SNDHWM メッセージを受け入れることを保証するものではありません。実際の制限は、ソケット上のメッセージの流れに応じて 60 ～ 70% 低くなる可能性があります。」

第二に、なぜメッセージが失われるのですか:

0.5M メッセージ (x 20) をソケットのバッファーにダンプすると、ランダムに HWM にヒットし、PUB ソケットの動作はキューに入れられないメッセージをドロップします。

第三に、これを解決する方法：

状態を個別のメッセージに分割する理由はありません。これの唯一の理由は、状態がメモリに収まらない場合です。これは簡単にできます。マルチパートとして送信 (ZMQ_SNDMORE); これにより、発信バッファーで 1 スロットを使用する単一の有効なメッセージが作成されます。

次に、500K HWM 制限を削除し、十分すぎるデフォルト (1000) に戻します。

第四に、パフォーマンスを向上させる方法:

明らかに、パブリッシャーとサブスクライバーのコードを可能な限りプロファイリングして改善してください。これらは通常のボトルネックです。

次に、メッセージがまばらで、CPU コストをあまりかけずに圧縮できる場合は、何らかの形式でメッセージを圧縮することを検討してください。サブスクライバーが 20 の場合、通常、ネットワーク オーバーヘッドから得られるものの方が、CPU コストから失われるものよりも多くなります。

最後に、加入者が増えて重要なシステムになった場合は、ネットワーク コストを効果的に削減できる PGM マルチキャストを検討してください。

于 2012-12-15T08:42:34.170 に答える
1

さまざまな組み合わせで半ランダムに実験して一日を過ごした後、次の暫定的な結論に達しました。

  • 送信ループにスリープ ステートメントを追加してメッセージ レートを制限すると、基本的に任意のオプション セットで信頼性が向上します。

  • 500,000 件のメッセージを 500,000 件の個別のメッセージではなく、1 つのメッセージのフレームとして送信すると、信頼性が向上します。

  • tcp プロトコルではなく epgm を使用すると、より高いスループットを実現できます。

  • Epgm では、マルチキャスト レート オプションは、スリープ ステートメントによって達成される目的のメッセージ レートと一致する必要があります。

  • 最高水準点とバッファーを増やすと信頼性が向上しますが、両方の設定を増やして、クライアントとサーバーの両方で行う必要があります。すべてを組み合わせて実行しないと、役に立たない傾向があります。(単一のメッセージのフレームとは対照的に) 個々のメッセージで実行されるあらゆる種類の信頼性を得るには、これらを非常に高く設定する必要があります。この場合、最高水準点を 1,000,000 に設定し、バッファーを 65 MB に設定するまで、良い結果は得られませんでした。(送信しようとしていた一連のメッセージの 2 倍のサイズです。) これは、私が本能的に試みようと思っていたよりもはるかに大きかったです。そのケースでは、500K メッセージの各ラウンド間で 5 秒間一時停止していました。間隔を 1 秒に短縮すると、メッセージの 1 つのバッチのサイズの 4 倍まで、間隔をさらに長くする必要がありました。

  • epgm では、回復間隔の設定はあまり役に立ちません。

于 2012-12-14T21:03:38.913 に答える