Freigeben über


Problembehebung bei der Leistung von Azure Event Hubs

Dieser Artikel enthält Lösungen für häufige Leistungsprobleme, die beim Verwenden der Event Hubs-Bibliothek im Azure SDK für Java auftreten können. Wenn Sie nach Lösungen für andere häufige Probleme suchen, die bei der Verwendung von Event Hubs auftreten können, lesen Sie die Problembehandlung bei Azure Event Hubs.

Verwenden Sie processEvent oder processEventBatch

Wenn Sie den processEvent Rückruf verwenden, ruft jede EventData Instanz Ihren Code auf. Dieser Prozess funktioniert gut mit geringem oder moderatem Datenverkehr im Event Hub.

Wenn der Event Hub stark frequentiert ist und ein hoher Durchsatz erwartet wird, behindern die aggregierten Kosten für das kontinuierliche Aufrufen Ihres Callbacks die Leistung von EventProcessorClient. In diesem Fall sollten Sie verwenden processEventBatch.

Für jede Partition wird Ihr Callback nacheinander aufgerufen. Eine hohe Verarbeitungszeit im Callback behindert die Leistung, weil der EventProcessorClient weder weitere Ereignisse nach unten pusht noch weitere EventData-Instanzen vom Dienst des Event Hubs anfragt.

Kosten des Checkpointing

Wenn Sie Azure Blob Storage als Prüfpunktspeicher verwenden, gibt es Netzwerkkosten für die Prüfpunkte, da eine HTTP-Anforderung gesendet wird und auf eine Antwort gewartet wird. Dieser Vorgang kann aufgrund der Netzwerklatenz, der Leistung von Azure Blob Storage, des Ressourcenstandorts usw. bis zu mehreren Sekunden dauern.

Das Checkpointing nach der Verarbeitung jeder EventData-Instanz beeinträchtigt die Leistung aufgrund der Kosten für diese HTTP-Anfragen. Sie sollten keinen Checkpoint durchführen, wenn Ihr Callback keine Ereignisse verarbeitet hat, oder Sie sollten einen Checkpoint durchführen, nachdem Sie eine bestimmte Anzahl von Ereignissen verarbeitet haben.

Verwenden Sie LoadBalancingStrategy.BALANCED oder LoadBalancingStrategy.GREEDY

Wenn Sie LoadBalancingStrategy.BALANCED verwenden, erhebt EventProcessorClient Anspruch auf eine Partition für jeden Load-Balancing-Zyklus. Wenn in einem Event Hub 32 Partitionen vorhanden sind, dauert es 32 Iterationen zum Lastenausgleich, um alle Partitionen in Anspruch zu nehmen. Wenn Benutzer wissen, dass eine bestimmte Anzahl von EventProcessorClient-Instanzen ausgeführt wird, können sie LoadBalancingStrategy.GREEDY verwenden, um ihren Anteil an den Partitionen in einem Load-Balancing-Zyklus zu beanspruchen.

Weitere Informationen zu den einzelnen Strategie finden Sie unter LoadBalancingStrategy.java im Azure-sdk-for-Java-Repository.

Konfigurieren von prefetchCount

Der Standardwert für Prefetch ist 500. Wenn der AMQP-Empfangslink geöffnet wird, werden 500 Guthaben auf den Link gelegt. Unter der Annahme, dass jede EventData-Instanz einem Link-Guthaben entspricht, stellt EventProcessorClient 500 EventData-Instanzen vorab bereit. Wenn alle Ereignisse verbraucht sind, fügt der Prozessor-Client 500 Guthaben zum Link hinzu, um weitere Nachrichten zu empfangen. Dieser Vorgang wird wiederholt, solange EventProcessorClient noch im Besitz einer Partition ist.

Das Konfigurieren prefetchCount kann Auswirkungen auf die Leistung haben, wenn die Zahl zu niedrig ist. Immer wenn der AMQP-Empfangslink Guthaben platziert, sendet der Remotedienst eine Bestätigung. Bei Szenarien mit hohem Durchsatz kann der Aufwand für Tausende von Clientanforderungen und Dienst-ACKs die Leistung beeinträchtigen.

Das Konfigurieren prefetchCount kann Auswirkungen auf die Leistung haben, wenn die Zahl zu hoch ist. Wenn x Guthaben auf die Zeile gelegt werden, weiß der Dienst Event Hubs, dass er höchstens x Nachrichten senden kann. Wenn jede EventData Instanz empfangen wird, wird sie in einer Speicherwarteschlange platziert, die auf die Verarbeitung wartet. Eine hohe Anzahl von EventData Instanzen in der Warteschlange kann zu einer sehr hohen Speicherauslastung führen.

Nächste Schritte

Wenn die Richtlinien zur Fehlerbehebung in diesem Artikel nicht helfen, Probleme bei der Verwendung der Azure SDK for Java Client-Bibliotheken zu lösen, empfehlen wir Ihnen, einen Fehler im Azure SDK for Java GitHub Repository zu melden.