|    contact    |     link forum    |
Domaines d’application Produits

Modèle d’un rapport MQPerf standard

Le rapport MQPerf standard est un document au format OpenDocument en langue anglaise. La présente page décrit de manière détaillée sa structure et son contenu.

structure générale du rapport

Voici la table des matières typique d’un rapport MQPerf standard :

Technical specifications
Performance tests results
  Maximum throughput per scenario
  Comparison with reference platforms
  Positioning in the community scale
  Reference platforms description
Tests configuration
  Server configuration
  Client configuration
  Configuration in a J2EE application
Detailed durability tests results
  Reading guide
  local, queue, transient
  tcp, queue, transient
  local, topic, transient
  tcp, topic, transient
  local, queue, persistent
  tcp, queue, persistent
  local, topic, persistent
  tcp, topic, persistent
2
2
2
3
3
3
3
3
4
4
5
6
7
10
13
16
19
22
25
28

Les deux premières parties correspondent globalement à un rapport MQPerf community. Les deux parties suivantes sont spécifiques au rapport standard.

caractéristiques techniques

Cette partie, très courte, synthétise les caractéristiques techniques de la plateforme de tests. Sont décrites la nature du ou des processeurs, la taille de la mémoire et la taille disque disponible côté matériel, la nature et la version du système et la version de l’environnement Java côté logiciel.

CPU
Memory size  
Disk size
OS version
JRE version
2 x amd64
2002 Mo
39.440Go
Linux : 2.6.18-128.el5
1.6

tests de performance

Cette partie du rapport vise à afficher les performances optimales de JORAM suivant différents scénarios d’usage classique d’un MOM.

Cinq axes sont explorés, avec 2 ou 3 valeurs par axe, pour un total de 48 scénarios. Les axes sont les suivants :

  • type de destination : queue ou topic
  • persistance : messages persistants ou transients
  • type de connexion : local (inVM) ou tcp connection factory
  • taille des messages : petit (100 o/msg), gros (10 ko/msg), ou spécifique [1]
  • nombre de serveurs JORAM parallèles : 1, 2, ou 4 serveurs. [2]

Un premier groupe de 24 tests explore les différentes combinaisons des axes type de destination, persistance, type de connexion, et taille des messages avec un unique serveur JORAM. Un second groupe de 24 tests explore les différentes combinaisons des axes type de destination, persistance, type de connexion, et nombre de serveurs parallèles pour une taille de messages fixée.

débit maximal par scénario

Un premier tableau donne la valeur brute de débit maximal pour les 24 tests du groupe taille des messages. Cette valeur est donnée en nombre de messages par seconde, et doit donc être multipliée par la taille des messages pour obtenir le débit de données effectif.

Cette valeur de débit maximal doit être comprise comme une cible stable, c’est à dire un débit constant que JORAM supporte sur la durée. Si on considère un débit variable, les valeurs de pic transitoire côté producteur ou consommateur peuvent être supérieures.

PNG - 8.1 ko

Le second tableau se réfère aux mêmes tests du groupe taille des messages, et donne pour chaque test trois valeurs permettant de cerner la latence des messages envoyés.

La première valeur est la valeur moyenne de la latence sur la totalité des messages envoyés lors du test. Indiquée en µs, cette valeur doit normalement rester très faible. La seconde valeur donne une idée de la dispersion des valeurs. Comme la valeur moyenne est généralement très faible, l’écart type habituellement fourni pour indiquer la dispersion est difficilement interprétable. C’est pourquoi nous donnons à la place le pourcentage de valeurs inférieures au double de la moyenne. Enfin la dernière valeur donne la latence maximale rencontrée lors du test.

PNG - 8.9 ko

Le troisième et dernier tableau donne la valeur brute de débit maximal pour les 24 tests du groupe nombre de serveurs parallèles. Cette valeur est le cumul de débit pour l’ensemble des serveurs instanciés sur chaque test.

Par serveur il faut comprendre serveur JORAM, c’est-à-dire une machine virtuelle Java (JVM) exécutant JORAM dans un processus séparé. L’objectif est bien d’exécuter plusieurs serveurs JORAM sur la même machine physique, et non pas de simuler la scalabilité matérielle. Suivant les capacités de la machine, on peut constater une augmentation des performances avec l’augmentation du nombre de serveurs, signe d’une meilleure exploitation des ressources disponibles.

PNG - 7.4 ko

comparaison aux plateformes de référence

Les résultats de la plateforme testée sont comparés aux résultats des tests sur des plateformes de référence. L’affichage se présente sous la forme de deux diagrammes en toile, où chaque axe représente un scénario d’usage.

Le premier diagramme explore les différentes combinaisons des axes type de destination, persistance, et type de connexion pour la petite taille de messages. Le second reprend les mêmes combinaisons pour la grande taille de messages.

PNG - 20.9 ko
PNG - 20.4 ko
PNG - 1 ko

La légende de chaque axe décrit les caractéristiques du test sous forme condensée. Ainsi Q, local, P fait référence au scénario type de destination = Queue, type de connexion = local (inVM), et persistance = messages persistants.

Trois courbes de référence en bleu sont indiquées en plus de la courbe en rouge de la machine testée. Ces courbes permettent de positionner la machine testée vis à vis des machines de référence, pour chaque scénario.

Chaque scénario est en effet indépendant, et chaque axe possède sa propre échelle, même si les valeurs affichées représentent toutes un débit en nombre de messages par seconde. Le centre fait toujours référence à la valeur 0, mais les valeurs maximales sur chaque axe sont indépendantes. L’objectif est clairement de faciliter la comparaison, l’échelle de chaque axe restant linéaire. Ainsi chaque cercle représente un seuil de 20% par rapport à la valeur maximale de l’axe.

Il arrive que les courbes se confondent sur un axe, ce qui veut simplement dire que l’écart entre les deux valeurs est bien inférieur à 5%.

positionnement dans l’échelle communautaire

A partir des 16 scénarios de base qui servent également pour les diagrammes en toile comparatifs, nous calculons un d’indice global de performance de la machine testée. Cet indice est alors replacé dans l’échelle des tests soumis par la communauté JORAM.

PNG - 2.7 ko

Au-delà de l’aspect évaluation de la machine testée, le diagramme présente l’intérêt d’exhiber l’étendue des matériels utilisés pour exécuter JORAM. Il permet du même coup d’avoir une idée assez précise du potentiel de gain de performance que l’on peut obtenir en changeant de matériel.

Bien entendu la validité du diagramme dépend de l’étendue des contributions des utilisateurs de JORAM au travers de MQPerf community. Nous comptons sur la communauté pour que ces contributions soient les plus larges possible.

description des plateformes de référence

Nous avons retenu un certain nombre de plateformes de référence pour réaliser les diagrammes de comparaison. Sont retenues celles dont les résultats sont proches de ceux de la machine testée.

Les plateformes de référence sont les types de machines du cloud EC2 d’Amazon, sur lesquelles nous avons exécuté MQPerf, mais aussi un ensemble d’autres machines variées. Nous comptons enrichir ces références au fur et à mesure de l’usage de MQPerf par la communauté.

Les machines autres que celles de EC2 retenues dans le rapport sont décrites ici en termes de processeur, mémoire, disque, et version de système.

configuration des tests

Un MOM peut être utilisé dans des contextes très variés, et nous configurons JORAM de manière spécifique à chaque test pour obtenir l’optimum de performances. Cette section du rapport standard décrit les paramètres de JORAM sur lesquels nous jouons, leur rôle, et la manière selon laquelle ils peuvent être configurés.

configuration serveur

La configuration serveur est la seule commune à tous les tests. En effet, afin de maintenir la durée totale d’exécution de la sonde dans des bornes acceptables, nous avons choisi de réutiliser la configuration et même le déploiement du serveur JORAM pour tous les tests. Nous avons retenu une configuration médiane, avec notamment le choix d’un composant de persistance transactionnel, et le paramétrage de ce composant.

configuration client

Cette section décrit les paramètres utilisés au niveau de la partie cliente des tests. Les différentes possibilités de paramétrage sont décrites, mais les valeurs elles-mêmes ne sont pas fournies ici. Spécifiques à chaque test elles sont données dans les sections dédiées à chaque test, en amont des premières courbes.

configuration J2EE

Un usager JORAM au sein d’un serveur d’application J2EE ne peut pas accéder aux paramètres de la même manière qu’un usager de JORAM standalone. Cette section décrit comment configurer les paramètres au niveau notamment des Message Driven Beans de J2EE.

tests de stabilité

Les tests de stabilité sont spécifiques au service MQPerf standard. Ils analysent plus précisément le comportement de JORAM sur les 24 scénarios du groupe taille des messages.

L’objectif ici n’est plus de rechercher l’optimum de performance, mais d’observer le comportement de JORAM avec une charge d’envoi de messages autour de l’optimum défini dans la première phase. Le profil de charge est plus précisément le suivant :

  • pendant la première moitié du test, charge à 100% de l’optimum,
  • pendant la moitié du temps restant, charge à 110% de l’optimum,
  • pendant le dernier quart du test, charge à 90% de l’optimum.

L’analyse est organisée en 8 sections, chaque section détaillant une combinaison des axes type de destination, persistance, et type de connexion, en parcourant les trois valeurs possibles de l’axe taille des messages. Dans la présente documentation nous détaillons la première section, à savoir le scénario type de destination Queue, type de connexion local (inVM), et persistance messages transients.

guide de lecture

Cette section rappelle l’organisation de la suite du document, et décrit les différents diagrammes produits. On trouvera notamment dans cette section plusieurs clefs d’interprétation des courbes produites.

local, queue, transient

Cette section décrit en fait trois tests, un pour chaque taille de messages. Dans un premier temps chacun de ces trois tests est décrit spécifiquement à partir d’indicateurs choisis. Ensuite une analyse croisée montre l’impact de la taille des messages sur chaque indicateur, en regroupant les trois courbes de l’indicateur sur un même diagramme.

analyse du test taille de message petite

Le premier diagramme fourni donne le profil de charge et de débit du test pour la petite taille de message (100 o/msg). On trouve sur ce diagramme trois courbes :

  • la consigne de débit d’émission (en jaune), qui marque clairement la phase de surcharge,
  • le débit effectif d’émission (en bleu), censé suivre au plus près le débit de consigne,
  • le débit effectif de réception (en rouge).

L’échelle est en milliers de messages par seconde.

PNG - 8.1 ko
profil de charge et de débit

Ce diagramme donne déjà une bonne idée de la stabilité du système. Une éventuelle dérive importante de la consommation par rapport à la production sera visible par le décalage des courbes bleue et rouge.
Dans la plupart des cas ces deux courbes sont confondues, la courbe rouge cachant la bleue affichée dessous.

Le second diagramme présente l’évolution d’un certain nombre d’indicateurs système qui traduisent la bonne santé de JORAM durant le test. On trouve sur ce diagramme quatre courbes :

  • le débit effectif de réception (en rouge), semblable à la courbe du diagramme précédent mais mesurée d’une autre manière,
  • le nombre de messages non consommés en attente dans la destination (en bleu), indicateur de l’accumulation de messages dans le MOM,
  • un indicateur de charge du module de persistance (en jaune), particulièrement sensible au fonctionnement en surcharge du MOM,
  • la charge moyenne du moteur d’exécution de JORAM sur la dernière minute (en vert), analogue à la commande uptime d’un système Unix.

Sur ce diagramme les valeurs nulles ne sont pas représentées pour gagner en clarté.
Les deux diagrammes partagent le même axe temporel horizontal. Les éventuels événements particuliers qui ont pu survenir durant le test peuvent ainsi être mis en correspondance dans les deux diagrammes.

PNG - 16.6 ko
état global du système

La courbe bleue montre l’accumulation des messages dans le MOM. Il est parfaitement normal que des messages s’accumulent, puisque c’est la première fonction que doit remplir un MOM : le store & forward. Dans le cas de notre test, cet indicateur doit rester stable durant la première moitié, signe de la stabilité du système soumis au débit nominal. Cette valeur n’est d’ailleurs pas forcément nulle, et doit être comparée au nombre de messages envoyés simultanément à chaque appel du client. Elle peut augmenter lors de la phase de surcharge et doit baisser ensuite lorsque la charge se réduit.

La courbe jaune est l’indicateur d’activité d’une partie du module de persistance qui doit, correctement configuré et dans des conditions normales de charge, rester faible. La courbe peut donc être complètement nulle, donc non représentée, ce qui est bon signe. Elle peut également apparaître dans la phase de surcharge, pour diminuer ensuite.

La courbe verte enfin est un très bon indicateur de charge sur le long terme. Il reprend exactement le mode de calcul de l’indicateur uptime d’un système Unix, par ailleurs largement utilisé. Les tests restant relativement courts pour permettre une étude exhaustive des scénarios d’usage dans un temps global acceptable, cet indicateur peut être difficile à lire. On peut toutefois se fier à la pente de l’indicateur, d’autant plus forte que l’augmentation de charge est importante. A titre indicatif un gain régulier de 0,3 sur 20s est la marque d’une augmentation de charge moyenne de 1. On devrait donc constater une pente régulière sur la première moitié du test, un infléchissement lors de la phase de surcharge, et un aplatissement progressif lorsque la charge se réduit.

analyse du test taille de messages grande

On retrouve dans cette section les mêmes éléments que dans l’analyse du test taille de messages petite, concernant cette fois le test pour des messages de 10.000 octets.

L’échelle de certaines courbes dans les diagrammes est bien entendu différente que dans la section précédente, notamment l’échelle des débits de messages. Il faut en tenir compte dans les comparaisons.

analyse du test taille de messages spécifique

On retrouve dans cette section les mêmes éléments que dans l’analyse du test taille de messages petite, concernant cette fois le test pour des messages de la taille fournie par l’utilisateur lors de l’exécution de la sonde. Là encore il faut porter une attention particulière à l’échelle des diagrammes.

analyse comparative

Les quatre indicateurs retenus pour les diagrammes d’état global du système sont repris pour présenter quatre diagrammes comparatifs dédiés. Sur chaque diagramme la courbe bleue représente l’évolution de l’indicateur pendant le test à petite taille de messages, la courbe rouge pendant le test à grande taille de messages, et la courbe verte pendant le test à taille de messages spécifique.

PNG - 10.7 ko
PNG - 5.8 ko
PNG - 2.5 ko
PNG - 7.8 ko

autres tests

Les 7 autres tests sont ensuite traités de la même manière que le premier.

L’analyse des différents diagrammes fournis peut effectivement aider le chef de projet à choisir son mode d’usage privilégié de JORAM, ou a comprendre le fonctionnement d’un système JORAM qu’il aura déjà développé.


[1] taille spécifique uniquement dans MQPerf standard

[2] axe nombre de serveurs uniquement dans MQPerf standard

spatial

Scalagent Distributed Technologies +33 (0)4 7629-7981 +33 (0)4 7633-8773 serge.lacourte@scalagent.com
plan du site  | crédits  | mentions légales