Najlepsze rozwiązania dotyczące zwiększania wydajności przy użyciu komunikatów usługi Service Bus

  • Artykuł

W tym artykule opisano sposób używania usługi Azure Service Bus do optymalizowania wydajności podczas wymiany komunikatów obsługiwanych przez brokera. W pierwszej części tego artykułu opisano różne mechanizmy zwiększania wydajności. Druga część zawiera wskazówki dotyczące korzystania z usługi Service Bus w sposób, który może zapewnić najlepszą wydajność w danym scenariuszu.

W tym artykule termin "klient" odnosi się do dowolnej jednostki, która uzyskuje dostęp do usługi Service Bus. Klient może przejąć rolę nadawcy lub odbiorcy. Termin "nadawca" jest używany dla klienta kolejki usługi Service Bus lub klienta tematu, który wysyła komunikaty do kolejki usługi Service Bus lub tematu. Termin "receiver" odnosi się do klienta kolejki usługi Service Bus lub klienta subskrypcji, który odbiera komunikaty z kolejki usługi Service Bus lub subskrypcji.

Planowanie i zagadnienia dotyczące zasobów

Podobnie jak w przypadku wszelkich infrastruktury technicznej, rozsądne planowanie ma kluczowe znaczenie w zapewnieniu, że usługa Azure Service Bus zapewnia wydajność oczekiwaną przez aplikację. Właściwa konfiguracja lub topologia przestrzeni nazw usługi Service Bus zależy od wielu czynników obejmujących architekturę aplikacji i sposób użycia poszczególnych funkcji usługi Service Bus.

Warstwa cenowa

Usługa Service Bus oferuje różne warstwy cenowe. Zaleca się wybranie odpowiedniej warstwy dla wymagań aplikacji.

  • Warstwa Standardowa — odpowiednie dla środowisk deweloperskich/testowych lub scenariuszy o niskiej przepływności, w których aplikacje nie są wrażliwe na ograniczanie przepustowości.

  • Warstwa Premium — odpowiednie dla środowisk produkcyjnych z różnymi wymaganiami dotyczącymi przepływności, w których wymagane jest przewidywalne opóźnienie i przepływność. Ponadto przestrzenie nazw usługi Service Bus w warstwie Premium można skalować automatycznie i można je włączyć, aby obsłużyć wzrost przepływności.

Uwaga

Jeśli nie wybrano odpowiedniej warstwy, istnieje ryzyko przeciążenia przestrzeni nazw usługi Service Bus, co może prowadzić do ograniczenia przepustowości.

Ograniczanie przepustowości nie prowadzi do utraty danych. Aplikacje korzystające z zestawu SDK usługi Service Bus mogą korzystać z domyślnych zasad ponawiania prób, aby upewnić się, że dane zostaną ostatecznie zaakceptowane przez usługę Service Bus.

Obliczanie przepływności dla warstwy Premium

Dane wysyłane do usługi Service Bus są serializowane do pliku binarnego, a następnie deserializowane po odebraniu przez odbiornik. W związku z tym aplikacje myślą o komunikatach jako niepodzielnych jednostkach pracy, usługa Service Bus mierzy przepływność pod względem bajtów (lub megabajtów).

Podczas obliczania wymagania dotyczącego przepływności należy wziąć pod uwagę dane wysyłane do usługi Service Bus (ruch przychodzący) i dane odebrane z usługi Service Bus (ruch wychodzący).

Zgodnie z oczekiwaniami przepływność jest wyższa w przypadku mniejszych ładunków komunikatów, które można podzielić na partie.

Testy porównawcze

Oto przykład usługi GitHub, który można uruchomić, aby zobaczyć oczekiwaną przepływność otrzymaną dla przestrzeni nazw usługi Service Bus. W naszych testach porównawczych zaobserwowaliśmy około 4 MB/s na jednostkę obsługi komunikatów (MU) ruchu przychodzącego i wychodzącego.

W przykładzie porównawczym nie są używane żadne zaawansowane funkcje, więc obserwowana przepływność aplikacji różni się w zależności od Twoich scenariuszy.

Zagadnienia dotyczące obliczeń

