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.

La nouvelle version 3.0 de SOAPUI améliore le test des services REST

SoapUI est l’outil indispensable pour développer « graphiquement » des tests de services web. Dans sa version 3.0, il améliore le support des tests de services REST.

Il existe toujours deux versions : une gratuite et open source et une version payante dite “SoapUI Pro”.

Le plugin Eclipse est de plus en plus performant (SoapUI offre aussi des plugins pour IntelliJ IDEA et NetBeans).

SoapUI 3.0, version open source, expose de nombreuses nouvelles fonctionnalités dont :

· Amélioration de support de REST

· Ajout du support de JavaScript (via le moteur Rhino) comme un langage de Scripting.

· Ajout du support du Protocol WS-ReliableMessaging

· Incorporation des outils de test de WS-I Basic profile, issus du ws-i.org (avant il fallait les installer à part)

Pour commencer à utiliser allez à SoapUI 3.0

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.

Les implémentations de JSF ne cohabitent pas en paix : le cas de RichFaces et Sun

Dans un contexte d’une application web : JSF1.2 avec RichFaces 3.3.1, Spring et JPA/Hibernate (et SpringWebflow),

… du très classique, …

sauf qu’on m’a soumit ce bug :

 

ATTENTION: JSF1059: WARNING! The com.sun.faces.verifyObjects feature is to aid developers not using tools. It shouldn''t be enabled if using an IDE, or if this application is being deployed for production as it will impact application start times. 26 mai 2009 20:45:48 org.apache.catalina.core.StandardContext listenerStart GRAVE: Exception lors de l'envoi de l'événement contexte initialise¿½ (context initialized) à l'instance de classe d’écoute (listener) com.sun.faces.config.ConfigureListener com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! null at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:212) at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:174) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) Caused by: java.lang.NullPointerException at com.sun.faces.config.processor.ManagedBeanConfigProcessor.process( ManagedBeanConfigProcessor.java:241) at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:94) at com.sun.faces.config.processor.ValidatorConfigProcessor.process(ValidatorConfigProcessor.java:107) at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(/// at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:94) at com.sun.faces.config.processor.FactoryConfigProcessor.process(FactoryConfigProcessor.java:132) at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:202) ... 16 more

Et l’application ne s’affiche pas, sans aucune autre explication,

Ça laisse perplexe : les «bugs JSF sont connus pour leurs manques d’informations »

Mais,

En étudiant de très prés les librairies du projet on découvre l’existence de deux implémentations de JSF : celle de Sun et celle de Jboss.

Il suffit, alors, d’enlever le fichier « jsf-impl-1.2_06.jar », implémentation de JSF 1.2 par SUN, pour que le projet fonctionne sans aucun problème.

En fait, c’est très simple : les différentes implémentations de JSF ne cohabitent pas aussi pacifiquement qu’on pourrait penser ?

Cloud Computing : Créer votre première application avec GoogleApp Engine et java

Objectif

Ce tutorial a pour but de présenter la démarche à suivre pour déployer une application web Java EE dans la plateforme PaaS de Google : Google appengine.

Pour présenter GAE (Google appengine) : il suffit de pense à un serveur d'applications java capable de supporter une charge importante. Bien sûre, plusieurs API java ont été désactivé, ce qui rend impossible de deployer telqu'elles les applications J2EE classique.

Il permettra de :

- Tester GAE : Faire un premier test du PaaS (Plateforme As A Service) de Google avec java

- Vérifier la courbe d’apprentissage

- Tester les outillages offerts par Google

- Vérifier la qualité des informations présentées par le Tableau de bord : dans le sens vérifier la validité des informations données par le Tableau de Bord (DashBorad) de Google par rapport à des mesures réelles.

Ce tutorial présente une démarche pour passer du monde de développement en local vers l’univers de l’hébergement d’une application dans une infrastructure de type Cloud : Google App Engine. Il couvre les points importants pour créer un compte Google App Engine, le déploiement des versions et le suivi de l’activité de l’application à travers la console d’administration.

GAE c’est quoi ?

Google App Engine est une une plateforme permettant de déployer des applications web Python et maintenant Java, directement dans les Datacenters de Google.

Le découpage des rôles est simple : le développeur crée son application et la déploie dans l’infrastructure de Google App Engine et Google s’occupe de gérer la montée en charge de l’application et facture le temps consommé (après dépassement d’un quota gratuit).

Introduction

On l’attendait pour le milieu de l’année 2009, mais Google vient de la lancer officiellement au début de second trimestre 2009 : La « déclinaison » java de sa plate-forme Googe App Engine est désormais là.

C’est logique : il fallait réagir rapidement : pour faire barrage à Microsoft Azure.

Google se devait de riposter et proposer une alternative pour les développeurs.

La manœuvre est habile : supporter Java 6 et offrir un plugin Eclipse, permettrait à Google d’élargir la base de développeurs cible.

Google vise ainsi à faciliter la réutilisation de code source des applications existantes et à introduire les langages dynamique de type Groovy…

Préparer l’environnement

Créer un compte sur Google App Engine

