Meilleures pratiques relatives aux améliorations de performances à l’aide de la messagerie Service Bus

Cet article décrit comment utiliser Azure Service Bus pour optimiser les performances lors de l’échange de messages répartis. La première partie de cet article décrit les différents mécanismes pour améliorer les performances. La deuxième partie fournit des conseils sur l’utilisation de Service Bus des services visant à offrir des performances optimales dans un scénario donné.

Dans cet article, le terme « client » fait référence à une entité qui accède à Service Bus. Un client peut jouer le rôle d’un expéditeur ou d’un destinataire. Le terme « expéditeur » est utilisé pour un client de file d’attente ou de rubrique Service Bus qui envoie des messages à une file d’attente ou une rubrique Service Bus. Le terme « destinataire » fait référence à un client de file d’attente ou d’abonnement de Bus de Service qui reçoit des messages de la part d’une file d’attente ou d’un abonnement Service Bus.

Planification et considérations relatives aux ressources

Comme pour toute ressource technique, une planification prudente est essentielle pour garantir qu’Azure Service Bus fournit les performances attendues par votre application. La configuration ou la topologie adéquate pour vos espaces de noms Service Bus dépend d’une multitude de facteurs impliquant l’architecture de votre application et la façon dont chacune des fonctionnalités de Service Bus est utilisée.

Niveau tarifaire

Service Bus propose plusieurs niveaux tarifaires. Il est recommandé de choisir le niveau approprié pour les besoins de votre application.

• Niveau standard : Adapté aux environnements de développement et de test ou aux scénarios à faible débit où les applications ne sont pas sensibles à la limitation.

• Niveau Premium : adapté aux environnements de production avec des exigences de débit variables où la latence et le débit doivent être prévisibles. De plus, les espaces de noms Premium de Service Bus peuvent faire l’objet d’une mise à l’échelle automatique et être activés pour s’adapter aux pics de débit.

Calcul du débit pour le niveau Premium

Les données envoyées à Service Bus sont sérialisées en binaire, puis désérialisées lorsqu’elles sont reçues par le destinataire. Ainsi, tandis que les applications considèrent les messages comme des unités atomiques de travail, Service Bus mesure le débit en octets (ou mégaoctets).

Pour calculer le débit requis, tenez compte des données envoyées à Service Bus (entrée) et des données reçues de Service Bus (sortie).

Comme prévu, le débit est plus élevé lorsque les charges utiles des messages sont plus petites et peuvent être regroupées.

Benchmarks

Voici un exemple GitHub que vous pouvez exécuter pour voir le débit attendu que vous recevez pour votre espace de noms Service Bus. Dans nos tests de point de référence, nous avons observé environ 4 Mo/s par unité de messagerie (MU) d’entrée et de sortie.

L’échantillon de point de référence n’utilise pas de fonctionnalités avancées, le débit observé par vos applications est donc différent selon vos scénarios.

Considérations relatives à la capacité de calcul

Le Service Bus exploite plusieurs processus en arrière-plan qui peuvent affecter l’utilisation des calculs. Ceux-ci incluent, mais ne sont pas limités à, des minuteurs, des planifications et l’émission de métriques. De plus, l’utilisation de certaines fonctionnalités du Service Bus nécessite une utilisation du calcul qui peut diminuer le débit attendu. Voici quelques-unes de ces fonctionnalités :

1. Sessions
2. Extension à plusieurs abonnements sur une même rubrique
3. Exécution de nombreux filtres sur un abonnement unique
4. Messages planifiés
5. Messages reportés
6. Transactions
7. Déduplication et fenêtre de temps des périodes passées.
8. Transfert à (transfert d’une entité à une autre)

Si votre application utilise l’une des fonctionnalités ci-dessus et que vous ne recevez pas le débit attendu, vous pouvez examiner les métriques d’utilisation du processeur et envisager d’effectuer une mise à l’échelle de votre espace de noms Service Bus Premium. Vous pouvez également utiliser Azure Monitor pour mettre automatiquement à l’échelle l’espace de noms Service Bus. Pour garantir des performances optimales, nous recommandons d’augmenter le nombre d’unités de message (MU) lorsque l’utilisation de l’unité centrale dépasse 70 %.

Partitionnement entre les espaces de noms

Bien que le scale-up du calcul (unités de messagerie) alloué à l’espace de noms soit une solution plus facile, il peut ne pas fournir une augmentation linéaire du débit. Cela est dû aux éléments internes de Service Bus (stockage, réseau, etc.) qui peuvent limiter le débit.