Korzystanie z niektórych funkcji usługi Service Bus wymaga wykorzystania zasobów obliczeniowych, które mogą zmniejszyć oczekiwaną przepływność. Niektóre z tych funkcji to :

  1. Sesji.
  2. Fanning out to multiple subscriptions on a single topic (Tworzenie fanning out to multiple subscriptions on a single topic).
  3. Uruchamianie wielu filtrów w jednej subskrypcji.
  4. Zaplanowane komunikaty.
  5. Komunikaty odroczone.
  6. Transakcji.
  7. Deduplikacja i patrz wstecz przedział czasu.
  8. Prześlij dalej do (przekazywanie z jednej jednostki do innej).

Jeśli aplikacja używa dowolnej z powyższych funkcji i nie otrzymujesz oczekiwanej przepływności, możesz przejrzeć metryki użycia procesora CPU i rozważyć skalowanie w górę przestrzeni nazw usługi Service Bus Premium.

Możesz również użyć usługi Azure Monitor do automatycznego skalowania przestrzeni nazw usługi Service Bus.

Fragmentowanie między przestrzeniami nazw

Skalowanie w górę zasobów obliczeniowych (jednostek obsługi komunikatów) przydzielonych do przestrzeni nazw jest łatwiejsze, ale może nie zapewnić liniowego wzrostu przepływności. Wynika to z wewnętrznych elementów usługi Service Bus (magazynu, sieci itp.), które mogą ograniczać przepływność.

Rozwiązaniem czystszym w tym przypadku jest fragmentowanie jednostek (kolejek i tematów) w różnych przestrzeniach nazw usługi Service Bus Premium. Możesz również rozważyć fragmentowanie w różnych przestrzeniach nazw w różnych regionach świadczenia usługi Azure.

Protokoły

Usługa Service Bus umożliwia klientom wysyłanie i odbieranie komunikatów za pośrednictwem jednego z trzech protokołów:

  1. Advanced Message Queuing Protocol (AMQP)
  2. Protokół SBMP (Service Bus Messaging Protocol)
  3. Protokół HTTP

Protokół AMQP jest najbardziej wydajny, ponieważ utrzymuje połączenie z usługą Service Bus. Implementuje również przetwarzanie wsadowe i pobieranie wstępne. O ile nie wspomniano jawnie, cała zawartość w tym artykule zakłada użycie protokołu AMQP lub SBMP.

Ważne

Protokół SBMP jest dostępny tylko dla programu .NET Framework. Protokół AMQP jest domyślny dla platformy .NET Standard.

30 września 2026 r. wycofamy obsługę protokołu SBMP dla usługi Azure Service Bus, więc nie będzie można już używać tego protokołu po 30 września 2026 r. Przeprowadź migrację do najnowszych bibliotek zestawu SDK usługi Azure Service Bus przy użyciu protokołu AMQP, który oferuje krytyczne aktualizacje zabezpieczeń i ulepszone możliwości przed tą datą.

Aby uzyskać więcej informacji, zobacz ogłoszenie o wycofaniu pomocy technicznej.

Wybieranie odpowiedniego zestawu SDK platformy .NET usługi Service Bus

Pakiet Azure.Messaging.ServiceBus jest najnowszym zestawem .NET SDK usługi Azure Service Bus dostępnym od listopada 2020 r. Istnieją dwa starsze zestawy SDK platformy .NET, które będą nadal otrzymywać krytyczne poprawki błędów do 30 września 2026 r., ale zdecydowanie zachęcamy do korzystania z najnowszego zestawu SDK. Przeczytaj przewodnik migracji, aby uzyskać szczegółowe informacje na temat przenoszenia ze starszych zestawów SDK.

Pakiet NuGet Podstawowe przestrzenie nazw Minimalne platformy Protokoły
Azure.Messaging.ServiceBus (najnowsza wersja) Azure.Messaging.ServiceBus
Azure.Messaging.ServiceBus.Administration		 .NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
platforma uniwersalna systemu Windows 10.0.16299		 AMQP
HTTP
Microsoft.Azure.ServiceBus Microsoft.Azure.ServiceBus
Microsoft.Azure.ServiceBus.Management		 .NET Core 2.0
.NET Framework 4.6.1
Mono 5.4
platforma uniwersalna systemu Windows 10.0.16299		 AMQP
HTTP

Aby uzyskać więcej informacji na temat minimalnej obsługi platformy .NET Standard, zobacz Obsługa implementacji platformy .NET.

