Ajánlott eljárások a teljesítmény javításához a Service Bus-üzenetkezelés használatával

  • Cikk

Ez a cikk azt ismerteti, hogyan optimalizálhatja a teljesítményt az Azure Service Bus használatával a közvetített üzenetek cseréjekor. A cikk első része a teljesítmény növelését szolgáló különböző mechanizmusokat ismerteti. A második rész útmutatást nyújt a Service Bus olyan módon való használatához, amely egy adott forgatókönyvben a legjobb teljesítményt nyújtja.

Ebben a cikkben az "ügyfél" kifejezés minden olyan entitásra vonatkozik, amely hozzáfér a Service Bushoz. Az ügyfél átveheti a feladó vagy a fogadó szerepkörét. A "feladó" kifejezés egy Service Bus-üzenetsor-ügyfélhez vagy egy service bus-üzenetsorba vagy témakörhöz üzeneteket küldő témakörügyfél esetében használatos. A "fogadó" kifejezés egy Service Bus-üzenetsor-ügyfelet vagy előfizetési ügyfelet jelent, amely üzeneteket fogad egy Service Bus-üzenetsorból vagy egy előfizetésből.

Erőforrás-tervezés és szempontok

Mint minden technikai forráskezelés esetében, a körültekintő tervezés kulcsfontosságú annak biztosításában, hogy az Azure Service Bus az alkalmazás által várt teljesítményt nyújtsa. A Service Bus-névterek megfelelő konfigurációja vagy topológiája számos, az alkalmazásarchitektúrát és a Service Bus-funkciók használatát érintő tényezőtől függ.

Tarifacsomag

A Service Bus különböző tarifacsomagokat kínál. Javasoljuk, hogy válassza ki az alkalmazás követelményeinek megfelelő szintet.

  • Standard szint – Fejlesztői/tesztelési környezetekhez vagy alacsony átviteli sebességű forgatókönyvekhez használható, ahol az alkalmazások nem érzékenyek a szabályozásra.

  • Prémium szint – Olyan éles környezetekhez használható, amelyek eltérő átviteli sebességre vonatkozó követelményekkel rendelkezik, ahol kiszámítható késésre és átviteli sebességre van szükség. Emellett a Service Bus prémium névterei automatikusan skálázhatók, és lehetővé teszik a kiugró átviteli sebességek elhelyezését.

Feljegyzés

Ha a megfelelő szintet nem választja ki, fennáll annak a kockázata, hogy túlterheli a Service Bus névterét, ami szabályozáshoz vezethet.

A szabályozás nem vezet adatvesztéshez. A Service Bus SDK-t használó alkalmazások az alapértelmezett újrapróbálkozési szabályzatot használhatják annak biztosítására, hogy a Service Bus végül elfogadja az adatokat.

A Premium átviteli sebességének kiszámítása

A Service Busnak küldött adatok binárisan szerializálva lesznek, majd deszerializálva lesznek, amikor a fogadó megkapja őket. Így míg az alkalmazások atomi munkaegységként tekintenek az üzenetekre , a Service Bus bájtok (vagy megabájtok) alapján méri az átviteli sebességet.

Az átviteli sebességre vonatkozó követelmény kiszámításakor vegye figyelembe a Service Busnak (bejövő forgalom) küldött adatokat és a Service Bustól (kimenő forgalom) érkező adatokat.

A vártnak megfelelően az átviteli sebesség nagyobb a kisebb, kötegelhető üzenettartalmak esetében.

Teljesítménytesztek

Íme egy GitHub-minta , amelyet a Service Bus-névtérhez kapott várt átviteli sebesség megtekintéséhez futtathat. A teljesítményteszt-tesztek során körülbelül 4 MB/másodpercet figyeltünk meg a bejövő és kimenő forgalom üzenetkezelési egységenként.

A teljesítményértékelési minta nem használ speciális funkciókat, ezért az alkalmazások által megfigyelt átviteli sebesség a forgatókönyvek alapján eltérő.

Számítási szempontok

