Felsöka Prestanda för Azure Event Hubs

Den här artikeln innehåller lösningar på vanliga prestandaproblem som kan uppstå när du använder Event Hubs-biblioteket i Azure SDKs för Java. Om du letar efter lösningar på andra vanliga problem som du kan stöta på när du använder Event Hubs kan du läsa Felsöka Azure Event Hubs.

Använd processEvent eller processEventBatch

När du använder återanropet processEvent anropar varje EventData instans din kod. Den här processen fungerar bra med låg eller måttlig trafik i händelsehubben.

Om händelsehubben har hög trafik och högt dataflöde förväntas, hindrar den aggregerade kostnaden för att kontinuerligt anropa återanropet prestanda för EventProcessorClient. I det här fallet använder du processEventBatch.

För varje partition anropas callbackfunktionen en åt gången. Hög bearbetningstid i återanropet hindrar prestanda eftersom EventProcessorClient inte fortsätter att skicka fler händelser nedströms eller begär fler EventData instanser från Event Hubs-tjänsten.

Kostnader för kontrollpunkter

När du använder Azure Blob Storage som kontrollpunktsarkiv finns det en nätverkskostnad för kontrollpunkter eftersom den gör en HTTP-begäran och väntar på ett svar. Den här processen kan ta upp till flera sekunder på grund av nätverksfördröjning, prestanda för Azure Blob Storage, resursplats och så vidare.

Kontrollpunkter när varje EventData instans har bearbetats hindrar prestanda på grund av kostnaden för att göra dessa HTTP-begäranden. Skapa inte en kontrollpunkt om återanropet inte har bearbetat några händelser, eller skapa en kontrollpunkt efter att ett visst antal händelser har bearbetats.

Använd LoadBalancingStrategy.BALANCED eller LoadBalancingStrategy.GREEDY

När du använder LoadBalancingStrategy.BALANCED gör EventProcessorClient anspråk på en partition för varje belastningsutjämningscykel. Om det finns 32 partitioner i en händelsehubb krävs 32 iterationer för belastningsutjämning för att göra anspråk på alla partitioner. Om användarna vet att ett visst antal EventProcessorClient instanser körs kan de använda LoadBalancingStrategy.GREEDY för att göra anspråk på sin andel av partitionerna i en belastningsutjämningscykel.

Mer information om varje strategi finns i LoadBalancingStrategy.java på lagringsplatsen azure-sdk-for-java.

Konfigurera prefetchCount

Standardvärdet för prefetch är 500. När mottagningslänken för AMQP öppnas tilldelas länken 500 krediter. Förutsatt att varje EventData exemplar är en länkkredit, förhämtar EventProcessorClient 500 EventData exemplar. När processorklienten använder alla händelser lägger den till 500 krediter till länken för att ta emot fler meddelanden. Det här flödet upprepas medan den EventProcessorClient fortfarande har ägarskap för en partition.

Att ställa in prefetchCount för lågt kan påverka prestandan. Varje gång mottagningslänken i AMQP tilldelar krediter, skickar fjärrtjänsten en ACK. För scenarier med högt dataflöde kan kostnaden för att göra tusentals klientbegäranden och tjänst-ACL:er hindra prestanda.

Att ställa in prefetchCount för högt kan påverka prestandan. När x krediter placeras på raden vet Event Hubs-tjänsten att den kan skicka högst x meddelanden. När varje EventData instans tas emot placeras den i en minnesintern kö som väntar på att bearbetas. Ett stort antal EventData instanser i kön kan resultera i mycket hög minnesanvändning.

Nästa steg

Om felsökningsguiden i den här artikeln inte hjälper dig att lösa problem när du använder Azure SDKs för Java klientbibliotek kan du ange ett problem i Azure SDKs för Java GitHub lagringsplats.