Remarques sur la conception et les performances des applications z/OS

La conception de l'application est l'un des facteurs les plus importants affectant les performances. Utilisez cette rubrique pour comprendre certains des facteurs de conception impliqués dans les performances.

Il existe un certain nombre de façons dont une mauvaise conception du programme peut affecter les performances. Ces problèmes peuvent être difficiles à détecter car le programme peut sembler bien fonctionner, tout en affectant l'exécution d'autres tâches. Plusieurs problèmes spécifiques aux programmes effectuant des appels MQI sont présentés dans les sections suivantes.

Pour plus d'informations sur la conception d'application, voir Remarques relatives à la conception des applications IBM MQ.

Effet de la longueur du message

Bien que IBM MQ for z/OS® autorise les messages à contenir jusqu'à 100 Mo de données, la quantité de données d'un message affecte 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 à débiter.

Effet de la persistance des messages

Les messages persistants sont 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.

Les données des messages persistants sont écrites dans les mémoires tampon de journal. Ces mémoires tampon sont écrites dans les fichiers journaux lorsque:

Une validation a lieu
Un message est obtenu ou sorti d'un point de synchronisation
Les mémoires tampon WRTHRSH sont remplies

Le traitement d'un grand nombre de messages dans une unité d'oeuvre peut entraîner moins d'entrée/sortie que si les messages étaient traités pour chaque unité d'oeuvre ou hors point de synchronisation.

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 recherche la file d'attente jusqu'à ce qu'il trouve ce message. L'utilisation de MQGET de cette manière affecte les performances de votre application car, pour trouver un message particulier, IBM MQ peut être amené à analyser la totalité de la file d'attente.

Vous pouvez utiliser l'attribut de file d'attente IndexType pour indiquer que vous souhaitez que le gestionnaire de files d'attente gère un index pouvant être utilisé pour augmenter la vitesse des opérations MQGET sur la file d'attente. Cependant, il y a une petite réduction des performances pour la gestion d'un index. Par conséquent, n'en générez qu'un si vous avez besoin de l'utiliser. Vous pouvez choisir de générer un index d'identificateurs de message ou d'identificateurs de corrélation, ou vous pouvez choisir de ne pas générer d'index pour les files d'attente où les messages sont extraits de manière séquentielle. Essayez d'avoir plusieurs valeurs de clé différentes, pas des lots avec la même valeur. Par exemple, Balance1, Balance2et Balance3, et non trois avec Balance. Pour les files d'attente partagées, vous devez disposer du IndexTypecorrect. Pour plus de détails sur l'attribut de file d'attente IndexType , voir IndexType.

Pour éviter d'affecter le temps de redémarrage du gestionnaire de files d'attente à l'aide de files d'attente indexées, utilisez le paramètre QINDXBLD (NOWAIT) dans la macro CSQ6SYSP . Cela permet au redémarrage du gestionnaire de files d'attente de se terminer sans attendre la fin de la génération de l'index de file d'attente.

Pour une description complète de l'attribut IndexType et des autres attributs d'objet, voir Attributs des objets.

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

Obtenez un message en utilisant une taille de mémoire tampon correspondant à la taille attendue du message. Si vous recevez le code retour indiquant que le message est trop long, obtenez une mémoire tampon plus grande. Lorsque l'extraction échoue de cette manière, la longueur de données renvoyée est la taille des données de message non converties. Si vous spécifiez MQGMO_CONVERT dans l'appel MQGET et que les données se développent lors de la conversion, il se peut qu'elles ne tiennent pas dans la mémoire tampon, auquel cas vous devez augmenter encore la taille de la mémoire tampon.

Si vous émettez la commande MQGET avec une longueur de mémoire tampon de zéro, elle renvoie la taille du message et l'application peut alors obtenir une mémoire tampon de cette taille et émettre à nouveau la commande get. Si plusieurs applications traitent la file d'attente, il se peut qu'une autre application ait déjà traité le message lorsque l'application d'origine a réémis l'extraction. Si vous avez parfois des messages volumineux, vous devrez peut-être obtenir une mémoire tampon volumineuse uniquement pour ces messages et la libérer une fois que le message a été traité. Cela devrait aider à réduire les problèmes de mémoire virtuelle si toutes les applications ont des mémoires tampon volumineuses.

Si votre application ne peut pas utiliser des messages de longueur fixe, une autre solution à ce problème consiste à utiliser l'appel MQINQ pour trouver la taille maximale des messages que la file d'attente peut accepter, puis à utiliser cette valeur dans votre appel MQGET . La taille maximale des messages d'une file d'attente est stockée dans l'attribut MaxMsgL de la file d'attente. Cette méthode peut utiliser de grandes quantités de stockage, cependant, car la valeur de MaxMsgL peut atteindre 100 Mo, le maximum autorisé par IBM MQ for z/OS.

Remarque: Vous pouvez abaisser le paramètre MaxMsgL une fois que des messages volumineux ont été placés dans la file d'attente. Par exemple, vous pouvez insérer un message de 100 Mo, puis définir MaxMsgL sur 50 octets. Cela signifie qu'il est toujours possible d'obtenir des messages plus volumineux que prévu par l'application.

Fréquence des points de synchronisation

Les programmes qui émettent de nombreux appels MQPUT dans 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 inutilisables, alors que d'autres tâches peuvent être en attente d'obtention de ces messages. Cela a des implications en termes de stockage et en termes d'unités d'exécution liées aux tâches qui tentent d'obtenir des messages.

En règle générale, si vous avez plusieurs applications qui traitent une file d'attente, vous obtenez généralement les meilleures performances lorsque vous avez:

100 messages courts (moins de 1 ko), ou
Un message pour les messages plus volumineux (100 Ko)

pour chaque point de synchronisation. S'il n'y a qu'une seule application qui traite la file d'attente, vous devez avoir plus de messages pour chaque unité d'oeuvre.

Vous pouvez limiter le nombre de messages qu'une tâche peut obtenir ou insérer dans une unité de récupération unique à l'aide de l'attribut de gestionnaire de files d'attente MAXUMSGS . Pour plus d'informations sur cet attribut, voir la commande ALTER QMGR dans Commandes MQSC.

Avantages de l'appel MQPUT1

Utilisez l'appel MQPUT1 uniquement si vous disposez d'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 seul appel MQCLOSE .

Nombre de messages qu'un gestionnaire de files d'attente peut contenir

Files d'attente locales

Le nombre de messages locaux qu'un gestionnaire de files d'attente peut contenir correspond essentiellement à la taille des ensembles de pages. Vous pouvez avoir jusqu'à 100 ensembles de pages (bien qu'il soit recommandé que l'ensemble de pages 0 et l'ensemble de pages 1 soient destinés aux objets et aux files d'attente liés au système). Vous pouvez utiliser un ensemble de pages avec un format étendu et augmenter la capacité d'un ensemble de pages.

Files d'attente partagées

La capacité des files d'attente partagées dépend de la taille de l'unité de couplage (CF). IBM MQ utilise des structures de liste CF où les unités de stockage fondamentales sont des entrées et des éléments. Chaque message est stocké sous la forme d'une entrée et de plusieurs éléments contenant le MQMD associé et d'autres données de message. Le nombre d'éléments consommés par un seul message dépend de la taille du message et, pour CFLEVEL (5), des règles de déchargement en vigueur au moment de MQPUT. Moins d'éléments sont nécessaires lorsque les données de message sont déchargées dans Db2® ou SMDS. L'accès aux données de message est plus lent lorsque le message a été déchargé. Voir Performance Supportpac MP1H pour une comparaison plus détaillée des performances et de la surcharge de l'unité centrale associée au déchargement des messages.

Ce qui affecte les performances

Les performances peuvent signifier la vitesse à laquelle les messages peuvent être traités, ainsi que la quantité d'UC nécessaire par message.

Ce qui a une incidence sur la rapidité de traitement des messages

Pour les messages persistants, l'impact le plus important est la vitesse des fichiers journaux. La vitesse des fichiers journaux dépend de l'unité de stockage à accès direct sur laquelle ils se trouvent. Par conséquent, il convient de prendre soin de placer le fichier journal sur des volumes peu utilisés afin de réduire les conflits. La segmentation des journaux MQ améliore les performances des journaux lorsque plusieurs pages sont écrites par E-S. La connexion Z High Performance Fibre Connection (zHPF) offre également des performances importantes en termes de temps de réponse d'E-S lorsque le sous-système d'E-S est occupé.

Lorsqu'il existe une demande d'extraction et d'insertion de message, l'accès à la file d'attente est verrouillé lors de la demande afin de préserver l'intégrité de la file d'attente. A des fins de planification, prenez en compte la file d'attente verrouillée pour l'ensemble de la demande. Par conséquent, si la durée d'une insertion est de 100 microsecondes et que vous avez plus de 10 000 demandes par seconde, vous risquez de subir des retards. Vous pouvez obtenir de meilleurs résultats que cela dans la pratique, mais c'est une bonne règle générale. Vous pouvez utiliser différentes files d'attente pour améliorer les performances.

Les raisons possibles sont les suivantes:

utiliser une file d'attente de réponses commune utilisée par chaque transaction CICS®
chaque transaction CICS reçoit une réponse unique à la file d'attente
une réponse à une file d'attente pour la région CICS et toutes les transactions de la région CICS utilisent cette file d'attente.

La réponse dépend du nombre de demandes par seconde et du temps de réponse des demandes.

Si les messages doivent être lus à partir d'un ensemble de pages, ils seront plus lents que lorsque les messages se trouvent dans le pool de mémoire tampon. Si vous avez plus de messages qu'un pool de mémoire tampon, ils seront placés sur le disque. Vous devez donc vous assurer que le pool de mémoire tampon est suffisamment grand pour vos messages de courte durée. Si vous avez des messages que vous traitez plusieurs heures plus tard, ils risquent de déborder sur le disque. Vous devez donc vous attendre à ce que ces messages soient plus lents que s'ils se trouvaient dans le pool de mémoire tampon.

Pour une file d'attente partagée, la vitesse des messages dépend de la vitesse de l'unité de couplage. Une fonction de mise en cache de cluster dans le processeur physique est susceptible d'être plus rapide qu'une fonction de mise en cache de cluster externe. Le temps de réponse de l'unité de couplage dépend de l'occupation de l'unité de couplage. Par exemple, sur les systèmes Hursley, lorsque la fonction CF était occupée à 17%, le temps de réponse était de 14 microsecondes. Lorsque la fonction CF était occupée à 95%, le temps de réponse était de 45 microsecondes.

Si vos demandes MQ utilisent beaucoup d'UC, cela peut affecter la rapidité de traitement des messages. En effet, si la partition logique (LPAR) est contrainte pour l'UC, les applications seront retardées en attendant l'UC.

Quantité d'UC par message

En général, les messages de plus grande taille utilisent plus d'UC, donc évitez les messages de grande taille (x Mo) si possible.

Lors de l'obtention de messages spécifiques à partir de files d'attente, la file d'attente doit être indexée de sorte que le gestionnaire de files d'attente puisse accéder directement au message (ce qui permet d'éviter une analyse complète de la file d'attente). Si la file d'attente n'est pas indexée, elle est analysée depuis le début à la recherche du message. S'il y a 1000 messages dans la file d'attente, il peut être nécessaire d'analyser les 1000 messages. Il en résulte une utilisation inutile de l'unité centrale.

Les canaux utilisant TLS ont un coût supplémentaire dû au chiffrement du message.

Dans MQ V7 , vous pouvez sélectionner des messages à l'aide d'une chaîne de sélecteur en plus de CORRELID ou MSGID. Chaque message doit être consulté, donc s'il y a beaucoup de messages dans la file d'attente, cela est coûteux.

Il est plus efficace pour une application d'effectuer une opération OPEN PUT PUT CLOSE que PUT1 PUT1.

Déclenchement dans CICS

Lorsque le débit d'arrivée des messages d'une file d'attente déclenchée est faible, il est efficace d'utiliser d'abord le déclencheur. Lorsque le débit d'arrivée des messages est supérieur à 10 messages par seconde, il est plus efficace de déclencher la première transaction, puis de faire traiter un message par la transaction et d'obtenir le message suivant, etc. Si un message n'est pas arrivé sur une courte période (par exemple entre 0.1 et 1 seconde), la transaction se termine. A haut débit, vous pouvez avoir besoin de plusieurs transactions en cours d'exécution pour traiter les messages et empêcher une génération de messages. Pour chaque message de déclenchement produit, cela nécessite une insertion et une extraction d'un message de déclenchement, ce qui, en fait, double le coût du message.

Nombre de connexions ou d'utilisateurs simultanés pris en charge

Chaque connexion utilise de la mémoire virtuelle dans le gestionnaire de files d'attente, de sorte que plus le nombre d'utilisateurs simultanés est élevé, plus la mémoire utilisée est importante. Si vous avez besoin d'un très grand pool de mémoire tampon et d'un grand nombre d'utilisateurs, vous pouvez être contraint pour la mémoire virtuelle et vous pouvez avoir besoin de réduire la taille de vos pools de mémoire tampon.

Si la sécurité est utilisée, le gestionnaire de files d'attente met en cache les informations dans le gestionnaire de files d'attente pendant une longue période. La quantité de mémoire virtuelle utilisée dans le gestionnaire de files d'attente est affectée.

CHINIT peut prendre en charge jusqu'à 10 000 connexions. Ceci est limité par la mémoire virtuelle. Si une connexion utilise plus de stockage, par exemple via TLS, le stockage par connexion augmente, ce qui signifie que CHINIT peut prendre en charge moins de connexions. Si vous traitez des messages volumineux, ils auront besoin de plus de mémoire pour les mémoires tampon dans le CHINIT, de sorte que CHINIT puisse prendre en charge moins de messages.

Les connexions à un gestionnaire de files d'attente éloignées sont plus efficaces que les connexions client. Par exemple, chaque demande client MQ requiert deux flux réseau (un pour la demande et un pour la réponse). Avec un canal vers un gestionnaire de files d'attente éloignées, il peut y avoir 50 envois sur le réseau avant le retour d'une réponse. Si vous envisagez d'utiliser un réseau client de grande taille, il peut être plus efficace d'utiliser un gestionnaire de files d'attente de concentrateur sur une boîte distribuée et de disposer d'un canal entrant et sortant du concentrateur.

Autres éléments ayant une incidence sur les performances

La taille de l'ensemble de données de journal doit être d'au moins 1000 cylindres. Si les journaux sont plus petits que cela, l'activité des points de contrôle peut être trop fréquente. Sur un système occupé, un point de contrôle doit généralement être toutes les 15 minutes ou plus, à des débits très élevés, il peut être inférieur à cela. Lorsqu'un point de contrôle se produit, les pools de mémoire tampon sont analysés et les anciens messages et les pages modifiées sont écrits sur le disque. Si les points de contrôle sont trop fréquents, cela peut avoir un impact sur les performances. La valeur de LOGLOAD peut également affecter la fréquence des points de contrôle. Si le gestionnaire de files d'attente s'arrête de manière anormale, il se peut qu'au redémarrage, il soit nécessaire de le lire à 3 points de contrôle. Le meilleur intervalle de point de contrôle est un équilibre entre l'activité lors de la prise d'un point de contrôle et la quantité de données de journal qui peut avoir besoin d'être lue lors du redémarrage du gestionnaire de files d'attente.

Le démarrage d'un canal entraîne une surcharge importante. Il est généralement préférable de démarrer un canal et de le laisser connecté, plutôt que de fréquents démarrages et arrêts du canal.