Bloomberg APIv3 retournant les avertissements lents du consommateur

Question

J'ai créé un programme en C# basé sur l'exemple SubscriptionWithEventHandlerExample de l'API 3.2.9.0. Après m'être abonné à environ 500 titres pour des données en temps réel, je reçois quelques avertissements d'événement ADMIN déclarant SlowConsumerWarning et SlowConsumerWarningCleared. J'ai lu quelque part qu'il introduit un certain retard, jusqu'à ce que je traite tous les événements.

Le problème est que dans mon code je reçois seulement des rappels de bloomberg. La file d'attente des événements n'est même pas dans mon programme!

Certaines choses que j'essayées:

1. augmenter la limite de file d'attente, la mise en MaxEventQueueSize dans les options de session (semble avoir aucun effet)

2. voir si je reçois tout état de cause de délai d'attente (non, Je ne comprends pas)

3. créer plusieurs sessions et la souscription de 50 titres dans chaque (maintenant je reçois plusieurs avertissements, un pour chaque fil)

Y at-il quelque chose que je peux faire ou ce comportement est hors de ma portée?

Answer 1

Vous pouvez effectuer le traitement des données dans un thread dédié et laisser uniquement le Bloomberg callbacks mettre en file d'attente les données. Votre thread de traitement des données lirait les données de la file d'attente et effectuerait un travail fastidieux. Cela pourrait résoudre votre problème, en fonction de ce qui déclenche un SlowConsumerWarning. Si votre code pour traiter les données est trop lent, votre file d'attente se remplirait au fil du temps.

Answer 2

L'API Bloomberg et les processus associés sont multithread internes. Si vous vous abonnez à une source en temps réel et ne traitez pas les événements assez rapidement pour que les événements commencent à effectuer une sauvegarde interne dans l'API Bloomberg, l'API émettra un avertissement de consommateur lent. Je pense qu'à ce stade, il peut également commencer à étrangler ou à laisser tomber des événements. Est-ce que vous faites quelque chose qui prend du temps dans le rappel d'événement (écrire dans une base de données)? En fin de compte, si vous vous abonnez à des données en temps réel pour 500 événements de titres, le traitement de vos événements doit suivre le flux de données auquel vous êtes abonné.

Answer 3

Je ne suis pas sûr si cela s'applique à la question ci-dessus, mais il est susceptible de faire la lumière sur une possibilité. Si vous effectuez une requête pour des données qui génèrent de nombreux événements générés par l'API Bloomberg (telles que les longues demandes de données intraday historiques ou éventuellement les abonnements en temps réel), n'utilisez pas le modèle spécifié dans la documentation API, comme il peut finir par rendre votre application très lente pour récupérer tous les événements. Fondamentalement, n'appelez pas NextEvent() sur un objet Session, utilisez plutôt une EventQueue dédiée.

au lieu de le faire:

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

Pour ce faire:

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

Cela peut entraîner une amélioration de la performance, bien que l'API est connu pour ne pas être particulièrement déterministe ...