30 września 2026 r. wycofamy biblioteki zestawu SDK usługi Azure Service Bus WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus i com.microsoft.azure.servicebus, które nie są zgodne z wytycznymi dotyczącymi zestawu Azure SDK. Zakończymy również obsługę protokołu SBMP, więc nie będzie można już używać tego protokołu po 30 września 2026 r. Przeprowadź migrację do najnowszych bibliotek zestawu Azure SDK, które oferują krytyczne aktualizacje zabezpieczeń i ulepszone możliwości przed tą datą.

Mimo że starsze biblioteki mogą być nadal używane poza 30 września 2026 r., nie będą już otrzymywać oficjalnej pomocy technicznej i aktualizacji od firmy Microsoft. Aby uzyskać więcej informacji, zobacz ogłoszenie o wycofaniu pomocy technicznej.

Ponowne użycie fabryk i klientów

Klienci usługi Service Bus, którzy wchodzą w interakcję z usługą, takimi jak ServiceBusClient, ServiceBusSender, ServiceBusReceiver i ServiceBusProcessor, powinni być zarejestrowani w celu wstrzyknięcia zależności jako pojedynczetony (lub utworzone raz i udostępnione). Klasy ServiceBusClient można zarejestrować pod kątem wstrzykiwania zależności za pomocą klasy ServiceBusClientBuilderExtensions.

Zalecamy, aby nie zamykać ani usuwać tych klientów po wysłaniu lub odebraniu każdego komunikatu. Zamknięcie lub usunięcie obiektów specyficznych dla jednostki (ServiceBusSender/Receiver/Processor) powoduje usunięcie linku do usługi Service Bus. Usunięcie elementu ServiceBusClient powoduje usunięcie połączenia z usługą Service Bus.

Te wskazówki nie dotyczą usługi ServiceBusSessionReceiver, ponieważ jego okres istnienia jest taki sam jak sama sesja. W przypadku aplikacji pracujących z ServiceBusSessionReceiverprogramem zaleca się użycie pojedynczego ServiceBusClient wystąpienia klasy , aby zaakceptować każdą sesję, która obejmuje nową ServiceBusSessionReceiver granicę tej sesji. Po zakończeniu przetwarzania tej sesji aplikacja powinna usunąć skojarzony element ServiceBusSessionReceiver.

Poniższa uwaga dotyczy wszystkich zestawów SDK:

Uwaga

Nawiązywanie połączenia jest kosztowną operacją, której można uniknąć przez ponowne użycie tych samych obiektów fabrycznych lub klienta dla wielu operacji. Te obiekty klienta można bezpiecznie używać do współbieżnych operacji asynchronicznych i z wielu wątków.

Operacje współbieżne

Operacje, takie jak wysyłanie, odbieranie, usuwanie itd., zajmują trochę czasu. Tym razem obejmuje czas potrzebny usłudze Service Bus na przetworzenie operacji oraz opóźnienie żądania i odpowiedzi. Aby zwiększyć liczbę operacji na czas, operacje muszą być wykonywane współbieżnie.

Klient planuje współbieżne operacje, wykonując operacje asynchroniczne . Następne żądanie zostanie uruchomione przed ukończeniem poprzedniego żądania. Poniższy fragment kodu jest przykładem asynchronicznej operacji wysyłania:

var messageOne = new ServiceBusMessage(body);
var messageTwo = new ServiceBusMessage(body);

var sendFirstMessageTask =
    sender.SendMessageAsync(messageOne).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #1");
    });
var sendSecondMessageTask =
    sender.SendMessageAsync(messageTwo).ContinueWith(_ =>
    {
        Console.WriteLine("Sent message #2");
    });

await Task.WhenAll(sendFirstMessageTask, sendSecondMessageTask);
Console.WriteLine("All messages sent");

Poniższy kod jest przykładem asynchronicznej operacji odbierania.

var client = new ServiceBusClient(connectionString);
var options = new ServiceBusProcessorOptions 
{

      AutoCompleteMessages = false,
      MaxConcurrentCalls = 20
};
await using ServiceBusProcessor processor = client.CreateProcessor(queueName,options);
processor.ProcessMessageAsync += MessageHandler;
processor.ProcessErrorAsync += ErrorHandler;

static Task ErrorHandler(ProcessErrorEventArgs args)
{
    Console.WriteLine(args.Exception);
    return Task.CompletedTask;
};

static async Task MessageHandler(ProcessMessageEventArgs args)
{
    Console.WriteLine("Handle message");
    await args.CompleteMessageAsync(args.Message);
}

