Rozwiązywanie problemów z wydajnością usługi Azure Event Hubs

Ten artykuł zawiera rozwiązania typowych problemów z wydajnością, które mogą wystąpić podczas korzystania z biblioteki usługi Event Hubs w zestawie Azure SDK dla języka Java. Jeśli szukasz rozwiązań innych typowych problemów, które mogą wystąpić podczas korzystania z usługi Event Hubs, zobacz Rozwiązywanie problemów z usługą Azure Event Hubs.

Używanie metody processEvent lub processEventBatch

Gdy używasz wywołania zwrotnego processEvent, każda instancja EventData wywołuje twój kod. Ten proces działa dobrze z niskim lub umiarkowanym ruchem w centrum zdarzeń.

Jeśli centrum zdarzeń ma duży ruch i oczekuje się wysokiej przepływności, całkowity koszt ciągłego wywoływania callbacka wpływa na wydajność EventProcessorClient. W tym przypadku należy użyć polecenia processEventBatch.

Dla każdej partycji wywołanie zwrotne jest uruchamiane pojedynczo. Wysoki czas przetwarzania w wywołaniu zwrotnym pogarsza wydajność, ponieważ EventProcessorClient nie kontynuuje wypychania zdarzeń w dół ani żądania większej liczby wystąpień EventData z usługi Event Hubs.

Koszty tworzenia punktów kontrolnych

W przypadku korzystania z usługi Azure Blob Storage jako magazynu punktów kontrolnych istnieje koszt sieciowy związany z tworzeniem punktów kontrolnych, ponieważ wysyła żądanie HTTP i czeka na odpowiedź. Ten proces może potrwać do kilku sekund z powodu opóźnienia sieci, wydajności usługi Azure Blob Storage, lokalizacji zasobów itd.

Ustawianie punktów kontrolnych po przetworzeniu każdego EventData wystąpienia pogarsza wydajność ze względu na koszty wykonywania tych żądań HTTP. Nie należy tworzyć punktu kontrolnego, jeśli wywołanie zwrotne nie przetworzyło żadnych zdarzeń, lub należy go utworzyć po przetworzeniu pewnej liczby zdarzeń.

Użyj metody LoadBalancingStrategy.BALANCED lub LoadBalancingStrategy.GREEDY

Gdy używasz LoadBalancingStrategy.BALANCED, EventProcessorClient zajmuje jedną partycję w każdym cyklu równoważenia obciążenia. Jeśli w centrum zdarzeń znajdują się 32 partycje, potrzeba 32 iteracji równoważenia obciążenia, aby przejąć wszystkie partycje. Jeśli użytkownicy wiedzą, że działa określona liczba EventProcessorClient wystąpień, mogą użyć LoadBalancingStrategy.GREEDY, aby zadeklarować ich udział w partycjach w jednym cyklu równoważenia obciążenia.

Aby uzyskać więcej informacji na temat każdej strategii, zobacz LoadBalancingStrategy.java w repozytorium azure-sdk-for-java.

Konfigurowanie prefetchCount

Domyślna wartość prefetch to 500. Po otwarciu linku odbierającego AMQP, umieszcza się na nim 500 kredytów. Zakładając, że każde EventData wystąpienie jest jednym kredytem linku, EventProcessorClient pobiera wstępnie 500 EventData wystąpień. Gdy wszystkie zdarzenia są przetworzone, procesor klienta dodaje do linku 500 kredytów, aby otrzymywać więcej komunikatów. Ten przepływ powtarza się, gdy EventProcessorClient nadal ma własność partycji.

Skonfigurowanie prefetchCount może mieć wpływ na wydajność, jeśli liczba jest zbyt mała. Za każdym razem, gdy łącze odbiorcze AMQP przydziela kredyty, usługa zdalna wysyła ACK. W przypadku scenariuszy o wysokiej przepływności obciążenie związane z tworzeniem tysięcy żądań klientów i zestawów ACL usług może utrudnić wydajność.

Skonfigurowanie prefetchCount może mieć wpływ na wydajność, jeśli liczba jest zbyt wysoka. Kiedy x kredytów jest umieszczonych na linii, usługa Event Hubs wie, że może wysyłać maksymalnie x komunikatów. Gdy każde EventData wystąpienie zostanie odebrane, zostanie umieszczone w kolejce pamięciowej, czekając na przetworzenie. Duża liczba EventData instancji w kolejce może spowodować bardzo wysokie użycie pamięci.

Dalsze kroki

Jeśli wskazówki dotyczące rozwiązywania problemów w tym artykule nie pomogą rozwiązać problemów podczas korzystania z bibliotek klienckich zestawu Azure SDK dla języka Java, zalecamy, aby zgłosić problem w repozytorium Azure SDK for Java w usłudze GitHub.