Dans ce cas, la solution la plus propre consiste à partition vos entités (files d’attente et rubriques) dans différents espaces de noms Service Bus Premium. Vous pouvez également envisager un partitionnement sur différents espaces de noms dans différentes régions Azure.

Protocoles

Service Bus permet aux clients d’envoyer et de recevoir des messages par le biais de l’un des trois protocoles suivants :

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

AMQP est le plus efficace, car il maintient la connexion à Service Bus. Il implémente également le traitement par lot et la prérécupération. Sauf mention explicite, tout le contenu de cet article suppose l’utilisation du protocole AMQP ou SBMP.

Le 30 septembre 2026, nous mettrons hors service la prise en charge du protocole SBMP pour Azure Service Bus. Vous ne pourrez donc plus utiliser ce protocole après le 30 septembre 2026. Migrez vers les dernières bibliothèques du SDK Azure Service Bus utilisant le protocole AMQP, qui offre des mises à jour de sécurité critiques et des fonctionnalités améliorées, avant cette date.

Pour plus d’informations, consultez l’annonce concernant l’arrêt de la prise en charge.

Choix du Kit de développement logiciel (SDK) .NET Service Bus approprié

Le package Azure.Messaging.ServiceBus est le dernier kit de développement logiciel (SDK) .net Azure Service Bus disponible à partir du 2020 novembre. Il existe deux SDK .NET plus anciens qui continuent de recevoir des correctifs de bogues critiques jusqu’au 30 septembre 2026, mais nous vous encourageons vivement à utiliser à la place le dernier Kit de développement logiciel (SDK). Lisez le Guide de migration pour plus d’informations sur la façon de migrer les anciens SDK.

Pour plus d’informations sur la prise en charge minimale de la plateforme .NET Standard, consultez Prise en charge de l’implémentation .NET.

Le 30 septembre 2026, nous retirerons les bibliothèques WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus et com.microsoft.azure.servicebus du kit de développement logiciel (SDK) Azure Service Bus, qui ne sont pas conformes aux directives du kit de développement logiciel (SDK) Azure. Nous mettrons également fin à la prise en charge du protocole SBMP. Vous ne pourrez donc plus utiliser ce protocole après le 30 septembre 2026. Migrez vers les dernières bibliothèques du kit de développement logiciel (SDK) Azure, qui offre des correctifs de sécurité critiques et des fonctionnalités améliorées, avant cette date.

Bien que les anciennes bibliothèques puissent toujours être utilisées au-delà du 30 septembre 2026, elles ne seront plus prises en charge officiellement et mises à jour par Microsoft. Pour plus d’informations, consultez l’annonce concernant l’arrêt de la prise en charge.

Réutilisation de structures et de clients

La remarque suivante s’applique à tous les kits SDK :

Opérations simultanées

Les opérations telles qu’envoyer, recevoir, supprimer, etc., prennent un certain temps. Ce temps comprend le traitement de l’opération par le service Service Bus et la latence de la requête et de la réponse. Pour augmenter le nombre d’opérations par période, les opérations doivent s’exécuter simultanément.

Le client planifie les opérations parallèles en effectuant des opérations asynchrones. La requête suivante démarre avant la fin de la demande précédente. Voici un exemple d’opération d’envoi asynchrone présenté sous forme d’extrait de code :

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

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

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

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

Voici un exemple d’opération de réception asynchrone présenté sous forme de code.

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

var receiver = new MessageReceiver(connectionString, queueName, ReceiveMode.PeekLock);

static Task LogErrorAsync(Exception exception)
{
    Console.WriteLine(exception);
    return Task.CompletedTask;
};

receiver.RegisterMessageHandler(
    async (message, cancellationToken) =>
    {
        Console.WriteLine("Handle message");
        await receiver.CompleteAsync(message.SystemProperties.LockToken);
    },
    new MessageHandlerOptions(e => LogErrorAsync(e.Exception))
    {
        AutoComplete = false,
        MaxConcurrentCalls = 20
    });

Mode de réception

Lorsque vous créez un client de file d’attente ou d’abonnement, vous pouvez spécifier un mode de réception : Verrouillage ou Recevoir et supprimer. Le mode de réception par défaut est PeekLock. En mode par défaut, le client envoie une requête pour recevoir un message de Service Bus. Une fois que le client a reçu le message, il envoie une demande pour compléter le message.