await processor.StartProcessingAsync();

Tryb odbierania

Podczas tworzenia klienta kolejki lub subskrypcji można określić tryb odbierania: Podgląd blokady lub odbierania i usuwania. Domyślnym trybem odbierania jest PeekLock. W przypadku działania w trybie domyślnym klient wysyła żądanie otrzymania komunikatu z usługi Service Bus. Po odebraniu komunikatu klient wysyła żądanie ukończenia komunikatu.

Podczas ustawiania trybu odbierania na ReceiveAndDeletewartość oba kroki są łączone w jednym żądaniu. Te kroki zmniejszają ogólną liczbę operacji i mogą zwiększyć ogólną przepływność komunikatów. Ten wzrost wydajności wiąże się z ryzykiem utraty komunikatów.

Usługa Service Bus nie obsługuje transakcji dotyczących operacji odbierania i usuwania. Ponadto semantyka wglądu w blokadę jest wymagana w przypadku wszystkich scenariuszy, w których klient chce odroczyć lub utracony komunikat .

Prefetching

Wstępne pobieranie umożliwia klientowi kolejki lub subskrypcji ładowanie dodatkowych komunikatów z usługi po odebraniu komunikatów. Klient przechowuje te komunikaty w lokalnej pamięci podręcznej. Rozmiar pamięci podręcznej zależy od ServiceBusReceiver.PrefetchCount właściwości. Każdy klient, który umożliwia pobieranie wstępne, zachowuje własną pamięć podręczną. Pamięć podręczna nie jest udostępniana między klientami. Jeśli klient uruchamia operację odbierania, a jego pamięć podręczna jest pusta, usługa przesyła partię komunikatów. Jeśli klient uruchamia operację odbierania, a pamięć podręczna zawiera komunikat, komunikat zostanie pobrany z pamięci podręcznej.

Po wstępnym pobraniu komunikatu usługa blokuje wstępnie pobrany komunikat. W przypadku blokady pobrany wstępnie komunikat nie może zostać odebrany przez inny odbiornik. Jeśli odbiorca nie może ukończyć komunikatu przed wygaśnięciem blokady, komunikat stanie się dostępny dla innych odbiorców. Pobrana wstępnie kopia komunikatu pozostaje w pamięci podręcznej. Odbiorca, który korzysta z wygasłej kopii w pamięci podręcznej, otrzymuje wyjątek podczas próby ukończenia tego komunikatu. Domyślnie blokada komunikatu wygasa po 60 sekundach. Tę wartość można przedłużyć do 5 minut. Aby zapobiec użyciu wygasłych komunikatów, ustaw rozmiar pamięci podręcznej mniejszy niż liczba komunikatów, które klient może używać w przedziale czasu blokady.

Jeśli używasz domyślnego wygaśnięcia blokady wynoszącego 60 sekund, dobra wartość PrefetchCount parametru to 20-krotny maksymalny współczynnik przetwarzania wszystkich odbiorników fabryki. Na przykład fabryka tworzy trzy odbiorniki, a każdy odbiornik może przetwarzać maksymalnie 10 komunikatów na sekundę. Liczba prefetch nie powinna przekraczać 20 X 3 X 10 = 600. Domyślnie PrefetchCount ustawiono wartość 0, co oznacza, że żadne dodatkowe komunikaty nie są pobierane z usługi.

Wstępne pobieranie komunikatów zwiększa ogólną przepływność kolejki lub subskrypcji, ponieważ zmniejsza ogólną liczbę operacji komunikatów lub rund. Pobieranie pierwszego komunikatu trwa jednak dłużej (ze względu na zwiększony rozmiar komunikatu). Odbieranie wstępnie pobranych komunikatów z pamięci podręcznej jest szybsze, ponieważ te komunikaty zostały już pobrane przez klienta.

Właściwość time-to-live (TTL) komunikatu jest sprawdzana przez serwer w czasie, gdy serwer wysyła komunikat do klienta. Klient nie sprawdza właściwości TTL komunikatu po odebraniu komunikatu. Zamiast tego komunikat może zostać odebrany nawet wtedy, gdy czas wygaśnięcia komunikatu został przekazany podczas buforowania komunikatu przez klienta.

Pobieranie wstępne nie ma wpływu na liczbę rozliczanych operacji obsługi komunikatów i jest dostępne tylko dla protokołu klienta usługi Service Bus. Protokół HTTP nie obsługuje pobierania wstępnego. Pobieranie wstępne jest dostępne zarówno dla synchronicznych, jak i asynchronicznych operacji odbierania.

