Exporter (0) Imprimer
Développer tout

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

Mis à jour: novembre 2014

Cette rubrique décrit l'utilisation du Microsoft Azure Service Bus pour optimiser les performances lors de l'échange de messages répartis. La première moitié de cette rubrique est consacrée aux différents mécanismes permettant d'augmenter les performances. La deuxième moitié donne des conseils sur l'utilisation du Service Bus de façon à obtenir des performances optimales pour un scénario donné.

Tout au long de cette rubrique, le terme « client » fait référence à une entité qui accède au Service Bus. Un client peut prendre le rôle d'expéditeur ou de récepteur. 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 « récepteur » fait référence à un client de file d'attente ou d'abonnement Service Bus qui reçoit des messages d'une file d'attente ou d'un abonnement Service Bus.

Cette section présente différents concepts employés par le Service Bus pour améliorer les performances.

Le Service Bus permet aux clients d'échanger des messages via deux protocoles : le protocole client Service Bus, et HTTP. Le protocole client Service Bus est plus efficace, car il maintient la connexion au service Service Bus tant que la fabrique des messages existe. Il implémente aussi le traitement par lot et le préchargement. Le protocole client Service Bus est disponible pour les applications .NET utilisant l'API gérée par .NET.

Sauf mention explicite, tout le contenu de cette rubrique suppose l'utilisation du protocole client Service Bus.

Les objets clients Service Bus, tels que QueueClient ou MessageSender, sont créés via un objet MessagingFactory, qui permet également la gestion interne des connexions. Vous ne devez pas fermer les fabriques de messageries ou les clients de file d'attente, de rubrique et d'abonnement après l'envoi d'un message, puis les recréer lorsque vous envoyez le message suivant. La fermeture d'une fabrique de messagerie supprime la connexion au service Service Bus, et une nouvelle connexion est établie lors de la recréation de la fabrique. L'établissement d'une connexion est une opération coûteuse qui peut être évitée en réutilisant les mêmes objets fabrique et client pour plusieurs opérations.

La réalisation d'une opération (envoi, réception, suppression, etc.) prend un certain temps. Cette durée inclut le traitement de l'opération par le service Service Bus, en plus de la latence de la requête et de la réponse. Pour augmenter le nombre d'opérations par durée, les opérations doivent s'exécuter simultanément. Pour ce faire, il existe plusieurs méthodes :

  • Opérations asynchrones : le client place dans le pipeline des opérations en réalisant des opérations asynchrones. La requête suivante démarre avant la fin de la requête précédente. L'exemple suivant illustre une opération d'envoi asynchrone :

    BrokeredMessage m1 = new BrokeredMessage(body);
    BrokeredMessage m2 = new BrokeredMessage(body);
    queueClient.BeginSend(m1, processEndSend, queueClient); // Send message 1.
    queueClient.BeginSend(m2, processEndSend, queueClient); // Send message 2.
    
    void processEndSend(IAsyncResult result)
    {
        QueueClient qc = result.AsyncState as QueueClient;
        qc.EndSend(result);
        Console.WriteLine("Message sent");
    }
    
    L'exemple suivant illustre une opération de réception asynchrone :

    queueClient.BeginReceive(processEndReceive, queueClient); // Receive message 1.
    queueClient.BeginReceive(processEndReceive, queueClient); // Receive message 2.
    
    void processEndReceive(IAsyncResult result) 
    {
        QueueClient qc = result.AsyncState as QueueClient;
        BrokeredMessage m = qc.EndReceive(result);
        m.BeginComplete(processEndComplete, m);
        Console.WriteLine("Received message " + m.Label);
    }
    
    void processEndComplete(IAsyncResult result)
    {
        BrokeredMessage m = result.AsyncState as BrokeredMessage;
        m.EndComplete(result);
        Console.WriteLine("Completed message " + m.Label);
    }
    
  • Plusieurs fabriques : tous les clients (expéditeurs et récepteurs) créés par la même fabrique partagent une même connexion TCP. Le débit maximum de messages est limité par le nombre d'opérations pouvant circuler via cette connexion TCP. Le débit pouvant être obtenu avec une seule fabrique varie grandement en fonction des durées de parcours circulaire TCP et de la taille des messages. Pour obtenir des taux de débit supérieurs, vous devez utiliser plusieurs fabriques de messageries.