Si le mode de réception est défini sur ReceiveAndDelete, les deux étapes sont regroupées en une seule requête. Cette étape réduit le nombre total d’opérations et peut améliorer le débit global des messages. Ce gain de performances est fourni au risque de perdre des messages.

Service Bus ne gère pas les transactions des opérations de réception-suppression. En outre, la syntaxe de verrouillage est nécessaire pour tous les scénarios dans lesquels le client souhaite différer ou ignorer un message (lettre morte).

Lecture anticipée

La prérécupération permet au client de la file d’attente ou de l’abonnement de charger des messages supplémentaires à partir du service quand il reçoit des messages. Le client stocke ces messages en mémoire cache. La taille du cache est déterminée par les propriétés ServiceBusReceiver.PrefetchCount. Chaque client qui permet la lecture anticipée gère son propre cache. Un cache n’est pas partagé par plusieurs clients. Si le client initie une opération de réception et que sa mémoire cache est vide, le service transmet un lot de messages. Si le client initie une opération de réception et que le cache contient un message, ce dernier est extrait de la mémoire cache.

Lorsqu’un message est lu par anticipation, le service le verrouille. Ainsi, le message lu par anticipation ne peut pas être reçu par un autre destinataire. Si le destinataire ne peut pas terminer le message avant expiration du verrouillage, le message devient disponible pour les autres destinataires. La copie lue par anticipation du message reste dans le cache. Le destinataire qui consomme la copie en cache expirée reçoit une exception lorsqu’il essaie de terminer le message. Par défaut, le verrouillage du message expire au bout de 60 secondes. Cette valeur peut être étendue à 5 minutes. Pour empêcher la consommation des messages arrivés à expiration, définissez la taille du cache pour qu’elle soit inférieure au nombre de messages qu’un client peut utiliser au sein de l’intervalle de délai d’expiration de verrouillage.

Si vous utilisez la durée par défaut d’expiration de verrouillage, qui est de 60 secondes, une bonne valeur pour PrefetchCount est 20 fois les vitesses de traitement maximales de l’ensemble des récepteurs de la fabrique. Par exemple, une structure crée 10 destinataires, et chaque destinataire peut traiter jusqu’à 10 messages par seconde. Le nombre de lectures anticipées ne doit pas dépasser 20 X 3 X 10 = 600. Par défaut, PrefetchCount est défini sur 0, ce qui signifie qu’aucun autre message n’est récupéré à partir du service.

La lecture anticipée de messages augmente le débit global d’un abonnement ou une file d’attente, car elle permet de réduire le nombre total d’opérations de messagerie, ou les allers-retours. La récupération (fetch) du premier message, cependant, prend plus de temps (en raison de la taille du message accrue). La réception de messages pré-récupérés depuis le cache sera plus rapide, car ces messages ont déjà été téléchargés par le client.

La propriété (TTL) de durée de vie d’un message est vérifiée par le serveur au moment où le serveur envoie le message au client. Le client ne vérifie pas la propriété TTL du message à la réception de ce dernier. Toutefois, le message peut être reçu même si la durée de vie du message a été dépassée pendant la mise en cache par le client.

La lecture anticipée n’affecte pas le nombre d’opérations de messagerie facturables et est disponible uniquement pour le protocole client Service Bus. Le protocole HTTP ne prend pas en charge la lecture anticipée. La lecture anticipée est disponible pour les opérations de réception synchrones et asynchrones.

Prérécupération et ReceiveMessagesAsync

Même si les concepts liés à la prérécupération de plusieurs messages ensemble présentent une sémantique similaire au traitement des messages dans un lot (ReceiveMessagesAsync), il existe quelques différences mineures que vous devez garder à l’esprit lorsque vous optez pour ces approches simultanément.

La prérécupération est une configuration (ou un mode) du ServiceBusReceiver et ReceiveMessagesAsync est une opération (qui a une requête-réponse sémantique).

Lorsque vous optez pour ces approches en même temps, envisagez les cas suivants :

• Le nombre de prérécupérations doit être supérieur ou égal au nombre de messages que vous vous attendez à recevoir de ReceiveMessagesAsync.
• Le nombre de prérécupérations peut aller jusqu’à n/3 fois le nombre de messages traités par seconde, sachant que n est la durée de verrouillage par défaut.