Aby uzyskać więcej informacji, zobacz następujące PrefetchCount właściwości:

Wartości tych właściwości można ustawić w polach ServiceBusReceiverOptions lub ServiceBusProcessorOptions.

Pobieranie wstępne i funkcja ReceiveMessagesAsync

Chociaż koncepcje wstępnego pobierania wielu komunikatów razem mają podobne semantyka przetwarzania komunikatów w partii (ReceiveMessagesAsync), istnieją pewne drobne różnice, które należy wziąć pod uwagę podczas używania tych podejść razem.

Prefetch to konfiguracja (lub tryb) w usłudze ServiceBusReceiver i ReceiveMessagesAsync jest operacją (która ma semantyka żądań-odpowiedzi).

Podczas używania tych podejść należy wziąć pod uwagę następujące przypadki:

  • Pobieranie wstępne powinno być większe lub równe liczbie komunikatów, które mają zostać odebrane z ReceiveMessagesAsyncusługi .
  • Pobieranie wstępne może wynosić do n/3 razy więcej niż liczba przetworzonych komunikatów na sekundę, gdzie n jest domyślnym czasem trwania blokady.

Istnieją pewne wyzwania związane z chciwym podejściem, czyli utrzymywanie dużej liczby przedwychodów, ponieważ oznacza to, że komunikat jest zablokowany dla określonego odbiornika. Zalecamy wypróbowanie wartości pobierania wstępnego, które znajdują się między progami wymienionymi wcześniej, i zidentyfikowanie pasujących wartości.

Wiele kolejek lub tematów

Jeśli jedna kolejka lub temat nie może obsłużyć oczekiwanej liczby komunikatów, użyj wielu jednostek obsługi komunikatów. W przypadku korzystania z wielu jednostek utwórz dedykowanego klienta dla każdej jednostki, zamiast używać tego samego klienta dla wszystkich jednostek.

Więcej kolejek lub tematów oznacza, że masz więcej jednostek do zarządzania w czasie wdrażania. Z perspektywy skalowalności naprawdę nie ma zbyt wiele różnicy, które można zauważyć, ponieważ usługa Service Bus już rozkłada obciążenie między wiele dzienników wewnętrznie, więc jeśli używasz sześciu kolejek lub tematów lub dwóch kolejek lub tematów, nie będzie miało istotnej różnicy.

Warstwa usługi, której używasz, ma wpływ na przewidywalność wydajności. W przypadku wybrania warstwy Standardowa przepływność i opóźnienie są najlepszym rozwiązaniem w przypadku współużytkowanej infrastruktury wielodostępnej. Inne dzierżawy w tym samym klastrze mogą mieć wpływ na przepływność. Jeśli wybierzesz pozycję Premium, uzyskasz zasoby, które zapewniają przewidywalną wydajność, a wiele kolejek lub tematów jest przetwarzanych z tej puli zasobów. Aby uzyskać więcej informacji, zobacz Warstwy cenowe.

Partycjonowane przestrzenie nazw

W przypadku korzystania z partycjonowanych przestrzeni nazw warstwy Premium wiele partycji z niższymi jednostkami obsługi komunikatów (MU) zapewnia lepszą wydajność w ramach jednej partycji z wyższymi jednostkami MU.

Scenariusze

W poniższych sekcjach opisano typowe scenariusze obsługi komunikatów i opisano preferowane ustawienia usługi Service Bus. Współczynniki przepływności są klasyfikowane jako małe (mniejsze niż 1 komunikat/sekundę), umiarkowane (1 komunikat/sekundę lub większy, ale mniejsze niż 100 komunikatów/sekundę) i wysokie (100 komunikatów/sekundę lub więcej). Liczba klientów jest klasyfikowana jako mała (5 lub mniejsza), umiarkowana (więcej niż 5, ale mniejsza lub równa 20) i duża (więcej niż 20).

Kolejka o wysokiej przepływności