Lors de la création d'un client d'abonnement ou de file d'attente, vous pouvez spécifier un mode de réception : Afficher-verrouiller ou Recevoir et supprimer. Le mode de réception par défaut est PeekLock. Sous ce mode, le client envoie une requête de réception de message à partir du Service Bus. Après réception du message par le client, il envoie une requête pour terminer le message.

Si le mode de réception est défini sur ReceiveAndDelete, les deux étapes sont regroupées en une seule requête. Cela réduit le nombre général d'opérations et peut améliorer le débit général des messages. Ce gain de performances est réalisé au risque de perdre des messages.

Service Bus ne prend pas en charge les transactions pour les opérations de réception-suppression. De plus, les sémantiques afficher-verrouiller sont requises pour les scénarios dans lesquels le client souhaite différer un message ou annuler sa distribution en raison de lettres mortes.

Le traitement par lot côté client permet à un client de rubrique ou de file d'attente de différer l'envoi d'un message pendant une certaine durée. Si le client envoie d'autres messages pendant cette durée, il les transmet en un seul lot. Le traitement par lot côté client pousse aussi le client de file d'attente/d'abonnement à regrouper plusieurs requêtes Terminer en une seule requête. Le traitement par lot est uniquement disponible pour les opérations asynchrones Envoyer et Terminer. Les opérations synchrones sont immédiatement envoyées au service Service Bus. Le traitement par lot n'a pas lieu pour des opérations d'affichage ou de réception, ni sur plusieurs clients.

Si le lot dépasse la taille maximale des messages, le dernier message est supprimé du lot pour que le client envoie immédiatement ce dernier. Le dernier message devient le premier message du lot suivant. Un client utilise par défaut un intervalle de 20 ms entre chaque lot. Vous pouvez modifier l'intervalle s'écoulant entre l'envoi de chaque lot en définissant la propriété BatchFlushInterval avant de créer la fabrique des messages. Ce paramètre touche tous les clients créés par cette fabrique. Pour désactiver le traitement par lot, définissez la propriété BatchFlushInterval sur TimeSpan.Zero. Par exemple :

MessagingFactorySettings mfs = new MessagingFactorySettings();
mfs.TokenProvider = tokenProvider;
mfs.NetMessagingTransportSettings.BatchFlushInterval = TimeSpan.FromSeconds(0.05);
MessagingFactory messagingFactory = MessagingFactory.Create(namespaceUri, mfs);

Le traitement par lot n'a pas d'incidence sur le nombre d'opérations de messagerie facturables et il est disponible uniquement pour le protocole client Service Bus. Le protocole HTTP ne prend pas en charge le traitement par lot.

Pour augmenter le débit d'une file d'attente/d'une rubrique/d'un abonnement, le service Service Bus regroupe plusieurs messages lorsqu'il écrit à son magasin interne. En cas d'activation sur une file d'attente ou une rubrique, l'écriture de messages dans le magasin sera traitée par lot. En cas d'activation sur une file d'attente ou un abonnement, la suppression de messages du magasin sera traitée par lot. Si l'accès au magasin par lot est activé pour une entité, le Service Bus retarde une opération d'écriture dans le magasin au sujet de cette entité de 20 ms au maximum. Les opérations de magasin supplémentaires qui se produisent pendant cet intervalle sont ajoutées au lot. L'accès au magasin par lot affecte uniquement les opérations Envoyer et Terminer ; les opérations de réception ne sont pas affectées. L'accès au magasin par lot est une propriété sur une entité. Le traitement par lot se produit sur toutes les entités qui activent l'accès au magasin par lot.

En cas de création d'une file d'attente, d'une rubrique ou d'un abonnement, l'accès au magasin par lot est activé par défaut. Pour désactiver l'accès au magasin par lot, définissez la propriété EnableBatchedOperations sur false avant de créer l'entité. Par exemple :

QueueDescription qd = new QueueDescription();
qd.EnableBatchedOperations = false;
Queue q = namespaceManager.CreateQueue(qd);

L'accès au magasin par lot n'a pas d'incidence sur le nombre d'opérations de messagerie facturables et c'est une propriété d'une file d'attente, d'une rubrique ou d'un abonnement. Il est indépendant du mode de réception et du protocole utilisé entre un client et le service Service Bus.

