Řešení potíží s výkonem služby Azure Event Hubs

Tento článek obsahuje řešení běžných problémů s výkonem, se kterými se můžete setkat při použití knihovny Event Hubs v sadě Azure SDK pro Javu. Pokud hledáte řešení jiných běžných problémů, se kterými se můžete setkat při používání služby Event Hubs, přečtěte si téma Řešení potíží se službou Azure Event Hubs.

Použití processEvent nebo processEventBatch

Když použijete processEvent zpětné volání, každá EventData instance přijala volání kódu. Tento proces funguje dobře s nízkým nebo středním provozem v centru událostí.

Pokud má centrum událostí vysoký provoz a očekává se vysoká propustnost, agregované náklady na průběžné volání zpětného volání brání výkonu EventProcessorClient. V tomto případě byste měli použít processEventBatch.

Pro každý oddíl se zpětné volání vyvolá po jednom. Vysoká doba zpracování v zpětném volání brání výkonu, protože EventProcessorClient nesdílí více událostí do podřízeného stavu ani nevyžaduje více EventData instancí ze služby Event Hubs.

Náklady na kontrolní body

Pokud jako úložiště kontrolních bodů používáte Azure Blob Storage, stojí za kontrolní body síť, protože vytváří požadavek HTTP a čeká na odpověď. Tento proces může trvat až několik sekund kvůli latenci sítě, výkonu služby Azure Blob Storage, umístění prostředků atd.

Vytváření kontrolních bodů po zpracování každé EventData instance brání výkonu kvůli nákladům na provedení těchto požadavků HTTP. Pokud zpětné volání nezpracovalo žádné události, neměli byste kontrolní bod kontrolovat ani po zpracování některých událostí.

Použití LoadBalancingStrategy.BALANCE nebo LoadBalancingStrategy.GREEDY

Při použití LoadBalancingStrategy.BALANCEDEventProcessorClient deklarace identity jeden oddíl pro každý cyklus vyrovnávání zatížení. Pokud je v centru událostí 32 oddílů, k deklaraci všech oddílů trvá 32 iterací vyrovnávání zatížení. Pokud uživatelé vědí, že je spuštěný nastavený počet EventProcessorClient instancí, můžou použít LoadBalancingStrategy.GREEDY k deklaraci podílu oddílů v jednom cyklu vyrovnávání zatížení.

Další informace o jednotlivých strategiích najdete v tématu LoadBalancingStrategy.java v úložišti azure-sdk-for-java.

Konfigurace prefetchCount

Výchozí hodnota předběžného načtení je 500. Když se otevře odkaz pro příjem AMQP, umístí na něj 500 kreditů. Za předpokladu, že každá EventData instance je jeden kredit propojení, EventProcessorClient předem načte 500 EventData instancí. Když se spotřebují všechny události, klient procesoru přidá na odkaz 500 kreditů, aby dostával další zprávy. Tento tok se opakuje, EventProcessorClient zatímco stále má vlastnictví oddílu.

Konfigurace prefetchCount může mít vliv na výkon, pokud je číslo příliš nízké. Pokaždé, když AMQP obdrží kredity odkazu, vzdálená služba odešle ACK. U scénářů s vysokou propustností může režijní náklady na vytváření tisíců požadavků klientů a sad ACL služeb bránit výkonu.

Konfigurace prefetchCount může mít vliv na výkon, pokud je číslo příliš vysoké. Když se na řádek umístí kredit x , služba Event Hubs ví, že může odesílat maximálně x zpráv. Při přijetí každé EventData instance se umístí do fronty v paměti, která čeká na zpracování. Velký počet EventData instancí ve frontě může vést k velmi vysokému využití paměti.

Další kroky

Pokud pokyny k řešení potíží v tomto článku nepomáhají vyřešit problémy při použití sady Azure SDK pro klientské knihovny Java, doporučujeme vám založit problém v úložišti Azure SDK pro Javu na GitHubu.