2010-04-08 28 views
4

我在c#中基於API 3.2.9.0的示例SubscriptionWithEventHandlerExample製作了一個程序。訂閱約500個證券以獲取實時數據後,我收到一些ADMIN事件警告聲稱SlowConsumerWarningSlowConsumerWarningCleared。我在某處讀到它會引起一些延遲,直到我處理所有事件。Bloomberg APIv3返回緩慢消費者警告

問題是,在我的代碼中,我只接收來自bloomberg的回調。事件隊列甚至不在我的程序中!

一些事情,我想:

  1. 提高隊列限制,在會話選項設置MaxEventQueueSize(似乎沒有任何效果)

  2. 看看,如果我得到任何超時事件(無,我沒有得到任何)

  3. 創建多個會話並在每個認購50個證券(現在我得到多個警告,每個線程)

有什麼我可以做或者這種行爲超出我的範圍?

回答

4

您可以在專用線程中處理數據,並且只允許Bloomberg callbacks對數據進行排隊。您的數據處理線程將從隊列中讀取數據並執行任何耗時的工作。這可能會解決您的問題,具體取決於觸發SlowConsumerWarning的原因。但是,如果處理數據的代碼太慢,那麼隨着時間的推移,您的隊列將會填滿。

+0

是的,除非您有某種方式批量處理比一個接一個更快的事件,否則這隻會將問題向下移一步。 – Jon 2010-04-11 11:10:52

+0

也可能是數據出現在「陣雨」中,並且排隊策略可能隨時間推移處理。然而,根據Jon的回答,似乎Bloomberg API中可能已經有類似的機制。如果是這樣,自己實施它可能會刪除該警告,但無法避免問題的根源。 – Peter 2010-04-13 03:25:10

3

Bloomberg API和相關進程在內部是多線程的。如果您訂閱實時數據源,並且不會盡快處理事件,以便事件內部開始在Bloomberg API中備份,則API將發出緩慢的消費者警告。我認爲在這個階段它也可能開始限制或放棄事件。你是否在事件回調(寫入數據庫)中做了一些耗時的事情?

底線是,如果您訂閱500個證券事件的實時數據,您的事件處理必須跟上您訂閱的數據流。

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是衆所周知的不確定性特別...

相關問題