Quelques difficultés surviennent lors d’une approche gourmande (par exemple, en conservant le nombre de prérécupérations élevé), car cela implique le verrouillage du message sur un récepteur particulier. Nous vous recommandons d’essayer les valeurs de prérécupération qui se trouvent entre les seuils mentionnés précédemment et d’identifier ce qui convient.

Files d’attente ou rubriques multiples

Si une seule file d’attente ou rubrique ne peut pas gérer le nombre attendu de messages, utilisez plusieurs entités de messagerie. Lorsque vous utilisez plusieurs entités, créez un client dédié pour chacune d’elles au lieu d’utiliser le même client pour toutes les entités.

Un plus grand nombre de files d’attente ou de rubriques signifie que vous avez plus d’entités à gérer au moment du déploiement. Sur le plan de la scalabilité, il n’y a pas vraiment de différence notable, car Service Bus répartit déjà la charge sur plusieurs journaux en interne de sorte que, si vous utilisez six files d’attente ou rubriques ou deux files d’attente ou rubrique, cela ne fera pas une grande différence.

Le niveau de service que vous utilisez affecte la prévisibilité des performances. Si vous choisissez le niveau Standard, le débit et la latence sont optimisés sur une infrastructure multilocataire partagée. D’autres locataires sur le même cluster peuvent avoir un impact sur votre débit. Si vous choisissez Premium, vous obtenez des ressources qui vous donnent des performances prévisibles, et vos files d’attente ou rubriques multiples sont traitées hors de ce pool de ressources. Pour plus d’informations, consultez Niveaux tarifaires.

Espaces de noms avec partition

Lorsque vous utilisez des espaces de noms avec partition de niveau Premium , plusieurs partitions avec des unités de messagerie inférieures vous offrent un meilleur niveau de performance par rapport à une seule partition avec des unités de gestion plus élevées.

Scénarios

Les sections suivantes décrivent les scénarios de messagerie classiques et soulignent les paramètres Service Bus favoris par défaut. Les débits sont classés dans la catégorie Petit (moins d’1 message/seconde), Modéré (1 message/s ou plus, mais moins de 100 messages par seconde) et Élevé (100 messages/seconde ou plus). Le nombre de clients est classé en tant que petit (5 ou moins), modéré (plus de 5, mais inférieur ou égal à 20) et grand (plus de 20).

File d’attente à débit élevé

Objectif : Maximiser le débit d’une file d’attente unique. Le nombre d’expéditeurs et de destinataires est faible.

• Pour augmenter la vitesse de transmission globale dans la file d’attente, utilisez plusieurs structures de messages pour créer des expéditeurs. Pour chaque expéditeur, utilisez des opérations asynchrones ou plusieurs threads.
• Pour augmenter la vitesse de réception depuis la file d’attente, utilisez plusieurs structures de messages pour créer des destinataires.
• Définissez le nombre de lectures anticipées à 20 fois la vitesse de traitement maximale de la totalité des destinataires d’une structure. Cela réduit le nombre de transmissions de protocole client Service Bus.

Plusieurs files d’attente haut débit

Objectif : Optimiser le débit global de plusieurs files d’attente. Le débit d’une file d’attente individuelle est modéré ou élevé.

Pour obtenir un débit maximal sur plusieurs files d’attente, utiliser les paramètres conseillés pour maximiser le débit d’une file d’attente unique. En outre, utiliser des structures différentes pour créer des clients procédant à des envois ou des réceptions de la part de différentes files d’attente.

File d’attente à latence faible

Objectif : Réduisez la latence d’une file d’attente ou d’une rubrique. Le nombre d’expéditeurs et de destinataires est faible. Le débit de la file d’attente est faible ou modéré.

• Si vous utilisez un seul client, définissez le nombre de lectures anticipées à 20 fois la vitesse de traitement du destinataire. Si plusieurs messages arrivent à la file d’attente en même temps, le protocole client Service Bus les transmet tous simultanément. Lorsque le client reçoit le message suivant, ce message est déjà dans le cache local. Le cache doit être de petite taille.
• Si vous utilisez plusieurs clients, définissez le nombre de lectures anticipées sur 0. Ainsi, le deuxième client peut recevoir le deuxième message alors que le premier client traite toujours le premier message.

File d’attente comportant un grand nombre d’expéditeurs

Objectif : Maximiser le débit d’une file d’attente ou d’une rubrique comportant un grand nombre d’expéditeurs. Chaque expéditeur envoie des messages à une vitesse modérée. Le nombre de destinataires est faible.

