Problemen met prestaties van Azure Event Hubs oplossen

Dit artikel bevat oplossingen voor veelvoorkomende prestatieproblemen die kunnen optreden wanneer u de Event Hubs-bibliotheek gebruikt in de Azure SDK voor Java. Als u op zoek bent naar oplossingen voor andere veelvoorkomende problemen die kunnen optreden wanneer u Event Hubs gebruikt, raadpleegt u Problemen met Azure Event Hubs oplossen.

ProcessEvent of processEventBatch gebruiken

Wanneer u de processEvent callback gebruikt, wordt uw code door elk EventData exemplaar aangeroepen. Dit proces werkt goed met weinig of gemiddeld verkeer in de Event Hub.

Als de Event Hub veel verkeer en hoge doorvoer verwacht, worden de geaggregeerde kosten voor het continu aanroepen van uw callback de prestaties van EventProcessorClient. In dit geval moet u gebruiken processEventBatch.

Voor elke partitie wordt uw callback één voor één aangeroepen. Hoge verwerkingstijd in de callback belemmert de prestaties omdat er EventProcessorClient niet meer gebeurtenissen downstream worden gepusht of meer EventData exemplaren van de Event Hubs-service worden aangevraagd.

Kosten van controlepunten

Wanneer u Azure Blob Storage als controlepuntarchief gebruikt, zijn er netwerkkosten voor controlepunten omdat er een HTTP-aanvraag wordt ingediend en wordt gewacht op een antwoord. Dit proces kan enkele seconden duren vanwege netwerklatentie, de prestaties van Azure Blob Storage, resourcelocatie, enzovoort.

Controlepunten nadat elk EventData exemplaar is verwerkt, belemmert de prestaties vanwege de kosten van het maken van deze HTTP-aanvragen. U moet geen controlepunt instellen als uw callback geen gebeurtenissen heeft verwerkt of als controlepunt na het verwerken van een aantal gebeurtenissen.

LoadBalancingStrategy.BALANCED of LoadBalancingStrategy.GREEDY gebruiken

Wanneer u gebruikt LoadBalancingStrategy.BALANCED, claimt u EventProcessorClient één partitie voor elke taakverdelingscyclus. Als er 32 partities in een Event Hub zijn, duurt het 32 iteraties voor taakverdeling om alle partities te claimen. Als gebruikers weten dat een bepaald aantal EventProcessorClient exemplaren wordt uitgevoerd, kunnen ze hun LoadBalancingStrategy.GREEDY aandeel van de partities claimen in één taakverdelingscyclus.

Zie LoadBalancingStrategy.java in de opslagplaats azure-sdk-for-java voor meer informatie over elke strategie.

PrefetchCount configureren

De standaardwaarde voor vooraf fetch is 500. Wanneer de AMQP-ontvangstkoppeling wordt geopend, wordt er 500 tegoed op de koppeling weergegeven. Ervan uitgaande dat elk EventData exemplaar één koppelingstegoed is, EventProcessorClient worden 500 EventData exemplaren voorafgegaan. Wanneer alle gebeurtenissen worden gebruikt, voegt de processorclient 500 tegoed toe aan de koppeling om meer berichten te ontvangen. Deze stroom wordt herhaald terwijl de EventProcessorClient nog steeds eigenaar is van een partitie.

prefetchCount Het configureren kan gevolgen hebben voor de prestaties als het aantal te laag is. Telkens wanneer de AMQP tegoeden ontvangt, verzendt de externe service een ACK. Voor scenario's met hoge doorvoer kan de overhead van het maken van duizenden clientaanvragen en service-ACL's de prestaties belemmeren.

prefetchCount Het configureren kan gevolgen hebben voor de prestaties als het getal te hoog is. Wanneer x-tegoed op de regel wordt geplaatst, weet de Event Hubs-service dat het maximaal x-berichten kan verzenden. Wanneer elk EventData exemplaar wordt ontvangen, wordt deze in een in-memory wachtrij geplaatst, die wacht tot deze wordt verwerkt. Een groot aantal EventData exemplaren in de wachtrij kan leiden tot een zeer hoog geheugengebruik.

Volgende stappen

Als de richtlijnen voor probleemoplossing in dit artikel niet helpen bij het oplossen van problemen wanneer u de Azure SDK voor Java-clientbibliotheken gebruikt, raden we u aan een probleem op te slaan in de Azure SDK voor Java GitHub-opslagplaats.