件名: メッセージング、トランスポート、レイテンシ
ZeroMQ は、スケーラブルな正式なコミュニケーション パターン フレームワークです。それは一連のスマート オブジェクトを提供し、多くの内部の細かい点をデザイナーから隠します (これは非常に有益です)。
ZeroMQ はメッセージング用に設計されています
トランスポートにとらわれない、つまり、ほとんどのユース ケースは{ inproc: | ipc: | tcp: | pgm: | epgm: }、配信が行われる特定のトランスポート クラス ( )を考慮しません。
最適化された低遅延(「バッテリー付属」の原則として)
あなたが見逃しているように見える重要なことは、主な違いは、アプリケーションがユースケースのメタフォリック名を使用して提示されるZeroMQアーキタイプの動作に基づいて構築されるという事実に由来するということです（PUSH/PULL）。良いデザインにとって重要です。
設計上の決定が不十分で、ソフトウェアが「間違った」(適切に選択されていない) ZeroMQ アーキタイプを使用する場合、遅延は急増するだけです。例としての内部動作が誤解されているためREQ/REPです。
このように、達成可能な最小のレイテンシーは、( *)MQ ライブラリからではなく、スマートな設計から得られます。
ほぼリアルタイムのシステム設計に熟練した ZeroMQ は、コード内の最高の本物のサービスに適合します。 -ソケットメソッド。
の上.Context( nIOthreads )
一般的には、設計機能を分離して、最終基準へのそれぞれの影響を検証できるようにすることをお勧めします。全体的なエンドツーエンドのレイテンシが最小である場合は、インスタンス化され、 メソッドlocalhostを介してアプリケーションによって使用される IO スレッドの数を増やす手順が必要になる場合があります.Context()。
1 秒あたり 10 x 15 x 3kB は、Raspberry Pi プロセッサの場合でも大きな問題ではありません。
より重要なのは、この唯一のステップが、他の設計上の妥協や他の IO ワークロード関連のアクティビティよりも大幅な改善をもたらすかどうかです。
試して。
ただし、人為的に学術的な環境下で「インビトロ」ではなく、「インビボ」でテストしてください。次に、「周囲の」アーキテクチャがすでに実装されており、設計された手法のまさにコンテキストで測定するため、失うことなく利益を得ることができます。
次はどこへ？
出発点としては、Pieter HINTJEN の本「Code Connected, Volume 1」で 1 (asPdf)週間の実践的なテストを行うことをお勧めします。そこでは、前進するのに役立つ素晴らしい詳細な知識プールとコード例の両方について説明しました.
メリットに基づく事実に焦点を当てましょう。
A4:いいえ、可能であれば、それzmq.Context()はシングルトンであり、アーキテクチャ/設計/テストが有益であることが証明されている場合、 zmq.Context() インスタンスは、特定の低レベルのトラフィック パターン (ユーザー コード側からの他の支援/制御なし)。この意味で、すでに実装され、事前にテストされたソリューションが稼働するまで、そのような潜在的な利点を推測することは意味がありません. ソリューションが運用可能になったら、このパラメーターを増やして、全体的な処理パフォーマンスへの影響を実験的に測定することができます。
常に思い出させる良い習慣は、ダーティーリークを避けるために、ソケットとコンテキストのライフサイクルの適切な終了を強制することに十分な注意を払うことです。このような練習は推奨以上のものです。
A3:はい、TCP-transport-class も使用できます。Windows 以外のローカルホストでは、IPC オプションが実行可能になります。速度に関する質問は、意見に基づくものではなく、むしろ測定されるべきものです。あなたのコードが追加の [us]-s と [ns]-s ( zmq.Stopwatch はその解像度で約 30 ナノ秒にまで低下する) を削減するのに苦労している場合、コード設計に基づいて、いくつかを期待することができます。 TCP プロトコルのワイヤーライン フレーミング アセンブリ/再アセンブリ/デコードを回避することによるわずかな利点。よくある質問は、測定可能/観察可能なスピードアップに対して、これがどの程度の追加コストで利用できるようになるかということです。
A2:広すぎて答えられません。処理アーキテクチャと taskUnit のワークフローについての一言がなければ、Q2 に真剣に答える方法はありません。
A1:最適化の目標が「最高」であるという基準がありません。基準や指標がないため、一般的なルールのみが有効です。仕様を完全に満たし、所定の時間と予算内で正常に動作し、安定しているルールが最適です。