Bizonyos Service Bus-funkciók használatához olyan számítási kihasználtság szükséges, amely csökkentheti a várt átviteli sebességet. Ezen funkciók némelyike a következők:

  1. Ülés.
  2. Több előfizetést is ki lehet kapcsolni egyetlen témakörből.
  3. Több szűrő futtatása egyetlen előfizetésen.
  4. Ütemezett üzenetek.
  5. Halasztott üzenetek.
  6. Tranzakciók.
  7. Deduplikáció & visszatekintési időablak.
  8. Továbbítás (továbbítás az egyik entitásból a másikba).

Ha az alkalmazás a fenti funkciók bármelyikét használja, és nem kapja meg a várt átviteli sebességet, áttekintheti a processzorhasználati metrikákat, és megfontolhatja a Service Bus Premium-névtér felskálázását.

Az Azure Monitor használatával automatikusan skálázhatja a Service Bus-névteret.

Horizontális skálázás a névterek között

Bár a névtérhez rendelt számítási (üzenetkezelési egységek) horizontális felskálázása egyszerűbb megoldás, előfordulhat, hogy nem biztosít lineáris növekedést az átviteli sebességben. Ennek oka a Service Bus belső részei (tároló, hálózat stb.), amelyek korlátozhatják az átviteli sebességet.

Ebben az esetben a tisztább megoldás az entitások (üzenetsorok és témakörök) különböző Service Bus Premium-névterek közötti skálázása. Megfontolhatja a különböző Azure-régiók különböző névtereinek skálázását is.

Protokollok

A Service Bus három protokoll egyikével teszi lehetővé az ügyfelek számára az üzenetek küldését és fogadását:

  1. Advanced Message Queueing Protocol (AMQP)
  2. Service Bus Messaging Protocol (SBMP)
  3. Hypertext Transfer Protocol (HTTP)

Az AMQP a leghatékonyabb, mivel fenntartja a Service Bushoz való kapcsolatot. A kötegelést és az előkezelést is implementálja. Ha nem említettük kifejezetten, a cikkben szereplő összes tartalom feltételezi az AMQP vagy az SBMP használatát.

Fontos

Az SBMP protokoll csak .NET-keretrendszer érhető el. Az AMQP a .NET Standard alapértelmezett beállítása.

2026. szeptember 30-án megszüntetjük az Azure Service Bus SBMP protokolljának támogatását, így 2026. szeptember 30-tól már nem fogja tudni használni ezt a protokollt. Migrálás a legújabb Azure Service Bus SDK-kódtárakba az AMQP protokoll használatával, amely kritikus biztonsági frissítéseket és továbbfejlesztett képességeket kínál ezen dátum előtt.

További információkért lásd a támogatási nyugdíjazási bejelentést.

A megfelelő Service Bus .NET SDK kiválasztása

A Azure.Messaging.ServiceBus csomag a legújabb Azure Service Bus .NET SDK, amely 2020 novemberétől érhető el. Két régebbi .NET SDK létezik, amelyek 2026. szeptember 30-ig továbbra is kritikus hibajavításokat kapnak, de határozottan javasoljuk, hogy inkább a legújabb SDK-t használja. A régebbi SDK-król való áttérésről a migrálási útmutatóban olvashat.

NuGet-csomag Elsődleges névterek Minimális platformok Protokollok
Azure.Messaging.ServiceBus (legújabb) Azure.Messaging.ServiceBus
Azure.Messaging.ServiceBus.Administration		 .NET Core 2.0
.NET-keretrendszer 4.6.1-es verziója
Mono 5.4
Univerzális Windows-platform 10.0.16299		 AMQP
HTTP
Microsoft.Azure.ServiceBus Microsoft.Azure.ServiceBus
Microsoft.Azure.ServiceBus.Management		 .NET Core 2.0
.NET-keretrendszer 4.6.1-es verziója
Mono 5.4
Univerzális Windows-platform 10.0.16299		 AMQP
HTTP

A .NET Standard platform minimális támogatásáról további információt a .NET implementálási támogatásában talál.

