Bloomberg APIv3, возвращающий медленные потребительские предупреждения

Question

Я сделал программу в C# на основе примера SubscriptionWithEventHandlerExample API 3.2.9.0. После подписки на около 500 ценных бумаг для данных в реальном времени, я получаю некоторые предупреждения о событиях ADMIN, требующие SlowConsumerWarning и SlowConsumerWarningCleared. Я где-то читал, что он вводит некоторую задержку, пока я не обработаю все события.

Проблема в том, что в моем коде я получаю только обратные вызовы от bloomberg. Очередь событий даже не в моей программе!

Некоторые вещи, которые я пытался:

1. поднять предел очереди, установка MaxEventQueueSize в параметрах сеанса (кажется, не имеет никакого эффекта)

2. увидеть, если я получаю какое-либо событие тайм-аута (нет, Я не получаю)

3. создать несколько сеансов и подписавшись 50 ценных бумаг в каждой (теперь я получаю несколько предупреждений, один для каждого потока)

Есть ли что-то, что я могу сделать, или такое поведение выходит за рамки моей компетенции?

Answer 1

Вы можете обработать данные в выделенном потоке и только позволить Bloomberg callbacks поставить в очередь данные. Ваш поток обработки данных будет считывать данные из очереди и выполнять любую трудоемкую работу. Это может решить вашу проблему, в зависимости от того, что вызывает SlowConsumerWarning. Если ваш код для обработки данных слишком медленный, ваша очередь будет заполняться со временем.

Answer 2

API Bloomberg и связанные с ним процессы являются внутренне многопоточными. Если вы подписаны на источник в режиме реального времени и не обрабатываете события достаточно быстро, чтобы события внутренне запускали резервное копирование в API Bloomberg, API выпустит предупреждение о медленном потребителе. Я думаю, что на этом этапе он также может начать дросселирование или падение событий. Вы делаете что-то отнимающее много времени в обратном вызове события (запись в базу данных)?

Суть в том, что если вы подписываетесь на данные в режиме реального времени на 500 событий ценных бумаг, обработка ваших событий должна идти в ногу с потоком данных, на которые вы подписаны.

Answer 3

Я не уверен, относится ли это к вышеуказанной проблеме, но, скорее всего, пролить свет на возможность.

Если вы делаете запрос на данные, которые приводят к большому количеству событий, генерируемых API Bloomberg (например, длинный исторический запрос на внутридневные данные или, возможно, подписки в реальном времени), не используйте шаблон, указанный в документации API, так как это может привести к тому, что ваше приложение будет очень медленным для получения всех событий. В принципе, не вызывайте NextEvent() в объекте Session, вместо этого используйте выделенный 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, как известно, не особенно детерминированный ...