Cel: Maksymalizuj przepływność pojedynczej kolejki. Liczba nadawców i odbiorców jest niewielka.

  • Aby zwiększyć ogólną szybkość wysyłania do kolejki, użyj wielu fabryk komunikatów, aby utworzyć nadawców. Dla każdego nadawcy użyj operacji asynchronicznych lub wielu wątków.
  • Aby zwiększyć ogólną szybkość odbierania z kolejki, użyj wielu fabryk komunikatów, aby utworzyć odbiorniki.
  • Użyj operacji asynchronicznych, aby korzystać z przetwarzania wsadowego po stronie klienta.
  • Pozostaw włączony dostęp do magazynu wsadowego. Ten dostęp zwiększa ogólną szybkość zapisywania komunikatów w kolejce.
  • Ustaw liczbę prefetch na 20 razy maksymalną liczbę procesorów wszystkich odbiorników fabryki. Ta liczba zmniejsza liczbę transmisji protokołu klienta usługi Service Bus.

Wiele kolejek o wysokiej przepływności

Cel: Maksymalizuj ogólną przepływność wielu kolejek. Przepływność pojedynczej kolejki jest umiarkowana lub wysoka.

Aby uzyskać maksymalną przepływność w wielu kolejkach, użyj ustawień opisanych w celu zmaksymalizowania przepływności pojedynczej kolejki. Ponadto użyj różnych fabryk, aby utworzyć klientów, którzy wysyłają lub odbierają z różnych kolejek.

Kolejka o małych opóźnieniach

Cel: minimalizuj opóźnienie kolejki lub tematu. Liczba nadawców i odbiorców jest niewielka. Przepływność kolejki jest mała lub umiarkowana.

  • Wyłącz przetwarzanie wsadowe po stronie klienta. Klient natychmiast wysyła komunikat.
  • Wyłącz dostęp do magazynu wsadowego. Usługa natychmiast zapisuje komunikat w magazynie.
  • W przypadku korzystania z pojedynczego klienta ustaw liczbę pobierania wstępnego na 20 razy szybkość przetwarzania odbiornika. Jeśli jednocześnie do kolejki dociera wiele komunikatów, protokół klienta usługi Service Bus przesyła je w tym samym czasie. Gdy klient otrzyma następny komunikat, komunikat znajduje się już w lokalnej pamięci podręcznej. Pamięć podręczna powinna być mała.
  • W przypadku korzystania z wielu klientów ustaw liczbę prefetch na 0. Ustawiając liczbę, drugi klient może otrzymać drugi komunikat, podczas gdy pierwszy klient nadal przetwarza pierwszy komunikat.

Kolejka z dużą liczbą nadawców

Cel: Maksymalizuj przepływność kolejki lub tematu z dużą liczbą nadawców. Każdy nadawca wysyła komunikaty z umiarkowaną szybkością. Liczba odbiorników jest mała.

Usługa Service Bus umożliwia maksymalnie 1000 równoczesnych połączeń z jednostką obsługi komunikatów. Ten limit jest wymuszany na poziomie przestrzeni nazw, a kolejki, tematy lub subskrypcje są ograniczone przez limit współbieżnych połączeń na przestrzeń nazw. W przypadku kolejek ta liczba jest udostępniana między nadawcami i odbiorcami. Jeśli dla nadawców są wymagane wszystkie 1000 połączeń, zastąp kolejkę tematem i jedną subskrypcją. Temat akceptuje maksymalnie 1000 współbieżnych połączeń od nadawców. Subskrypcja akceptuje dodatkowe 1000 równoczesnych połączeń od odbiorników. Jeśli wymagane jest więcej niż 1000 współbieżnych nadawców, nadawcy powinni wysyłać komunikaty do protokołu usługi Service Bus za pośrednictwem protokołu HTTP.

Aby zmaksymalizować przepływność, wykonaj następujące kroki:

  • Jeśli każdy nadawca jest w innym procesie, użyj tylko jednej fabryki na proces.
  • Użyj operacji asynchronicznych, aby korzystać z przetwarzania wsadowego po stronie klienta.
  • Pozostaw włączony dostęp do magazynu wsadowego. Ten dostęp zwiększa ogólną szybkość zapisywania komunikatów w kolejce lub temacie.
  • Ustaw liczbę prefetch na 20 razy maksymalną liczbę procesorów wszystkich odbiorników fabryki. Ta liczba zmniejsza liczbę transmisji protokołu klienta usługi Service Bus.

Kolejka z dużą liczbą odbiorników

Cel: Maksymalizuj szybkość odbierania kolejki lub subskrypcji z dużą liczbą odbiorników. Każdy odbiorca odbiera komunikaty w umiarkowanym tempie. Liczba nadawców jest mała.

