Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article fournit des solutions aux problèmes de performances courants que vous pouvez rencontrer lorsque vous utilisez la bibliothèque Event Hubs dans le Kit de développement logiciel (SDK) Azure pour Java. Si vous recherchez des solutions à d’autres problèmes courants que vous pouvez rencontrer lorsque vous utilisez Event Hubs, consultez Résolution des problèmes liés à Azure Event Hubs.
Utiliser processEvent ou processEventBatch
Lorsque vous utilisez le rappel processEvent, chaque instance EventData reçue appelle votre code. Ce processus fonctionne bien avec un trafic faible ou modéré dans le hub d’événements.
Si le hub d’événements a un trafic élevé et qu'un débit élevé est attendu, le coût agrégé d’appel continu de votre rappel entrave les performances de EventProcessorClient. Dans ce cas, vous devez utiliser processEventBatch.
Pour chaque partition, votre rappel est appelé un par un. Le temps de traitement élevé dans le rappel entrave les performances, car l'élément EventProcessorClient ne continue pas à transmettre davantage d’événements en aval ni à demander davantage d’instances EventData du service Event Hubs.
Coûts du point de contrôle
Lorsque vous utilisez Azure Blob Storage comme magasin de points de contrôle, il y a un coût réseau associé au pointage, car il effectue une requête HTTP et attend une réponse. Ce processus peut prendre jusqu’à plusieurs secondes en raison de la latence réseau, des performances du Stockage Blob Azure, de l’emplacement des ressources, et ainsi de suite.
Le point de contrôle après le traitement de chaque EventData instance entrave les performances en raison du coût de l’exécution de ces requêtes HTTP. Vous ne devez pas effectuer de point de contrôle si votre rappel n’a traité aucun événement ou si vous devez effectuer un point de contrôle après avoir traité un certain nombre d’événements.
Utiliser LoadBalancingStrategy.BALANCED ou LoadBalancingStrategy.GREEDY
Lorsque vous utilisez LoadBalancingStrategy.BALANCED, EventProcessorClient revendique une partition pour chaque cycle d'équilibrage de charge. S’il existe 32 partitions dans un hub d’événements, il faut 32 itérations d’équilibrage de charge pour revendiquer toutes les partitions. Si les utilisateurs connaissent un nombre défini d’instances en cours d’exécution EventProcessorClient , ils peuvent utiliser LoadBalancingStrategy.GREEDY pour revendiquer leur partage des partitions dans un cycle d’équilibrage de charge.
Pour plus d’informations sur chaque stratégie, consultez LoadBalancingStrategy.java dans le référentiel azure-sdk-for-java.
Configurer prefetchCount
La valeur prefetchCount par défaut est 500. Lorsque le lien de réception AMQP est ouvert, il place 500 crédits sur le lien. En supposant que chaque EventData instance est un crédit de lien, EventProcessorClient préfetches 500 EventData instances. Lorsque tous les événements sont consommés, le client processeur ajoute 500 crédits au lien pour recevoir plus de messages. Ce processus se répète tant que le EventProcessorClient conserve la propriété d'une partition.
La configuration prefetchCount peut avoir des implications sur les performances si le nombre est trop faible. Chaque fois que le lien de réception AMQP attribue des crédits, le service distant envoie un ACK (accusé de réception). Pour les scénarios à débit élevé, la surcharge liée à l’exécution de milliers de demandes clientes et de kits ACK de service peut entraver les performances.
La configuration prefetchCount peut avoir des implications sur les performances si le nombre est trop élevé. Lorsque des crédits x sont placés sur la ligne, le service Event Hubs sait qu’il peut envoyer au maximum des messages x . Lorsque chaque EventData instance est reçue, elle est placée dans une file d’attente en mémoire, en attente d’être traitée. Un grand nombre d’instances dans la file d’attente peut entraîner une utilisation très élevée de la mémoire.
Étapes suivantes
Si les conseils de dépannage de cet article ne permettent pas de résoudre les problèmes liés à l'utilisation des bibliothèques clientes Azure SDK for Java, nous vous recommandons de déposer un problème dans le référentiel GitHub Azure SDK for Java.