Pour pouvoir créer un compte Google App Engine, il faut posséder compte email sur Gmail. Ce compte Gmail sera l’identifiant unique à utiliser pour se connecter ( Google a adopté le principe de l'OpenID)

Trois étapes pour créer un compte Google App Engine

ü Demander la création d’un compte le compte

ü Attendre l’arrivée d’un code secret par SMS pour compléter la création du compte GAE

ü Créer une application

Le lien : http://appengine.google.com/

Donner un numéro de GSM, pour recevoir le code d’authentification

En moins d’une seconde j’ai reçu le code du compte par SMS

L’étape suivante consiste à inscrire le code dans la page d’authentification.

Renseigner l’identifiant de l’application

Et le titre.

Ce dernier pourra être changé dans la suite

Enfin, l’application est crée

Application Registered Successfully

The application will use kbdsoft as an identifier. This identifier belongs in your application's app.yaml file as well. Learn more Note that this identifier cannot be changed.

Installer le plugin Eclipse de Google App Engine

J’ai commencé par télécharger Eclipse

La version recommandée est Eclipse 3.4 (Ganymede)

http://code.google.com/intl/fr/eclipse/docs/install-eclipse-3.4.html

Puis utiliser le lien suivant pour installer le pluging Eclipse pour GAE :

http://dl.google.com/eclipse/plugin/3.4

Choir les modules à installer

Vérifier l’installation

Et le paramétrage

Si besoin vérifier la configuration de GWT (Google essaye bien sûre de favoriser GWT, mais l’outil n’est pas limité à GWT)

Développer l’application

Les étapes à suivre dans ce tutorial

a. Récupérer une ancienne application web J2EE (faire un simple Hello World n’a pas d’intérêt, on sait d’avance que ça va marcher)

b. Créer un projet Déployer en local

c. Créer un projet Déployer dans les nuages (GAE)

d. Tester

Choix de l’application test :

Afin d’éviter le « Hello World » j’ai récupéré une ancienne application simple à partir de mon serveur SVN. J’ai choit une application simple pour tester un seul aspect à la fois. L’application date de 2005, cela me permet de vérifier la capacité de GAE à pérenniser les investissements.

En effet, s’il fallait réécrire toutes les applications avant de les déployer sur le Cloud : le concept n’aura aucune chance de survire au BUZZ.

Il s’agit d’une application Web traitant de l’aspect navigation et MVC. Elle est basée sur

· JSP

· Struts

· Struts Menu

Ce tutorial a pour objectif de « prendre la température » de ce que propose Google dans son PaaS, et de vérifier le prédicat suivant : « les développeurs java vont pouvoir capitaliser sur leurs expériences et utiliser les réflexes et habitudes,

Les aspects avancés ne sont pas inclus : ni base de données, ni Spring, ni Hibernate, ces aspects seront testés dans une phase ultérieure.

Cela permettra de vérifier si « dans les nuages », un développeur Java va se sentir « comme chez soit»

Création du projet Web :

La création d’une application est similaire à la création d’une application web avec WTP

J’ai crée ma premier WebApplication

Une fois crée le projet est une application web J2EE classique.

La principale nouveauté est la présence d’un fichier de config spécial de GAE

appengine-web.xml :

<sessions-enabled>truesessions-enabled>

Il suffit de copier les fichiers sources de l’ancienne Application « Version classique 2005 » dans le projet GAE qui vient d’être créer J’ai copier le contenu source de mon ancienne application (date de 2005) J’ai pris le soin de changer web.xml en conséquence J’ai exécuté dans l’environnement local

Exécuter en local

J’ai exécuté dans l’environnement local

Ça marche

On observe une console de déploiement

Cette console n’est pas connu par les développeurs Java EE web d’Eclipse,

Mais elle n’a pas de grande difficulté à l’ appréhender

Ça permet par exemple de lancer le serveur d’application de GAE (du Jetty apparemment)

Le résulta est le suivant

Ça rappelle, à l’identique, le résultat de l’exécution de l’application sur Tomcat en 2005

Mais attention la premier exécution d’un menu n’a pas fonctionné : en effet,

Ça ne marche pas

Google n’aime pas trop l’usage de la session, et impose qu’on le déclare officiellement Il a raison, les pb de perf… Bon, ce n’est pas grave, Il suffit d’ajouter dans le fichier appengine-web.xml (web-inf/) <sessions-enabled>truesessions-enabled> Ainsi le fichier appengine-web.xml <sessions-enabled>truesessions-enabled> Relancer et ça marche

Déploiement dans les nuages (GAE)

Le déploiement dans les nuages

Le déploiement est assez simple : un menu Google est ajouté :

Renseigner le mot de passe de votre compte Gmail

Le log du déploiement

Le module est nommé par Google « com.oxia.gae.kbd.Kbd » (le package par défaut de l’application est com.oxia.gae)

Et voilà

http://kbdsoft.appspot.com/

Une fois déployé et ça marche : il suffit d’ouvrir le lien http://kbdsoft.appspot.com/ dans un navigateur web : une application web déployé dans les nuages