Ř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žijte processEvent nebo processEventBatch

Když použijete processEvent zpětné volání, každá přijatá EventData instance volá váš kód. 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 je funkce zpětného volání vyvolána samostatně. Vysoká doba zpracování v callbacku omezuje výkon, protože EventProcessorClient neposílá více událostí směrem dolů ani nežádá více EventData instancí ze služby Event Hubs.

Náklady kontrolních bodů

Pokud používáte Azure Blob Storage jako úložiště pro kontrolní body, existují síťové náklady na kontrolní body, protože vytváří HTTP požadavek a čeká na jeho 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 způsobuje pokles výkonu kvůli nákladům spojeným s prováděním těchto HTTP požadavků. Neměli byste kontrolovat kontrolní bod, pokud vaše zpětné volání nezpracovalo žádné události, nebo byste měli kontrolovat kontrolní bod po zpracování určitého počtu událostí.

Použijte LoadBalancingStrategy.BALANCED nebo LoadBalancingStrategy.GREEDY

Při použití LoadBalancingStrategy.BALANCED si EventProcessorClient nárokuje 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.

Nakonfigurujte 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 představuje jeden kredit propojení, EventProcessorClient načítá předem 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, zatímco EventProcessorClient má stále vlastnictví oddílu.

Konfigurace prefetchCount může mít vliv na výkon, pokud je číslo příliš nízké. Pokaždé, když přijímací odkaz AMQP přidělí kredity, vzdálená služba odešle potvrzení. U scénářů s vysokou propustností mohou náklady na vytváření tisíců požadavků klientů a potvrzení služeb omezovat výkon.

Konfigurace prefetchCount může mít vliv na výkon, pokud je číslo příliš vysoké. Když jsou x credits umístěny na řádku, služba Event Hubs ví, že může odeslat maximálně x zpráv. Při přijetí každé EventData instance se umístí do fronty v paměti, kde č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 pro řešení potíží v tomto článku nepomohly vyřešit problémy při používání klientských knihoven Azure SDK pro Java, doporučujeme nahlásit problém v úložišti Azure SDK pro Java na GitHubu.