Usługa Service Bus umożliwia maksymalnie 1000 równoczesnych połączeń z jednostką. Jeśli kolejka wymaga więcej niż 1000 odbiorników, zastąp kolejkę tematem i wieloma subskrypcjami. Każda subskrypcja może obsługiwać maksymalnie 1000 równoczesnych połączeń. Alternatywnie odbiorniki mogą uzyskiwać dostęp do kolejki za pośrednictwem protokołu HTTP.

Aby zmaksymalizować przepływność, postępuj zgodnie z następującymi wytycznymi:

  • Jeśli każdy odbiornik jest w innym procesie, użyj tylko jednej fabryki na proces.
  • Odbiorniki mogą używać operacji synchronicznych lub asynchronicznych. Biorąc pod uwagę umiarkowaną szybkość odbierania pojedynczego odbiornika, przetwarzanie wsadowe po stronie klienta żądania Complete nie ma wpływu na przepływność odbiornika.
  • Pozostaw włączony dostęp do magazynu wsadowego. Ten dostęp zmniejsza ogólne obciążenie jednostki. Zwiększa również ogólną szybkość zapisywania komunikatów w kolejce lub temacie.
  • Ustaw liczbę prefetch na małą wartość (na przykład PrefetchCount = 10). Ta liczba uniemożliwia odbiornikom bezczynność, podczas gdy inni odbiorcy mają dużą liczbę komunikatów buforowanych.

Temat z kilkoma subskrypcjami

Cel: Maksymalizuj przepływność tematu przy użyciu kilku subskrypcji. Komunikat jest odbierany przez wiele subskrypcji, co oznacza, że łączna stawka odbierania dla wszystkich subskrypcji jest większa niż stawka wysyłania. Liczba nadawców jest mała. Liczba odbiorników na subskrypcję jest niewielka.

Aby zmaksymalizować przepływność, postępuj zgodnie z następującymi wytycznymi:

  • Aby zwiększyć ogólną szybkość wysyłania do tematu, użyj wielu fabryk komunikatów, aby utworzyć nadawców. Dla każdego nadawcy użyj operacji asynchronicznych lub wielu wątków.
  • Aby zwiększyć ogólną szybkość odbierania z subskrypcji, użyj wielu fabryk komunikatów, aby utworzyć odbiorniki. Dla każdego odbiornika użyj operacji asynchronicznych lub wielu wątków.
  • Użyj operacji asynchronicznych, aby korzystać z przetwarzania wsadowego po stronie klienta.
  • Pozostaw włączony dostęp do magazynu wsadowego. Ten dostęp zwiększa ogólną szybkość zapisywania komunikatów w temacie.
  • Ustaw liczbę prefetch na 20 razy maksymalną liczbę procesorów wszystkich odbiorników fabryki. Ta liczba zmniejsza liczbę transmisji protokołu klienta usługi Service Bus.

Temat z dużą liczbą subskrypcji

Cel: Maksymalizuj przepływność tematu z dużą liczbą subskrypcji. Komunikat jest odbierany przez wiele subskrypcji, co oznacza, że łączna stawka odbierania dla wszystkich subskrypcji jest większa niż stawka wysyłania. Liczba nadawców jest mała. Liczba odbiorników na subskrypcję jest niewielka.

Tematy z dużą liczbą subskrypcji zwykle uwidaczniają niską ogólną przepływność, jeśli wszystkie komunikaty są kierowane do wszystkich subskrypcji. Jest to spowodowane tym, że każdy komunikat jest odbierany wiele razy, a wszystkie komunikaty w temacie i wszystkich jego subskrypcjach są przechowywane w tym samym magazynie. Założeniem jest to, że liczba nadawców i liczba odbiorników na subskrypcję jest niewielka. Usługa Service Bus obsługuje maksymalnie 2000 subskrypcji na temat.

Aby zmaksymalizować przepływność, spróbuj wykonać następujące czynności:

  • Użyj operacji asynchronicznych, aby korzystać z przetwarzania wsadowego po stronie klienta.
  • Pozostaw włączony dostęp do magazynu wsadowego. Ten dostęp zwiększa ogólną szybkość zapisywania komunikatów w temacie.
  • Ustaw liczbę pobierania wstępnego na 20 razy oczekiwaną szybkość odbierania komunikatów. Ta liczba zmniejsza liczbę transmisji protokołu klienta usługi Service Bus.