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

W przypadku korzystania z wywołania zwrotnego processEvent każde EventData wystąpienie odebrało wywołanie kodu. 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, zagregowany koszt ciągłego wywoływania zwrotnego utrudnia wydajność EventProcessorClient. W tym przypadku należy użyć polecenia processEventBatch.

Dla każdej partycji wywołanie zwrotne jest wywoływane pojedynczo. Wysoki czas przetwarzania wywołania zwrotnego utrudnia wydajność, ponieważ EventProcessorClient nie powoduje dalszego wypychania większej liczby zdarzeń podrzędnych ani żądania większej liczby EventData wystąpień 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 sieci do tworzenia 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.

Tworzenie punktów kontrolnych po przetworzeniu każdego EventData wystąpienia utrudnia wydajność z powodu kosztów wykonywania tych żądań HTTP. Nie należy sprawdzać punktu kontrolnego, jeśli wywołanie zwrotne nie przetworzyło żadnych zdarzeń lub punkt kontrolny po przetworzeniu pewnej liczby zdarzeń.

Użyj metody LoadBalancingStrategy.BALANCED lub LoadBalancingStrategy.GREEDY

Gdy używasz LoadBalancingStrategy.BALANCEDmetody , oświadczenia jedna partycja EventProcessorClient dla każdego cyklu równoważenia obciążenia. Jeśli w centrum zdarzeń znajduje się 32 partycje, do oświadczeń wszystkich partycji potrzeba 32 iteracji równoważenia obciążenia. Jeśli użytkownicy wiedzą, że jest uruchomiona liczba EventProcessorClient wystąpień, mogą użyć LoadBalancingStrategy.GREEDY ich do oświadczenia udziału partycji 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ść pobierania wstępnego to 500. Po otwarciu linku odbierania protokołu AMQP umieszcza on 500 środków na link. 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ą używane, klient procesora dodaje do linku 500 środkó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 usługa AMQP odbiera środki, 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. Po umieszczeniu x środków w wierszu usługa Event Hubs wie, że może wysyłać co najwyżej x komunikatów. Gdy każde EventData wystąpienie zostanie odebrane, zostanie umieszczone w kolejce w pamięci, czekając na przetworzenie. Duża liczba EventData wystąpień w kolejce może spowodować bardzo wysokie użycie pamięci.

Następne 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 zgłoszenie problemuw repozytorium GitHub zestawu Azure SDK dla języka Java.