FIX プロトコルを介してベンダーに注文を送信します。ベンダーは 1 秒あたり 100 件の FIX メッセージしか受け付けないため、送信する注文をこの速度を超えないように調整するよう要求しています。ここで見つけたものと同様に、送信するメッセージを遅くするために何かを書くことができると確信しています: Throttling method calls to M requests in N seconds
しかし、2 つの質問があります。
執行ベンダーまたは清算会社に送信されるメッセージの速度を遅くすることが業界で一般的な要件であるかどうかを知りたいですか?
QuickFix/J でメッセージのスループットを自動的に低下させるパラメータはありますか?
大量のフィルの処理が困難なシステムが多数あります。ほとんどの場合、ネットワーク帯域幅とは何の関係もありませんが、アプリケーション層でのメッセージの基本的な処理とは関係ありません。
たとえば、一部の古いシステムは、テーブルをロックするリレーショナル データベースに依存しており、実行が大量に処理されると、注文管理システム全体でパフォーマンスの問題が発生する可能性があります。
ブルート フォース ソリューションは、実行プロバイダーに強制的に実行をロールアップさせるか、スロットルさせることです。
これは、ベンダーが帯域幅を制限しており、おそらく数十または数百のクライアントが接続しているという事実に関係しています。たとえば、100 の商品の価格設定を要求した場合、静かな市場ではこれらすべてが 1 秒に 1 回更新され、FIX 接続ごとに、ベンダーは 1 秒に 100 件のメッセージを処理する必要があります。わかりました。FIX メッセージはバイト数に関するものです。1 文字あたり 1 バイト = 500 バイトで 500 文字とします (誰かがここで私を訂正してください)。したがって、500 * 100 = 接続ごとに 1 秒あたり 50,000 バイトです。
次に、100 クライアントを接続 = 1 秒あたり 5,000,000 バイト。うーん、まだたくさんの部屋があります。
しかし、相場が毎秒 10 ～ 20 回更新される忙しい市場では. 数値は 10 倍または 20 倍になります。ネットワーク ストーム、長いメッセージ キュー、高い CPU 使用率、メッセージの損失、またはすべてがダウンする可能性があります。そうなると、最も重要な時期に接続を維持できなくなるため、ベンダーはビジネスをすべて失うことになります。
OK、この問題にはおそらく多くの解決策がありますが、これは解決しなければならない問題の説明です...
もう1つは、ベンダーの主要なマーケットメーカーが市場の状況に応じて見積もりを更新する必要があることです. 彼らは必要な帯域幅を要求するか、単に取引執行を拒否します。つまり、セルサイドとバイサイドの間に別のトレードオフがあります。