Service Bus permet jusqu’à 1 000 connexions simultanées à une entité de messagerie. Cette limite s’applique au niveau de l’espace de noms et les rubriques, files d’attente ou abonnements sont limités par la limite de connexions simultanées par espace de noms. Pour les files d’attente, ce nombre est partagé entre les expéditeurs et les destinataires. Si les 1 000 connexions sont requises pour les expéditeurs, remplacez la file d’attente par une rubrique et un seul abonnement. Une rubrique accepte jusqu’à 1 000 connexions simultanées des expéditeurs. L’abonnement accepte 1 000 connexions simultanées supplémentaires de la part des récepteurs. Si plus de 1 000 expéditeurs simultanés sont requis, les expéditeurs doivent envoyer leurs messages au protocole de Service Bus via HTTP.

Pour maximiser le débit, procédez comme suit :

• Si chaque expéditeur se trouve dans un processus différent, utilisez uniquement une structure par processus.
• Définissez le nombre de lectures anticipées à 20 fois la vitesse de traitement maximale de la totalité des destinataires d’une structure. Cela réduit le nombre de transmissions de protocole client Service Bus.

File d’attente comportant un grand nombre de destinataires

Objectif : Optimiser la vitesse de réception d’une file d’attente ou d’abonnement comportant un grand nombre de destinataires. Chaque destinataire reçoit les messages à une vitesse modérée. Le nombre d’expéditeurs est faible.

Service Bus permet jusqu’à 1 000 connexions simultanées à une entité. Si une file d’attente nécessite plus de 1 000 récepteurs, remplacez la file d’attente par une rubrique et plusieurs abonnements. Chaque abonnement peut prendre en charge jusqu’à 1 000 connexions simultanées. Les destinataires peuvent également accéder à la file d’attente via le protocole HTTP.

Pour maximiser le débit, procédez comme suit :

• Si chaque destinataire se trouve dans un processus différent, utilisez uniquement une structure par processus.
• Définir le nombre de lectures anticipées sur une valeur faible (par exemple, PrefetchCount = 10). Cela empêche les destinataires de rester oisifs pendant que d’autres mettent en cache un grand nombre de messages.

Rubrique avec quelques abonnements

Objectif : Maximiser le débit d’une rubrique comportant quelques abonnements. Un message est reçu par un grand nombre d’abonnements, ce qui signifie que la vitesse de réception combinée sur l’ensemble des abonnements est supérieure à la vitesse d’envoi. Le nombre d’expéditeurs est faible. Le nombre de récepteurs par abonnement est faible.

Pour maximiser le débit, procédez comme suit :

• Pour augmenter la vitesse de transmission globale dans la rubrique, utilisez plusieurs structures de messages pour créer des expéditeurs. Pour chaque expéditeur, utilisez des opérations asynchrones ou plusieurs threads.
• Pour augmenter la vitesse de réception d’ensemble d’un abonnement, utilisez plusieurs structures de message pour créer des destinataires. Pour chaque destinataire, utilisez des opérations asynchrones ou plusieurs threads.
• Définissez le nombre de lectures anticipées à 20 fois la vitesse de traitement maximale de la totalité des destinataires d’une structure. Cela réduit le nombre de transmissions de protocole client Service Bus.

Rubrique comportant un grand nombre d’abonnements

Objectif : Maximiser le débit d’une rubrique comportant un grand nombre d’abonnements. Un message est reçu par un grand nombre d’abonnements, ce qui signifie que la vitesse de réception combinée sur l’ensemble des abonnements est supérieure à la vitesse d’envoi. Le nombre d’expéditeurs est faible. Le nombre de récepteurs par abonnement est faible.

Les rubriques comportant un grand nombre d’abonnements affichent généralement un faible débit global si tous les messages sont acheminés vers tous les abonnements. Cela est dû au fait que chaque message est reçu plusieurs fois et tous les messages d’une rubrique et tous les abonnements associés sont stockés dans le même magasin. Il est supposé ici que le nombre d’expéditeurs et le nombre de récepteurs par abonnement est faible. Service Bus prend en charge jusqu’à 2 000 abonnements par rubrique.

Pour maximiser le débit, procédez comme suit :

• Définissez le nombre de prérécupérations de manière à ce qu’il soit égal à 20 fois le taux de réception attendu des messages. Cela réduit le nombre de transmissions de protocole client Service Bus.