2026. szeptember 30-án kivonjuk az Azure Service Bus SDK-kódtárakat a WindowsAzure.ServiceBus, a Microsoft.Azure.ServiceBus és a com.microsoft.azure.servicebus kódtárakból, amelyek nem felelnek meg az Azure SDK irányelveinek. Az SBMP protokoll támogatását is megszüntetjük, így 2026. szeptember 30. után már nem használhatja ezt a protokollt. Migrálás a legújabb Azure SDK-kódtárakba, amelyek kritikus fontosságú biztonsági frissítéseket és továbbfejlesztett képességeket kínálnak ezen dátum előtt.

Bár a régebbi kódtárak 2026. szeptember 30-tól továbbra is használhatók, a Microsoft már nem kap hivatalos támogatást és frissítéseket. További információkért lásd a támogatási nyugdíjazási bejelentést.

Gyárak és ügyfelek újrafelhasználása

A szolgáltatással kommunikáló Service Bus-ügyfeleket, például a ServiceBusClientet, a ServiceBusSendert, a ServiceBusReceivert és a ServiceBusProcessort, a függőséginjektáláshoz egyszeri (vagy egyszer példányosított és megosztott) módon kell regisztrálni. A ServiceBusClient regisztrálható a ServiceBusClientBuilderExtensions függőséginjektálásához.

Javasoljuk, hogy az egyes üzenetek elküldése vagy fogadása után ne zárja be vagy ne dobja el ezeket az ügyfeleket. Az entitásspecifikus objektumok (ServiceBusSender/Receiver/Processor) bezárása vagy eltávolítása a Service Bus szolgáltatásra mutató hivatkozás megszakadását eredményezi. A ServiceBusClient eltávolításával megszakad a Kapcsolat a Service Bus szolgáltatással.

Ez az útmutató nem vonatkozik a ServiceBusSessionReceiverre, mivel élettartama megegyezik a munkamenetéval. A vele ServiceBusSessionReceiverdolgozó alkalmazások esetében ajánlott az egyes munkamenetek egy-egy példányának ServiceBusClient használata, amely az adott munkamenethez kötött új ServiceBusSessionReceiver munkamenetre terjed ki. Miután az alkalmazás befejezte a munkamenet feldolgozását, el kell helyeznie a kapcsolódót ServiceBusSessionReceiver.

Az alábbi megjegyzés az összes SDK-ra vonatkozik:

Feljegyzés

A kapcsolat létrehozása költséges művelet, amelyet elkerülhet, ha ugyanazt a gyár- vagy ügyfélobjektumot használja újra több művelethez. Ezeket az ügyfélobjektumokat biztonságosan használhatja egyidejű aszinkron műveletekhez és több szálból.

Egyidejű műveletek

Az olyan műveletek, mint például a küldés, fogadás, törlés stb., eltarthatnak egy ideig. Ez az idő magában foglalja a Service Bus szolgáltatás által a művelet feldolgozásához szükséges időt, valamint a kérés és a válasz késését. Az egyes műveletek számának növeléséhez a műveleteket egyidejűleg kell végrehajtani.

Az ügyfél egyidejű műveleteket ütemez aszinkron műveletek végrehajtásával. A következő kérés az előző kérés befejezése előtt indul el. Az alábbi kódrészlet egy aszinkron küldési művelet példája:

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");

Az alábbi kód egy aszinkron fogadási művelet példája.

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();

Fogadási mód

Üzenetsor- vagy előfizetés-ügyfél létrehozásakor megadhatja a fogadási módot: Betekintő zárolás vagy Fogadás és törlés. Az alapértelmezett fogadási mód a következő PeekLock: . Ha az alapértelmezett módban működik, az ügyfél kérést küld a Service Bustól érkező üzenet fogadására. Miután az ügyfél megkapta az üzenetet, egy kérést küld az üzenet befejezésére.

A fogadási mód ReceiveAndDeletebeállításakor a rendszer mindkét lépést egyetlen kérelemben egyesíti. Ezek a lépések csökkentik a műveletek teljes számát, és javíthatják az üzenetek teljes átviteli sebességét. Ez a teljesítménynövekedés az üzenetek elvesztésének kockázatával jár.

