Performance Engineering Process & Solutions (PEP&S) : Partie 2

Partie 2 : le processus

Les tests de performance doivent être implémentés et réalisés tout au long du cycle de développement.

Il est recommandé d’intégrer les mesures de performances dés les premières itérations :

- Tester le POC & l’architecture de base

- A 20 % du projet,

- A chaque jalon important

Le processus itératif se résume en :

Pour ce faire, nous mettrons en œuvre l’approche suivante pour chaque campagne de tests :

1. Identifier l'environnement de test : L'environnement de test doit être si possible identique à l’environnement de production. Pour cela, nous devons comprendre :

a. Le but de l'application web

b. Les comportements attendus des utilisateurs

c. L'architecture logique de l'application (n-tiers)

d. L'architecture physique de l'application (serveurs web, Base de données, etc.)

e. L'architecture réseau de l'application

2. Identifier les critères d'acceptation de performance

a. Déterminer les objectifs des tests (migration, tuning, etc.)

b. Estimer la valeur cible de l'usage des ressources et les seuils de tolérances

(Par exemple CPU < 75%, 1000 transactions/heure, etc.)

c. En déduire les métriques à utiliser (usage CPU, temps de réponse, usage mémoire, etc.)

3. Définir les scénarios : concevoir les tests

a. Identifier les principaux scénarii d'usage (les principaux use-cases) et les principaux chemins de navigation dans l'application.

b. Identifier les données à préparer pour que les tests soient réalistes (liste des clients, liste des produits, etc.)

c. Identifier les comportements des utilisateurs.

i. Identifier les erreurs classiques (lors des tests il est important de simuler les cas classiques d'erreurs des utilisateurs).

ii. Temps de réflexion (max, min, moyen).

4. Configurer l'environnement de test

a. Les outils de test utilisés

b. L'environnement d'exécution de l'application

5. Implémenter les tests : Enregistrer les scénarii

a. Les tests doivent être significatifs

i. Ne pas répéter la même transaction avec les mêmes données (résultats faussés à cause du cache de données)

ii. Ne pas générer des tests trop agressifs

6. Exécuter les tests

a. Valider les résultats des tests

i. Vérifier que le test fonctionne réellement

ii. Vérifier l'absence de problèmes qui faussent les résultats (réseau, disque, etc.)

b. Mesurer les réponses

c. Déterminer les lignes de base à utiliser pour évaluer les améliorations amenées par la variation d'un seul paramètre (mémoire, connexion JDBC, etc.)

d. Archiver les tests

7. Analyser les résultats

a. Synthétiser les résultats (plusieurs mesures doivent être réalisées pour prendre la moyenne, graphe de synthèse, etc.)

b. Rédiger un rapport : interprétation des résultats.

8. Optimiser le système

Place du PEP&S dans le cycle de développement des applications web

Tous les acteurs s'accordent sur la nécessité des Mesures de Performance et de leurs analyses, mais, les opinions divergent quand au moment.

La meilleure réponse est de rendre le PEP&S une partie intégrante du cycle de développement des applications web.

La mise en place du processus PEP& se résume en

• Évaluer le problème

• Mesurer le système

• Analyser les données

• Identifiez les goulots d'étranglement

• Optimiser le système

D’habitude, lorsque le chef de projet pense à réaliser une étude de performance il la planifie dans la phase de recette définitive. Or, la découverte d’un problème de performance à ce stade représente un danger pour le projet dans sa totalité. Il est important de planifier le suivi des performances dans les différentes phases du projet :

– Développement

• Profiling

• Logging

• Test Unitaire

– Assurance qualité / Staging

• Test fonctionnel

• Performance / test de charge

• blocage / tuning / amélioration de Performance

– Production

• Étude de la trace et vérification

• Disponibilité

• SLA (Service Level Agreements)

Le processus pourrait être résumé ainsi :

Il est recommandé de penser aux objectifs de performances très tôt :

– Fixer les cibles "lignes de base" /benchmarks

• Mettre en application une méthodologie qui permet la mesure des performances par rapport aux cibles "lignes de base" /benchmarks .

• Utiliser les bons outils.

• Construire des scripts de test "répétable" et automatisable.

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.