0

ここに私のシナリオがあります: 私のアプリケーションには、内部的に tcp ソケットを使用する Quickfix を使用して互いに通信するいくつかのプロセスがあります。フローは次のようになります。

プロセス 1 は quickfix メッセージを送信します -> プロセス 2 はプロセス 1 からのメッセージを処理した後、quickfix メッセージを送信します -> .....-> プロセス n

同様に、確認メッセージは次のように流れます。

プロセスn->....->プロセス1

ここで、最後のプロセス ( process n ) を除くこれらのプロセスはすべて同じマシン上にあります。私はググって、tcpソケットがipcメカニズムの中で最も遅いことを発見しました。

それで、他のipcメカニズムを介して（明らかにAPIを使用して）クイックフィックスメッセージを送受信する方法はありますか。はいの場合、同じマシン上にあるすべてのプロセス間でその ipc メカニズムを使用することにより、待ち時間を短縮できます。

ただし、そうすると、それらのメカニズムは tcp ソケットのように完全なメッセージの送信を保証しますか?

4

2 に答える 2

0

時期尚早の最適化を行っていると思います.TCPがパフォーマンスのボトルネックになるとは思いません. ローカル LAN の遅延は、外部 FIX 接続の遅延よりも速くなります。OnMessage()経験上、パフォーマンスの問題は、後で行われる IPCの問題ではなく、アプリのメッセージ処理 (おそらくコールバックでの偶発的なブロックが原因) に起因すると予想されます。

アドバイス:通信コンポーネントを抽象化レイヤー インターフェイスで記述し、必要になると判断した場合に後で TCP を別のもの (たとえば、ActiveMQ、ZeroMQ、その他考えられるもの) に交換できるようにします。

それ以外は、システムが正しく動作するようにすることに集中してください。動作が正しいことを確認したら (できればテストで確認してください)、パフォーマンスに取り組むことができます。 最適化を行う前にパフォーマンスを測定し、「改善」を行った後に再度測定します。自分の直感を信用しないでください。数字を取得します。

于 2013-01-29T15:22:58.117 に答える
0

この質問に関連する要件について詳しく聞くのは良いことですが、共有メモリ ソリューションを検討することをお勧めします。トレード マッチング エンジンを備えた同じ場所にある施設でサーバーを実行し、外部通信に高速のカーネル バイパス通信を使用していると想定しています。TCP に関する問題の 1 つは、ユーザー/カーネル空間の遷移です。IPC にユーザー空間の共有メモリを使用することを検討し、カーネルの遷移も伴う可能性のある同期メカニズムを使用するのではなく、同期にビジー ポーリング手法を使用することをお勧めします。

于 2013-02-08T22:51:37.833 に答える