A Service Bus nem támogatja a fogadási és törlési műveletek tranzakcióit. Emellett minden olyan forgatókönyv esetében szükség van a betekintő-zárolás szemantikára, amelyben az ügyfél el szeretné halasztani vagy elhalványíthatja az üzenetet.

Prefetching

Az előkezelés lehetővé teszi, hogy az üzenetsor- vagy előfizetés-ügyfél további üzeneteket töltsön be a szolgáltatásból, amikor üzeneteket fogad. Az ügyfél ezeket az üzeneteket egy helyi gyorsítótárban tárolja. A gyorsítótár méretét a tulajdonságok határozzák meg ServiceBusReceiver.PrefetchCount . Minden olyan ügyfél, amely engedélyezi az előkezelést, saját gyorsítótárat tart fenn. A gyorsítótár nincs megosztva az ügyfelek között. Ha az ügyfél elindít egy fogadási műveletet, és a gyorsítótára üres, a szolgáltatás üzenetek kötegét továbbítja. Ha az ügyfél elindít egy fogadási műveletet, és a gyorsítótár tartalmaz egy üzenetet, az üzenet a gyorsítótárból származik.

Ha egy üzenet elő van véve, a szolgáltatás zárolja az előre beszúrt üzenetet. A zárolással az előre befoglalt üzenetet nem fogadhatja egy másik fogadó. Ha a fogadó nem tudja befejezni az üzenetet a zárolás lejárta előtt, az üzenet elérhetővé válik más fogadók számára. Az üzenet előre bemásolt másolata a gyorsítótárban marad. A lejárt gyorsítótárazott másolatot használó fogadó kivételt kap, amikor megpróbálja befejezni az üzenetet. Alapértelmezés szerint az üzenet zárolása 60 másodperc után lejár. Ez az érték 5 percre meghosszabbítható. A lejárt üzenetek használatának megakadályozása érdekében állítsa be a gyorsítótár méretét kisebbre, mint az ügyfél által a zárolási időkorláton belül használható üzenetek száma.

Ha az alapértelmezett 60 másodperces zárolási lejáratot használja, a jó érték PrefetchCount a gyár összes fogadójának maximális feldolgozási sebességének 20-szorosa. Egy gyár például három fogadót hoz létre, és minden fogadó másodpercenként legfeljebb 10 üzenetet képes feldolgozni. Az előcsatornaszám nem haladhatja meg a 20 X 3 X 10 = 600 értéket. Alapértelmezés szerint PrefetchCount 0 értékre van állítva, ami azt jelenti, hogy a szolgáltatás nem hív le további üzeneteket.

Az előjegyzési üzenetek növelik az üzenetsorok vagy előfizetések teljes átviteli sebességét, mivel csökkenti az üzenetműveletek vagy a körutazások teljes számát. Az első üzenet beolvasása azonban tovább tart (a megnövekedett üzenetméret miatt). Az előre beírt üzenetek fogadása a gyorsítótárból gyorsabb, mert az ügyfél már letöltötte ezeket az üzeneteket.

Az üzenet élettartam (TTL) tulajdonságát a kiszolgáló akkor ellenőrzi, amikor a kiszolgáló elküldi az üzenetet az ügyfélnek. Az ügyfél nem ellenőrzi az üzenet TTL tulajdonságát az üzenet fogadásakor. Ehelyett az üzenet akkor is fogadható, ha az üzenet TTL-jét az ügyfél gyorsítótárazza.

Az előkezelés nem befolyásolja a számlázható üzenetküldési műveletek számát, és csak a Service Bus ügyfélprotokollhoz érhető el. A HTTP protokoll nem támogatja az előkezelést. Az előkezelés szinkron és aszinkron fogadási műveletekhez is elérhető.

További információkért tekintse meg a következő PrefetchCount tulajdonságokat:

Ezeknek a tulajdonságoknak az értékeit a ServiceBusReceiverOptionsban vagy a ServiceBusProcessorOptionsban állíthatja be.

Előkezelés és ReceiveMessagesAsync

