Question

我根据API 3.2.9.0的示例SubscriptionWithEventHandlerExample在c＃中创建了一个程序。在为实时数据订阅约500个证券后，我收到一些声明SlowConsumerWarning和SlowConsumerWarningCleared的ADMIN事件警告。我在某个地方读到它引入了一些延迟，直到我处理所有事件。

问题是在我的代码中我只收到来自bloomberg的回调。事件队列甚至不在我的程序中！

我尝试过的一些事情：

提高队列限制，在会话选项中设置MaxEventQueueSize（似乎没有效果）
看看我是否收到任何超时事件（不，我没有得到任何超时）
创建多个会话并在每个会议中订阅50个证券（现在我收到多个警告，每个线程一个）

我能做些什么或者这种行为超出了我的范围吗？

Answer 1

您可以在专用线程中处理数据，只让Bloomberg callbacks对数据进行排队。您的数据处理线程将从队列中读取数据并执行任何耗时的工作。这可能会解决您的问题，具体取决于触发SlowConsumerWarning的内容。但是，如果您处理数据的代码太慢，那么您的队列会随着时间的推移而填满。

Answer 2

Bloomberg API和相关流程内部是多线程的。如果您订阅了实时源并且没有足够快地处理事件以便事件在内部开始在Bloomberg API中备份，则API将发出缓慢的消费者警告。我认为在这个阶段它也可能会开始限制或放弃事件。你是否在事件回调（写入数据库）中做了一些耗时的工作？

最重要的是，如果您订阅500个证券事件的实时数据，您的事件处理必须跟上您订阅的数据流。

Answer 3

我不确定它是否适用于上述问题，但可能会对可能性有所了解。

如果您请求导致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不具有特别的确定性......

Bloomberg APIv3返回慢消费者警告

3 个答案: