Considérations relatives à la conception et aux performances des applications

Il existe un certain nombre de façons dont une mauvaise conception du programme peut affecter les performances. Ils peuvent être difficiles à détecter car le programme peut sembler bien fonctionner lui-même, mais affecter l'exécution d'autres tâches. Plusieurs problèmes spécifiques aux programmes effectuant des appels IBM® MQ sont décrits dans cette rubrique.

Voici quelques idées pour vous aider à concevoir des applications efficaces:
  • Concevez votre application de sorte que le traitement se déroule en parallèle avec le temps de réflexion d'un utilisateur:
    • Affiche un panneau et permet à l'utilisateur de commencer à taper pendant que l'application est en cours d'initialisation.
    • Obtenez les données dont vous avez besoin en parallèle à partir de différents serveurs.
  • Gardez les connexions et les files d'attente ouvertes si vous prévoyez de les réutiliser au lieu de les ouvrir et de les fermer, de les connecter et de les déconnecter à plusieurs reprises.
  • Toutefois, une application serveur qui ne place qu'un seul message doit utiliser MQPUT1.
  • Les gestionnaires de files d'attente sont optimisés pour les messages dont la taille est comprise entre 4 et 100 Ko. Les messages de très grande taille sont inefficaces ; il est probablement préférable d'envoyer 100 messages de 1 Mo chacun plutôt qu'un seul message de 100 Mo. Les très petits messages sont également inefficaces. Le gestionnaire de files d'attente effectue la même quantité de travail pour un message mono-octet que pour un message de 4 Ko.
  • Conservez vos messages dans une unité de travail afin qu'ils puissent être validés ou annulés simultanément.
  • Utilisez l'option tampon pour les messages qui n'ont pas besoin d'être récupérables.
  • Si vous devez envoyer un message à un certain nombre de files d'attente cible, envisagez d'utiliser une liste de distribution.

Effet de la longueur du message

La quantité de données d'un message peut affecter les performances de l'application qui traite le message. Pour obtenir les meilleures performances de votre application, envoyez uniquement les données essentielles d'un message. Par exemple, dans une demande de débit d'un compte bancaire, les seules informations qui doivent être transmises du client à l'application serveur sont le numéro de compte et le montant du débit.

Effet de la persistance des messages

Les messages persistants sont généralement consignés. La consignation des messages réduit les performances de votre application. Par conséquent, utilisez les messages persistants uniquement pour les données essentielles. Si les données d'un message peuvent être supprimées en cas d'arrêt ou d'échec du gestionnaire de files d'attente, utilisez un message non persistant.

[z/OS]Les opérations MQPUT et MQGET pour les messages persistants sont bloquées lorsque l'espace du journal de reprise est insuffisant pour enregistrer les opérations. Cette condition est indiquée dans le journal des travaux du gestionnaire de files d'attente par les messages CSQJ110E et CSQJ111A. S'assurer que des processus de surveillance sont en place afin que ces conditions soient gérées et évitées.

Recherche d'un message particulier

L'appel MQGET extrait généralement le premier message d'une file d'attente. Si vous utilisez les identificateurs de message et de corrélation (MsgId et CorrelId) dans le descripteur de message pour spécifier un message particulier, le gestionnaire de files d'attente doit effectuer une recherche dans la file d'attente jusqu'à ce qu'il trouve ce message. L'utilisation de l'appel MQGET de cette manière affecte les performances de votre application.

Files d'attente contenant des messages de longueurs différentes

Si votre application ne peut pas utiliser des messages de longueur fixe, agrandissez et réduisez les tampons de manière dynamique pour qu'ils correspondent à la taille de message standard. Si l'application émet un appel MQGET qui échoue car la mémoire tampon est trop petite, la taille des données de message est renvoyée. Ajoutez du code à votre application afin que la mémoire tampon soit redimensionnée en conséquence et que l'appel MQGET soit réémis.

Remarque: Si vous ne définissez pas explicitement l'attribut MaxMsgLength , la valeur par défaut est 4 Mo, ce qui peut s'avérer très inefficace si cette valeur est utilisée pour influencer la taille de la mémoire tampon de l'application.

Fréquence des points de synchronisation

Les programmes qui émettent un très grand nombre d'appels MQPUT ou MQGET au sein d'un point de synchronisation, sans les valider, peuvent entraîner des problèmes de performances. Les files d'attente affectées peuvent être saturées avec des messages actuellement inaccessibles, tandis que d'autres tâches peuvent être en attente pour obtenir ces messages. Cela a des implications en termes de stockage et en termes d'unités d'exécution liées à des tâches qui tentent d'obtenir des messages.

Utilisation de l'appel MQPUT1

Utilisez l'appel MQPUT1 uniquement si vous avez un seul message à insérer dans une file d'attente. Si vous souhaitez insérer plusieurs messages, utilisez l'appel MQOPEN, suivi d'une série d'appels MQPUT et d'un appel MQCLOSE unique.

Nombre d'unités d'exécution utilisées

[Windows]Pour IBM MQ for Windows, une application peut nécessiter un grand nombre d'unités d'exécution. Un nombre maximal d'unités d'exécution d'application est alloué à chaque processus de gestionnaire de files d'attente.

Les applications peuvent utiliser trop d'unités d'exécution. Déterminez si l'application prend en compte cette possibilité et qu'elle prend des mesures pour arrêter ou signaler ce type d'occurrence.

Placer les messages persistants sous le point de synchronisation

Les messages persistants doivent être insérés et placés sous le point de synchronisation. En effet, lors de l'obtention d'un message persistant en dehors du point de synchronisation, en cas d'échec de l'extraction, l'application ne peut pas savoir si le message a été obtenu de la file d'attente ou non et si, si le message a été obtenu, il a également été perdu. Lors de l'obtention de messages persistants sous le point de synchronisation, si quelque chose échoue, la transaction est annulée et le message persistant n'est pas perdu car il se trouve toujours dans la file d'attente.

De même, lors de l'insertion de messages persistants, placez-les sous le point de synchronisation. Une autre raison de placer et d'obtenir des messages persistants sous le point de synchronisation est que le code de message persistant dans IBM MQ est fortement optimisé pour le point de synchronisation. Ainsi, l'insertion et l'obtention de messages persistants sous le point de synchronisation sont plus rapides que l'insertion et l'obtention de messages persistants en dehors du point de synchronisation.

Si votre application place des messages persistants en dehors du point de synchronisation, le gestionnaire de files d'attente vérifie s'il peut créer un point de synchronisation implicite pour le compte de l'application. Si le gestionnaire de files d'attente peut le faire, il inclut l'insertion dans ce point de synchronisation et le valide automatiquement. Voir Point de synchronisation implicite sur Multiplatforms pour une description plus détaillée.

Toutefois, il est plus rapide d'insérer et d'extraire des messages non persistants en dehors du point de synchronisation car le code non persistant dans IBM MQ est optimisé pour être en dehors du point de synchronisation. L'insertion et l'obtention de messages persistants s'effectue à des vitesses de disque car le message persistant est conservé sur le disque. Cependant, l'insertion et l'obtention de messages non persistants se fait à des vitesses d'UC car il n'y a pas d'écriture de disque impliquée, même pas lors de l'utilisation d'un point de synchronisation.

Si une application reçoit des messages et ne sait pas à l'avance s'ils sont persistants ou non, l'option OGM MQGMO_SYNCPOINT_IF_PERSISTENT peut être utilisée.