Ř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ě použijte 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ů. Nevytvářejte kontrolní bod, pokud vaše zpětné volání nezpracovalo žádné události, nebo jej vytvořte 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ž klient procesoru událostí zpracuje všechny události, přidá ke spojení 500 kreditů, aby mohl přijímat další zprávy. Tento tok se opakuje, zatímco EventProcessorClient má stále vlastnictví oddílu.

Nastavení prefetchCount na příliš nízkou hodnotu může ovlivnit výkon. Pokaždé, když přijímací odkaz AMQP přidělí kredity, vzdálená služba odešle potvrzení. Ve scénářích s vysokou propustností mohou režijní náklady spojené s odesíláním tisíců klientských požadavků a potvrzení služby (ACK) snižovat výkon.

Nastavení prefetchCount příliš vysoké může mít vliv na výkon. 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 k řešení potíží v tomto článku nepomáhají vyřešit problémy při použití Azure SDK pro Java klientských knihoven, založte problém v Azure SDK pro úložiště Java GitHub.