Bár a több üzenet előkezelésének fogalmai hasonló szemantikával rendelkeznek a kötegben lévő üzenetek feldolgozásához (ReceiveMessagesAsync), van néhány kisebb különbség, amelyet szem előtt kell tartani e megközelítések együttes használatakor.

A prefetch egy konfiguráció (vagy mód) a ServiceBusReceiveren, és ReceiveMessagesAsync egy művelet (amely kérelem-válasz szemantikával rendelkezik).

E megközelítések együttes használata során vegye figyelembe a következő eseteket:

  • Az előbetöltésnek nagyobbnak vagy egyenlőnek kell lennie, mint a várt ReceiveMessagesAsyncüzenetek száma.
  • Az előkezelés legfeljebb a másodpercenként feldolgozott üzenetek számának n/3-szorosa lehet, ahol n az alapértelmezett zárolási időtartam.

Van néhány kihívás a kapzsi megközelítéssel, vagyis az előbetöltések számának magas tartásával, mivel ez azt jelenti, hogy az üzenet egy adott fogadóhoz van zárolva. Javasoljuk, hogy próbálja ki a korábban említett küszöbértékek közötti előbetöltési értékeket, és határozza meg, hogy mi illik hozzá.

Több üzenetsor vagy témakör

Ha egyetlen üzenetsor vagy témakör nem tudja kezelni a várt számú üzenetet, használjon több üzenettovábbítási entitást. Ha több entitást használ, hozzon létre egy dedikált ügyfelet minden entitáshoz, ahelyett, hogy ugyanazt az ügyfelet használja az összes entitáshoz.

A további üzenetsorok vagy témakörök azt jelentik, hogy az üzembe helyezéskor több entitást kell kezelnie. A méretezhetőség szempontjából valójában nincs túl sok különbség, amit észrevehet, mivel a Service Bus már több naplóra is szétterjed belsőleg, így ha hat üzenetsort vagy témakört használ, vagy két üzenetsort vagy témakört használ, az nem fog lényeges különbséget tenni.

A használt szolgáltatási szint hatással van a teljesítmény kiszámíthatóságára. Ha a Standard szintet választja, az átviteli sebesség és a késés a legjobb megoldás egy megosztott több-bérlős infrastruktúra esetében. Az ugyanazon a fürtön lévő többi bérlő befolyásolhatja az átviteli sebességet. Ha a Prémium verziót választja, olyan erőforrásokat kap, amelyek kiszámítható teljesítményt nyújtanak, és a több üzenetsor vagy témakör feldolgozva lesz ebből az erőforráskészletből. További információ: Tarifacsomagok.

Particionált névterek

Particionált prémium szintű névterek használata esetén több, alacsonyabb üzenetkezelési egységekkel (MU) rendelkező partíció jobb teljesítményt nyújt egy magasabb termékváltozatú partíción.

Forgatókönyvek

A következő szakaszok a tipikus üzenetkezelési forgatókönyveket ismertetik, és ismertetik az előnyben részesített Service Bus-beállításokat. Az átviteli sebesség kis (kevesebb mint 1 üzenet/másodperc), közepes (1 üzenet/másodperc vagy nagyobb, de 100 üzenet/másodpercnél kisebb) és magas (100 üzenet/másodperc vagy nagyobb) besorolású. Az ügyfelek száma kis (5 vagy kevesebb), mérsékelt (5-nél több, de 20-nál kisebb vagy egyenlő) és nagy (több mint 20) besorolású.

Nagy átviteli sebességű üzenetsor

Cél: Egyetlen üzenetsor átviteli sebességének maximalizálása. A feladók és fogadók száma kicsi.

  • Az üzenetsorba való teljes küldési arány növeléséhez használjon több üzenetgyárat a feladók létrehozásához. Minden feladóhoz használjon aszinkron műveleteket vagy több szálat.
  • Az üzenetsor teljes fogadási arányának növeléséhez használjon több üzenetgyárat fogadók létrehozásához.
  • Használjon aszinkron műveleteket az ügyféloldali kötegelés előnyeinek kihasználásához.
  • Hagyja engedélyezve a kötegelt tárhozzáférést. Ez a hozzáférés növeli az üzenetek üzenetsorba írható teljes sebességét.
  • Állítsa az előcsatornaszámot a gyár összes fogadójának maximális feldolgozási sebességének 20-szorosára. Ez a szám csökkenti a Service Bus ügyfélprotokoll-átviteleinek számát.