Le préchargement permet au client de l'abonnement ou de la file d'attente de charger des messages supplémentaires du service lorsqu'il réalise une opération de réception. Le client stocke ces messages dans un cache local. La taille du cache est déterminée par les propriétés PrefetchCount et PrefetchCount. Chaque client qui active le préchargement maintient son propre cache. Un cache n'est pas partagé par plusieurs clients. Si le client initie une opération de réception et que son cache est vide, le service transmet un lot de messages. La taille du lot est égale soit à la taille du cache soit à 256 Ko (le plus petit des deux). Si le client initie une opération de réception et que son cache contient un message, le message est extrait du cache.

Lorsqu'un message est préchargé, le service le verrouille. En faisant cela, le message préchargé ne peut pas être reçu par un autre récepteur. Si le récepteur ne peut pas terminer le message avant l'expiration du verrouillage, le message devient disponible aux autres récepteurs. La copie préchargée du message reste dans le cache. Le récepteur qui consomme la copie mise en cache expirée reçoit une exception lorsqu'il tente de terminer le message en question. Par défaut, le verrouillage du message expire au bout de 60 secondes. Cette valeur peut être prolongée à 5 minutes. Pour empêcher la consommation des messages expirés, la taille du cache doit toujours être inférieure au nombre de messages pouvant être consommés par un client durant l'intervalle du délai d'attente du verrouillage.

Si vous utilisez la durée d'expiration de verrouillage par défaut qui est de 60 secondes, une bonne valeur pour SubscriptionClient.PrefetchCount est 20 fois les vitesses de traitement maximales de l'ensemble des récepteurs de la fabrique. Par exemple, une fabrique crée 3 récepteurs. Chaque récepteur peut traiter un maximum de 10 messages par seconde. Le nombre de préchargements ne doit pas dépasser 20*3*10 = 600. QueueClient.PrefetchCount est défini sur 0 par défaut, ce qui signifie qu'aucun message supplémentaire n'est récupéré à partir du service.

