4

SubscriptionWithEventHandlerExampleAPI 3.2.9.0の例を元にc#でプログラムを作りました。リアルタイム データ用に約 500 の証券を購読した後、ADMIN イベントの警告が表示SlowConsumerWarningされ、SlowConsumerWarningCleared. すべてのイベントを処理するまで、ある程度の遅延が発生することをどこかで読みました。

問題は、私のコードではブルームバーグからのコールバックしか受け取らないことです。イベントキューは私のプログラムにもありません!

私が試したいくつかのこと：

  1. セッションオプションでMaxEventQueueSizeを設定して、キューの制限を引き上げます（効果がないようです）

  2. タイムアウト イベントが発生するかどうかを確認します (いいえ、何も発生しません)。

  3. 複数のセッションを作成し、それぞれに 50 の証券をサブスクライブします (スレッドごとに 1 つずつ、複数の警告が表示されるようになりました)

私にできることはありますか、それともこの行動は私の範囲外ですか?

4

3 に答える 3

4

専用スレッドでデータの処理を行い、Bloomberg だけcallbacksがデータをキューに入れるようにすることができます。データ処理スレッドはキューからデータを読み取り、時間のかかる作業を行います。.をトリガーするものによっては、問題が解決する場合がありますSlowConsumerWarning。ただし、データを処理するコードが遅すぎると、時間の経過とともにキューがいっぱいになります。

于 2010-04-09T12:56:39.293 に答える
3

Bloomberg API と関連プロセスは、内部でマルチスレッド化されています。リアルタイム ソースをサブスクライブし、イベントを処理する速度が十分でなく、イベントがブルームバーグ API で内部的にバックアップを開始する場合、API はスロー コンシューマーの警告を発行します。この段階で、イベントのスロットリングまたはドロップも開始される可能性があると思います。イベント コールバックで時間のかかる処理 (データベースへの書き込み) を行っていませんか?

肝心なのは、500 の証券イベントのリアルタイム データをサブスクライブする場合、イベント処理は、サブスクライブしたデータの流れに追いつく必要があるということです。

于 2010-04-11T11:09:56.600 に答える
1

上記の問題に当てはまるかどうかはわかりませんが、可能性に光を当てる可能性があります.

Bloomberg API によって大量のイベントが生成される結果となるデータをリクエストする場合 (長い履歴の日中データ リクエスト、場合によってはリアルタイム サブスクリプションなど)、API ドキュメントで指定されているパターンを使用しないでください。アプリケーションがすべてのイベントを取得するのが非常に遅くなります。基本的に、Session オブジェクトで NextEvent() を呼び出さず、代わりに専用の EventQueue を使用します。

これを行う代わりに：

var cID = new CorrelationID(1);
session.SendRequest(request, cID);
do {
   Event eventObj = session.NextEvent();
   ...
}

これを行う：

var cID = new CorrelationID(1);
var eventQueue = new EventQueue();
session.SendRequest(request, eventQueue, cID);
do {
   Event eventObj = eventQueue.NextEvent();
   ...
}

APIは特に決定論的ではないことが知られていますが、これによりパフォーマンスがいくらか向上する可能性があります...

于 2011-05-25T15:51:36.373 に答える