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 SDK 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ända 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 bör du använda processEventBatch.

För varje partition anropas återanropet en i taget. 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. Du bör inte kontrollera om återanropet inte har bearbetat några händelser, eller om du bör kontrollera när du har bearbetat ett antal händelser.

Använda LoadBalancingStrategy.BALANCED eller LoadBalancingStrategy.GREEDY

När du använder LoadBalancingStrategy.BALANCEDgör anspråk på EventProcessorClient 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 AMQP-mottagningslänken öppnas placerar den 500 krediter på länken. Förutsatt att varje EventData instans är en länkkredit, EventProcessorClient prefetches 500 EventData instanser. När alla händelser förbrukas lägger processorklienten 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.

Konfigurering prefetchCount kan få prestandakonsekvenser om antalet är för lågt. Varje gång AMQP tar emot länk placerar 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.

Konfigurering prefetchCount kan få prestandakonsekvenser om antalet är för högt. 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 till att lösa problem när du använder Azure SDK för Java-klientbibliotek rekommenderar vi att du skapar ett problem i Azure SDK för Java GitHub-lagringsplatsen.