Le préchargement de messages augmente le débit global d'une file d'attente ou d'un abonnement, car il diminue le nombre général d'opérations des messages, ou aller-retour. Le chargement du premier message prend toutefois plus de temps (en raison de l'augmentation de la taille des messages). La réception des messages préchargés est accélérée, car ceux-ci ont déjà été téléchargés par le client.

La propriété de durée de vie (TTL) d'un message est vérifiée par le serveur au moment où celui-ci envoie le message au client. Le client ne vérifie pas la propriété de durée de vie du message à sa réception. Mais le message peut être reçu même si sa durée de vie s'est écoulée pendant qu'il était mis en cache par le client.

Le préchargement n'a pas d'incidence sur le nombre d'opérations de messagerie facturables et il est disponible uniquement pour le protocole client Service Bus. Le protocole HTTP ne prend pas en charge le préchargement. Le préchargement est disponible pour les opérations de réception synchrones et asynchrones.

Les entités rapides offrent des scénarios à débit élevé et à faible latence. Avec les entités rapides, si un message est envoyé vers une file d'attente ou une rubrique, il n'est pas immédiatement stocké dans la banque de messagerie. À la place, le message est mis en mémoire cache. Si le message reste dans la file d'attente pendant plus de quelques secondes, il est automatiquement écrit sur le dispositif de stockage stable, ce qui le protège contre la perte due à une panne. L'enregistrement du message dans une mémoire cache permet d'augmenter le débit et de réduire la latence parce qu'il n'y a pas d'accès au stockage stable au moment où le message est envoyé. Les messages consommés en quelques secondes ne sont pas écrits dans la banque de messagerie. L'exemple suivant crée une rubrique rapide :

TopicDescription td = new TopicDescription(TopicName);
td.EnableExpress = true;
namespaceManager.CreateTopic(td);

Si un message contenant des informations sensibles ne pouvant pas être égarées est envoyé à une entité rapide, l'expéditeur peut contraindre Service Bus à maintenir immédiatement le message en stockage stable en définissant la propriété ForcePersistence sur true. Pour plus d'informations, consultez Nouveautés dans la version 2.4 (juillet 2014) du Kit de développement logiciel (SDK) Azure.

En interne, Service Bus utilise le même nœud et même la banque de messagerie pour traiter et stocker tous les messages pour une entité de messagerie (file d'attente ou rubrique). Une file d'attente ou une rubrique partitionnée est, d'un autre côté, distribuée sur plusieurs nœuds et banques de messagerie. Les files d'attente et rubriques partitionnées donnent non seulement un débit plus élevé que les files d'attente et rubriques ordinaires, mais elles offrent aussi une disponibilité supérieure. Pour créer une entité partitionnée, définissez la propriété EnablePartitioning sur true, comme illustré dans l'exemple suivant. Pour plus d'informations sur les entités partitionnées, consultez Partitionnement des entités de messagerie.

// Create partitioned queue.
QueueDescription qd = new QueueDescription(QueueName);
qd.EnablePartitioning = true;
namespaceManager.CreateQueue(qd);

S'il n'est pas possible d'utiliser une file d'attente ou une rubrique partitionnée, ou si la charge prévue ne peut pas être gérée par une seule file d'attente ou rubrique partitionnée, vous devez utiliser plusieurs entités de messagerie. Lors de l'utilisation de multiples entités, créez un client dédié pour chaque entité, au lieu d'utiliser le même client pour toutes les entités.

Les sections suivantes décrivent des scénarios de messagerie classiques et décrivent les paramètres Service Bus préférés. Les débits sont classés en trois catégories : petit (<1 message/s), modéré (≥ 1 message/s, <100 messages/s) et élevé (≥100 messages/s). Le nombre de clients est réparti en trois catégories : petit (≤5), modéré (>5, ≤20) et élevé (>20).

Objectif : maximiser le débit d'une seule file d'attente. Le nombre d'expéditeurs et de récepteurs est faible.

  • Utilisez une file d'attente partitionnée pour améliorer les performances et la disponibilité.

  • Pour augmenter la vitesse de transmission globale dans la file d'attente, utilisez plusieurs fabriques 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 globale à partir de la file d'attente, utilisez plusieurs fabriques de messages pour créer des récepteurs.

  • Utilisez des opérations asynchrones pour profiter du traitement par lot côté client.

  • Définissez l'intervalle de traitement par lot sur 50 ms pour diminuer le nombre de transmissions de protocoles clients Service Bus. Si plusieurs expéditeurs sont utilisés, faites passer l'intervalle de traitement par lot à 100 ms.

  • Laissez activé l'accès au magasin par lot. Cela augmente la vitesse globale à laquelle les messages peuvent être écrits dans la file d'attente.

  • Définissez le nombre de préchargements sur un nombre correspondant à 20 fois les vitesses de traitement maximales de l'ensemble des récepteurs d'une fabrique. Cela diminue le nombre de transmissions de protocoles clients Service Bus.

Objectif : maximiser le débit général 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, utilisez les paramètres décrits pour maximiser le débit d'une seule file d'attente. En outre, utilisez différentes fabriques pour créer des clients qui envoient ou reçoivent à partir de différentes files d'attente.

Objectif : minimiser la latence de bout en bout d'une file d'attente ou d'une rubrique. Le nombre d'expéditeurs et de récepteurs est faible. Le débit d'une file d'attente est faible ou modérée.

  • Utilisez une file d'attente partitionnée pour améliorer la disponibilité.

  • Désactivez le traitement par lot côté client. Le client envoie immédiatement un message.

  • Désactivez l'accès au magasin par lot. Le service écrit immédiatement le message dans le magasin.

  • Si vous utilisez un seul client, définissez le nombre de préchargements sur un nombre correspondant à 20 fois la vitesse de traitement du récepteur. Si plusieurs messages arrivent en même temps dans la file d'attente, le protocole client Service Bus les transmet tous à la fois. Lorsque le client reçoit le message suivant, ce dernier se trouve déjà dans le cache local. Le cache doit être petit.

  • Si vous utilisez plusieurs clients, définissez le nombre de préchargements sur 0. Ainsi, le deuxième client peut recevoir le deuxième message pendant que le premier client traite toujours le premier message.

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 récepteurs est faible.

Le Service Bus active un maximum de 100 connexions simultanées sur une entité. Pour les files d'attente, ce nombre est partagé entre les expéditeurs et les récepteurs. Si les 100 connexions sont requises pour les expéditeurs, vous devez remplacer la file d'attente par une rubrique et un abonnement unique. Une rubrique accepte un maximum de 100 connexions simultanées de la part des expéditeurs, alors que l'abonnement accepte 100 connexions simultanées supplémentaires de la part des récepteurs. Si plus de 100 expéditeurs simultanés sont requis, les expéditeurs doivent envoyer des messages au protocole Service Bus via HTTP.

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

  • Utilisez une file d'attente partitionnée pour améliorer les performances et la disponibilité.

  • Si chaque expéditeur réside dans un processus différent, utilisez uniquement une seule fabrique par processus.

  • Utilisez des opérations asynchrones pour profiter du traitement par lot côté client.

  • Utilisez l'intervalle de traitement par lot par défaut de 20 ms pour diminuer le nombre de transmissions de protocoles clients Service Bus.

  • Laissez activé l'accès au magasin par lot. Cela augmente la vitesse globale à laquelle les messages peuvent être écrits dans la file d'attente ou dans la rubrique.

  • Définissez le nombre de préchargements sur un nombre correspondant à 20 fois les vitesses de traitement maximales de l'ensemble des récepteurs d'une fabrique. Cela diminue le nombre de transmissions de protocoles clients Service Bus.

Objectif : maximiser la vitesse de réception d'une file d'attente ou d'un abonnement comportant un grand nombre de récepteurs. Chaque récepteur reçoit des messages à une vitesse modérée. Le nombre d'expéditeurs est faible.

Le Service Bus active un maximum de 100 connexions simultanées sur une entité. Si une file d'attente nécessite plus de 100 récepteurs, vous devez remplacer la file d'attente par une rubrique et plusieurs abonnements. Chaque abonnement peut prendre en charge un maximum de 100 connexions simultanées. Les récepteurs peuvent aussi accéder à la file d'attente via le protocole HTTP.

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

  • Utilisez une file d'attente partitionnée pour améliorer les performances et la disponibilité.

  • Si chaque récepteur réside dans un processus différent, utilisez uniquement une seule fabrique par processus.

  • Les récepteurs peuvent utiliser des opérations synchrones ou asynchrones. Étant donné la vitesse de réception modérée d'un récepteur individuel, le traitement par lot côté client d'une requête Terminer n'a pas d'incidence sur le débit du récepteur.

  • Laissez activé l'accès au magasin par lot. Cela diminue la charge globale de l'entité. Cela réduit aussi la vitesse globale à laquelle les messages peuvent être écrits dans la file d'attente ou dans la rubrique.

  • Définissez le nombre de préchargements sur une petite valeur (par exemple, PrefetchCount = 10). Cela empêche les récepteurs d'être inactifs alors que de grands nombres de messages sont mis en cache pour d'autres récepteurs.

Objectif : maximiser le débit d'une rubrique comportant un petit 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 tous les abonnements est supérieure à la vitesse de transmission. 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 :

  • Utilisez une rubrique partitionnée pour améliorer les performances et la disponibilité.

  • Pour augmenter la vitesse de transmission globale dans la rubrique, utilisez plusieurs fabriques 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 globale à partir d'un abonnement, utilisez plusieurs fabriques de messages pour créer des récepteurs. Pour chaque récepteur, utilisez des opérations asynchrones ou plusieurs threads.

  • Utilisez des opérations asynchrones pour profiter du traitement par lot côté client.

  • Utilisez l'intervalle de traitement par lot par défaut de 20 ms pour diminuer le nombre de transmissions de protocoles clients Service Bus.

  • Laissez activé l'accès au magasin par lot. Cela augmente la vitesse globale à laquelle les messages peuvent être écrits dans la rubrique.

  • Définissez le nombre de préchargements sur un nombre correspondant à 20 fois les vitesses de traitement maximales de l'ensemble des récepteurs d'une fabrique. Cela diminue le nombre de transmissions de protocoles clients Service Bus.

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 tous les abonnements est bien supérieure à la vitesse de transmission. Le nombre d'expéditeurs est faible. Le nombre de récepteurs par abonnement est faible.

Les rubriques comportant un grand nombre d'abonnements exposent 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 que tous les messages contenus dans une rubrique et tous les abonnements associés sont stockés dans le même magasin. On part du principe que le nombre d'expéditeurs et de récepteurs par abonnement est faible. Service Bus prend en charge un maximum de 2 000 abonnements par rubrique.

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

  • Utilisez une rubrique partitionnée pour améliorer les performances et la disponibilité.

  • Utilisez des opérations asynchrones pour profiter du traitement par lot côté client.

  • Utilisez l'intervalle de traitement par lot par défaut de 20 ms pour diminuer le nombre de transmissions de protocoles clients Service Bus.

  • Laissez activé l'accès au magasin par lot. Cela augmente la vitesse globale à laquelle les messages peuvent être écrits dans la rubrique.

  • Définissez le nombre de préchargements sur un nombre correspondant à 20 fois la vitesse de réception prévue en secondes. Cela diminue le nombre de transmissions de protocoles clients Service Bus.

Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft