lundi 25 mai 2009

Performance Engineering Process & Solutions : PEP&S

Partie 1 : les types de mesures de performance.

Quelles mesures pour qualifier la performance d’une application

D'un point de vue de l'utilisateur la performance d'une application web se résume à la question suivante "en combien de temps la page est chargée ?"

Des fois, cela relève du subjectif, et de l'expérience personnelle.

Par contre, l'administrateur doit obtenir plus de précision afin de quantifier les performances de son application web. Il doit avoir des éléments quantitatifs afin de formuler un avais objectifs

Ce qui n'est pas mesurable n'existe pas !

Il y a deux mesures importances à obtenir pour quantifier les performances d'une application web

-Temps de réponse

- Débit

On parle ici, de valeurs moyennes

Temps de réponse

Le temps de réponse est le temps qu'il faut pour un utilisateur d'exécuter une opération : la validation d’une opération d’achat (la sélection des produits et la constitution d’u panier n’est pas incluse) : le temps qui s’écoule entre le début de l’action et l’affichage de la page suivante.

En règle générale, vous devez tester cette opération plusieurs fois, et noter le temps de réponse moyen.

Les tests doivent être obtenu en simulant une charge réelle (ou proche du réelle) : Il faut avoir toujours à l'esprit que le temps de réponse dépend de la « charge sur l'application Web ».

Différents scénarii doivent être testés et peuvent avoir des temps de réponse différents.

Débit :

Une autre mesure liée à la performance des applications Web est le débit.

Le débit est le nombre de transactions qui peuvent se produire dans un laps de temps donné.

Le débit est habituellement mesuré en transactions par seconde (TPS).

Toutefois, avant de commencer l'exécution des essais, vous devez être clair sur ce type de performance est prévu à partir du site Web.

Par exemple, vous voulez des réponses ces questions:

  • Combien de temps dure une transaction donnée sur le Web?
  • Combien de temps un utilisateur doit attendre avant le chargement d'une page?
  • Combien d'utilisateurs devrait le site Web de soutien?
  • Quels types de trafic utilisateur prévoyez-vous: y a-t-il des périodes de faible activité et haute activité?
  • Comprendre quel type de trafic Web est prévu est important lors de la conception d'essai de la performance.

Les types de mesures de performance se divisent généralement en deux classes:

Les tests de performances

-En phase de développement

-Lors de la recette applicative

-En phase de maintenance

Le monitoring de l’application

- En production

Les types de tests de performance les plus connus sont:

  • Test de tenue en charge
  • Test en stress
  • Test d'endurance
  • Test de capacité
  • Test aux limites
Test de tenue en charge : :

  • Mesurer les performances de l'application par rapport à un SLA dans des conditions de charge normales et maximales

  • il s'agit d'un test au cours duquel on simule une charge importante d'utilisateurs sur une durée relativement longue, pour voir si le système testé est capable de supporter une activité intense sur une longue période sans dégradation de performances et/ou de diminution notable des ressources applicatives du système.

  • Des synonymes courants sont test d'endurance, de robustesse, de fiabilité.

Test en stress :

• Déterminer les limites de performances de l'application dans des conditions de charge au-delà des valeurs maximales.

  • Déterminer les conséquences d'une charge anormale (erreurs, blocage, …)
  • il s'agit d'un test au cours duquel on va simuler l'activité maximale attendue en heures de pointe de l'application, afin d’évaluer comment le système réagit à une activité "de pointe" des utilisateurs.
Test d'endurance :
  • Test de stress de longe durée, permettant de calculer les valeurs de MTBF (Mean Time Between Failure), MTTF (Mean Time To Failure), ce qui permet de détecter les fuites de ressources (fuite de mémoire, fuite de connexion JDBC, …)
  • il s'agit d'un test qui établit la linéarité du fonctionnement de l'application sur une longue durée (une journée ou un weekend d'utilisation), cela permet de mesurer une dérive des performances due à des fuites de mémoires ou des saturations disques de l'application.
Test de capacité :
  • Déterminer le nombre d'utilisateur / transactions possible pour une configuration matérielle donnée et rechercher un modèle de montée en charge.
  • Il s'agit d'un test au cours duquel on va simuler un nombre d'utilisateurs sans cesse croissant (par paliers) de manière à déterminer quelle charge limite le système est capable de supporter.
Test aux limites :
  • il s'agit d'un test au cours duquel on va simuler une activité bien supérieure à l'activité normale, pour voir comment le système réagit aux limites du modèle d'usage de l'application.
Autre type de test :

Il existe d'autres types de tests, plus ciblés et fonction des objectifs à atteindre dans la campagne de tests : Benchmark (comparaison de logiciels, matériels, architectures, etc.), tests de service, tests de volumétrie des données, etc.

Instrumentation et monitoring :

Avant de lancer la phase production (ou même la phase pilote), il est recommandé de réaliser une instrumentation qui permettra d'observer dans le détail le fonctionnement du système sur la base d'actions réelles des utilisateurs.

Les résultats d'une telle campagne de mesure (à partir d'instrumentation) permettent de connaître les fonctionnalités réellement utilisées, et leur fréquence d'utilisation, ils peuvent ensuite servir de base pour orienter les tests à réaliser dans des simulations futures, lors de la phase de maintenance.

Se Rappeler que la clef de la gestion des performances en des applications web est : Vigilance constante.

Les mesures de performances doivent être inscrites dans le cycle de vie du développement des applications web…

Mais, ceci est un autre sujet..


----

autres sujets traités :

1. Est-ce que vous voulez connaitre ce que fait votre application coté base de données : employer un espion (open source)
2. Performance Engineering Process & Solutions (PEP&S) : Partie 2
3. La nouvelle version 3.0 de SOAPUI améliore le test des services REST
4. Performance Engineering Process & Solutions : PEP&S
5. Améliorer la performance de vos travaux de fin de journée par “JDBC Batch” et Spring
6. Application web : la différence entre Mesure de performance, montée en charge et vitesse d’exécution
7. Are the data from the GoogleApp Engine Dashbord valid?
8. Quel crédit donner aux résultats affichés par le DashBoard de GoogleApp Engine (GAE) ?
9. InfraRED : un outil de suivi des temps de réponse d’application J2EE, de monitoring et diagnostique de problèmes de performance.

0 commentaires :

Enregistrer un commentaire

Architecte SOA & Professionnel Open Source Headline Animator

 
Khaled BEN DRISS
Cloud Computing, SOA et Web 2.0 : Des sujets techniques sur SOA et l'Open Source : de Java & .Net, PHP5, Symfony, à SaaS / PaaS en passant par Azure, google appengine, le BPM, la Modélisation et d'autres sujets du coté du serveur et cloud computing.