Több nagy átviteli sebességű üzenetsor

Cél: Több üzenetsor teljes átviteli sebességének maximalizálása. Az egyes üzenetsorok átviteli sebessége közepes vagy magas.

Ha több üzenetsoron szeretné elérni a maximális átviteli sebességet, használja a felvázolt beállításokat egy üzenetsor átviteli sebességének maximalizálásához. Emellett különböző gyárak használatával hozhat létre olyan ügyfeleket, amelyek különböző üzenetsorokból küldenek vagy fogadnak.

Alacsony késésű üzenetsor

Cél: Az üzenetsor vagy témakör késésének minimalizálása. A feladók és fogadók száma kicsi. Az üzenetsor átviteli sebessége kicsi vagy közepes.

  • Tiltsa le az ügyféloldali kötegelést. Az ügyfél azonnal üzenetet küld.
  • Tiltsa le a kötegelt tárhozzáférést. A szolgáltatás azonnal megírja az üzenetet az áruházba.
  • Ha egyetlen ügyfelet használ, állítsa be az előbetöltések számát a fogadó feldolgozási sebességének 20-szorosára. Ha egyszerre több üzenet is érkezik az üzenetsorba, a Service Bus ügyfélprotokoll egyszerre továbbítja őket. Amikor az ügyfél megkapja a következő üzenetet, az üzenet már a helyi gyorsítótárban van. A gyorsítótárnak kicsinek kell lennie.
  • Ha több ügyfelet használ, állítsa az előmunkák számát 0-ra. A darabszám beállításával a második ügyfél megkapja a második üzenetet, miközben az első ügyfél még mindig az első üzenetet dolgozza fel.

Üzenetsor nagy számú feladóval

Cél: Egy üzenetsor vagy témakör átviteli sebességének maximalizálása nagy számú feladóval. Minden feladó mérsékelt sebességgel küld üzeneteket. A fogadók száma kicsi.

A Service Bus legfeljebb 1000 egyidejű kapcsolatot tesz lehetővé egy üzenetkezelő entitással. Ezt a korlátot a névtér szintjén kell érvényesíteni, és az üzenetsorokat, témaköröket vagy előfizetéseket az egyidejű kapcsolatok névtérenkénti korlátja korlátozza. Üzenetsorok esetén ez a szám meg van osztva a feladók és a fogadók között. Ha mind a 1000 kapcsolatra szükség van a feladók számára, cserélje le az üzenetsort egy témakörre és egy előfizetésre. Egy témakör legfeljebb 1000 egyidejű kapcsolatot fogad el a feladóktól. Az előfizetés további 1000 egyidejű kapcsolatot fogad el a fogadóktól. Ha több mint 1000 egyidejű feladóra van szükség, a feladóknak HTTP-en keresztül kell üzeneteket küldeni a Service Bus protokollba.

Az átviteli sebesség maximalizálásához kövesse az alábbi lépéseket:

  • Ha minden feladó más folyamatban van, folyamatonként csak egyetlen gyárat használjon.
  • Használjon aszinkron műveleteket az ügyféloldali kötegelés előnyeinek kihasználásához.
  • Hagyja engedélyezve a kötegelt tárhozzáférést. Ez a hozzáférés növeli az üzenetek üzenetsorba vagy témakörbe való írásának általános sebességét.
  • Állítsa az előcsatornaszámot a gyár összes fogadójának maximális feldolgozási sebességének 20-szorosára. Ez a szám csökkenti a Service Bus ügyfélprotokoll-átviteleinek számát.

Üzenetsor nagyszámú fogadóval

Cél: Az üzenetsorok vagy előfizetések fogadási arányának maximalizálása nagyszámú fogadóval. Minden fogadó mérsékelt sebességgel fogadja az üzeneteket. A feladók száma kicsi.

