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, roept elk ontvangen EventData voorbeeld uw code aan. Dit proces werkt goed met weinig of gemiddeld verkeer in de Event Hub.

Als de Event Hub veel verkeer heeft en een hoge doorvoer wordt verwacht, beïnvloeden de geaggregeerde kosten van 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 bij de callback beïnvloedt de prestaties negatief omdat de EventProcessorClient geen extra gebeurtenissen naar downstream duwt en er ook geen extra EventData exemplaren worden aangevraagd bij de Event Hubs-service.

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.

Het maken van controlepunten na de verwerking van elk EventData-exemplaar hindert de prestaties vanwege de kosten van het maken van deze HTTP-aanvragen. U moet geen controlepunt maken als uw callback geen gebeurtenissen heeft verwerkt, of u moet een controlepunt maken na het verwerken van een aantal gebeurtenissen.

Gebruik LoadBalancingStrategy.BALANCED of LoadBalancingStrategy.GREEDY

Wanneer u LoadBalancingStrategy.BALANCED gebruikt, claimt EventProcessorClient één partitie voor elke balanscyclus. Als er 32 partities in een Event Hub zijn, duurt het 32 iteraties voor taakverdeling om alle partities te claimen. Als gebruikers weten dat er een bepaald aantal EventProcessorClient exemplaren draait, kunnen ze hun aandeel van de partities via LoadBalancingStrategy.GREEDY 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, worden er 500 credits op de koppeling geplaatst. Ervan uitgaande dat elk EventData exemplaar één link-credit is, haalt EventProcessorClient vooraf 500 EventData exemplaren op. Wanneer alle gebeurtenissen zijn verbruikt, voegt de processorclient 500 tegoeden 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-ontvangstlink credits plaatst, verzendt de externe service een bevestiging. 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 het in een in-memory wachtrij geplaatst om te wachten op verwerking. 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 te melden in de Azure SDK voor Java GitHub-repository.