A Service Bus legfeljebb 1000 egyidejű kapcsolatot tesz lehetővé egy entitáshoz. Ha egy üzenetsor több mint 1000 fogadót igényel, cserélje le az üzenetsort egy témakörre és több előfizetésre. Minden előfizetés legfeljebb 1000 egyidejű kapcsolatot támogat. Másik lehetőségként a fogadók a HTTP protokollon keresztül érhetik el az üzenetsort.

Az átviteli sebesség maximalizálásához kövesse az alábbi irányelveket:

  • Ha mindegyik fogadó egy másik folyamatban van, folyamatonként csak egyetlen gyárat használjon.
  • A fogadók szinkron vagy aszinkron műveleteket is használhatnak. Az egyes fogadók mérsékelt fogadási sebessége miatt a Teljes kérelem ügyféloldali kötegelése nem befolyásolja a fogadó átviteli sebességét.
  • Hagyja engedélyezve a kötegelt tárhozzáférést. Ez a hozzáférés csökkenti az entitás teljes terhelését. Emellett növeli az üzenetek üzenetsorba vagy témakörbe való írásának általános sebességét is.
  • Állítsa be az előbetöltések számát kis értékre (például PrefetchCount = 10). Ez a szám megakadályozza, hogy a fogadók tétlenek legyenek, míg más fogadók nagy mennyiségű üzenetet gyorsítótáraznak.

Témakör néhány előfizetéssel

Cél: Egy témakör átviteli sebességének maximalizálása néhány előfizetéssel. Számos előfizetés fogad üzenetet, ami azt jelenti, hogy az összes előfizetés összesített fogadási sebessége nagyobb, mint a küldési arány. A feladók száma kicsi. Az előfizetésenkénti fogadók száma kicsi.

Az átviteli sebesség maximalizálásához kövesse az alábbi irányelveket:

  • A témakörbe történő általános küldési arány növeléséhez használjon több üzenetgyárat a feladók létrehozásához. Minden feladóhoz használjon aszinkron műveleteket vagy több szálat.
  • Az előfizetés teljes fogadási arányának növeléséhez használjon több üzenetgyárat fogadók létrehozásához. Minden fogadóhoz használjon aszinkron műveleteket vagy több szálat.
  • Használjon aszinkron műveleteket az ügyféloldali kötegelés előnyeinek kihasználásához.
  • Hagyja engedélyezve a kötegelt tárhozzáférést. Ez a hozzáférés növeli az üzenetek témakörbe írható általános sebességét.
  • Állítsa az előcsatornaszámot a gyár összes fogadójának maximális feldolgozási sebességének 20-szorosára. Ez a szám csökkenti a Service Bus ügyfélprotokoll-átviteleinek számát.

Nagy számú előfizetést tartalmazó témakör

Cél: Egy témakör átviteli sebességének maximalizálása nagy számú előfizetéssel. Számos előfizetés fogad üzenetet, ami azt jelenti, hogy az összes előfizetés összesített fogadási sebessége nagyobb, mint a küldési arány. A feladók száma kicsi. Az előfizetésenkénti fogadók száma kicsi.

A nagy számú előfizetést tartalmazó témakörök általában alacsony általános átviteli sebességet biztosítanak, ha az összes üzenet az összes előfizetéshez van irányítva. Ennek az az oka, hogy minden üzenet sokszor érkezik, és egy témakör összes üzenete és az összes előfizetése ugyanabban a tárolóban van tárolva. A feltételezés az, hogy a feladók és a fogadók száma előfizetésenként kicsi. A Service Bus témakörenként legfeljebb 2000 előfizetést támogat.

Az átviteli sebesség maximalizálásához próbálkozzon az alábbi lépésekkel:

  • Használjon aszinkron műveleteket az ügyféloldali kötegelés előnyeinek kihasználásához.
  • Hagyja engedélyezve a kötegelt tárhozzáférést. Ez a hozzáférés növeli az üzenetek témakörbe írható általános sebességét.
  • Állítsa be az előbetöltések számát az üzenetek fogadásának várható sebességének 20-szorosára. Ez a szám csökkenti a Service Bus ügyfélprotokoll-átviteleinek számát.