OXIA  a le plaisir de vous annoncer le lancement de son cycle de Formations en Technologies Avancées.
Notre objectif est de vous apporter, une offre de formation à la pointe de l’innovation dans les technologies de l’information, basée sur une veille technologique permanente et enrichie des retours d’expériences de nos experts sur des projets concrets.
Les deux prochaines sessions  porteront sur des thèmes d’actualité incontournables pour les décideurs informatiques : l’intégration des applications du SI, les architectures SOA, leurs enjeux et les clés de succès de leur mise en œuvre. Elles seront animées par M. Khaled BENDRISS, Directeur Technique du Groupe  OXIA et expert en architecture des SI.

Nous restons à votre disposition pour toute demande d’information, ou échange nécessaire concernant vos besoins de formation spécifiques.
Dans l’attente de vous servir, veuillez agréer, Madame, Monsieur , l’expression de nos salutations les plus sincères.
Contact : Inès BOURGOU, Responsable de l’offre de formation OXIA.

Formation@oxia-group.com  ou par Tel. +216 71 28 27 00
Visitez  notre blog de veille technologique : http://net-progress.blogspot.com/

télécharger:

Seminaire SOA Open Source V 1-0-0 [Mode de compatibilité]

Seminaire SOA EAI ESB MOM V 1-0-0 [Mode de compatibilité]

    La fiche d’inscriptionContactez-nous !

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 performance 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 :

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

• Le but de l’application web
• Les comportements attendus des utilisateurs
• L’architecture logique de l’application (n-tiers)
• L’architecture physique de l’application (serveurs web, Base de données, etc.)
• L’architecture réseau de l’application

• Identifier les critères d’acceptation de performance

• Déterminer les objectifs des tests (migration, tuning, etc.)
• Estimer la valeur cible de l’usage des ressources et les seuils de tolérance
  • (Par exemple CPU < 75%, 1000 transactions/heure, etc.)
• En déduire les métriques à utiliser (usage CPU, temps de réponse, usage mémoire, etc.)

• Définir les scénarios : concevoir les tests

• Identifier les principaux scénarii d’usage (les principaux use-cases) et les principaux chemins de navigation dans l’application.
• Identifier les données à préparer pour que les tests soient réalistes (liste des clients, liste des produits, etc.)
• Identifier les comportements des utilisateurs.
  • Identifier les erreurs classiques (lors des tests il est important de simuler les cas classiques d’erreurs des utilisateurs).
  • Temps de réflexion (max, min, moyen).

• Configurer l’environnement de test

• Les outils de test utilisés
• L’environnement d’exécution de l’application

• Implémenter les tests : Enregistrer les scénarii

• Les tests doivent être significatifs
  • 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)
  • Ne pas générer des tests trop agressifs

• Exécuter les tests

• Valider les résultats des tests
  • Vérifier que le test fonctionne réellement
  • Vérifier l’absence de problèmes qui faussent les résultats (réseau, disque, etc.)
• Mesurer les réponses
• 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.)
• Archiver les tests

• Analyser les résultats

• Synthétiser les résultats (plusieurs mesures doivent être réalisées pour prendre la moyenne, graphe de synthèse, etc.)
• Rédiger un rapport : interprétation des résultats.

• 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 les temps de réponse du 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 :

1. 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étables” et automatisables.

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 avis objectifs
Ce qui n’est pas mesurable n’existe pas !
Il y a deux mesures importantes à 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 à un utilisateur pour exécuter une opération : la validation d’une opération d’achat (la sélection des produits et la constitution d’un 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éel) : Il faut avoir toujours présent à 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 trouver des réponses aux questions suivantes :

•    Combien de temps devrait durer une transaction Web?
•    Combien de temps un utilisateur doit attendre avant le chargement d’une page?
•    Combien d’utilisateurs devraient visiter le site Web?
•    Quels types de trafic utilisateur prévoyez-vous: y a-t-il des périodes de faible activité et de 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’utilisateurs / 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 de 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.

Il faut toujours se Rappeler que la clef de la gestion des performances 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..

Selon une étude présentée par le site d’information TIC lemondeinformatique, toujours plus d’entreprises découvrent les avantages des wikis : Ils mémorisent les expériences des employés, organisent les projets et accélèrent les flux de travail. Les outils légers Open-Source et les wikis d’entreprise plus compliqués participent à ce processus.

Avant de commencer : Que sont exactement les wikis, et plus particulièrement les wikis d’entreprise?

Au niveau purement technique, un wiki est composé uniquement d’un serveur qui permet aux utilisateurs de créer et de modifier par navigateur les contenus de sites web. Par principe, les wikis ne sont donc rien d’autres que des ensembles de sites web sur lesquels de nombreux utilisateurs écrivent ou tiennent à jour [source LMI, pas wikipedia].

Mais, alors, Comment les Wiki peuvent ils aider les équipes de développement des applications web ?

Je suggère au moins deux axes d’amélioration : l’axe cycle de vie d’un développement logiciel et l’axe produit livré

Sur l’axe de cycle vie de développement :  l’introduction d’un wiki (tel que le fameux confluence de Atlassian le créateur de JIRA ou de XEclipse de Xwiki) dans la gestion du projet de développement permet de capitaliser sur le savoir faire de l’équipe de développement et de le communiquer. Depuis quelques années on admet qu’on arrive à utiliser avec succès le wiki dans la définition du cycle de vie.

Sur l’axe du produit livré:  l’usage d’un Wiki permet de réduire le coût de la réalisation de la documentation du logiciel (l’application web). Le manuel d’exploitation, le manuel d’installation, le manuel utilisateur, ainsi que le support de formation pourront faire l’objet d’un ou plusieurs wikis. L’idéal serait d’impliquer la maitrise d’ouvrage et/ou les utilisateurs dans la création du contenu du manuel utilisateur, dès la phase de réception provisoire.

L’amélioration de ce manuel utilisateur pourra se poursuivre tout au long de la vie de l’application et lors des phases de maintenance (évolutive ou corrective).
Le coût global de réalisation sera réduit, l’adéquation avec les besoins des utilisateurs sera assurée par le simple fait qu’il a été produit par leurs représentants dans l’équipe de développement.

Le Wiki pourra même être intégré à l’application en réalisant le bon choix:

Dans le cas d’application Java EE : il suffit d’utiliser, par exemple, XWiki

Dans la cas .Net : utiliser le wiki de SharePoint (version “gratuite” WSS 3.0 de Windows 2003)

Je présente dans cette étude une expérience simple qui montre l’utilité, d’un point de vue temps de réponse globale, de l’exploitation judicieuse de cette fonctionnalité.

Exécution d’opérations par lot

Pour améliorer les performances lors de la réalisation de mises à jour multiples d’une base de données, un grand nombre de pilote JDBC (Oraxcle, PostgrSQL, MS SQL) offre la possibilité de soumettre plusieurs mises à jour comme un seul travail, appelé également lot.

La méthode addBatch permet d’ajouter une commande.

La méthode executeBatch permet de soumettre toutes les commandes pour traitement.

Seules des instructions DDL (Data Definition Language, langage de définition de données) et DML (Data Manipulation Language, langage de manipulation de données) retournent un seul nombre de mises à jour peuvent être exécutées dans un lot.

La méthode executeBatch retourne un tableau de valeurs int correspondant au nombre de mises à jour de chaque commande.

JSBC et Exécution d’opérations par lot

On l’attendait pour le milieu de l’année, 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’était logique : il fallait réagir rapidement : pour faire barrage à Microsoft Azure.

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

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

Et pour mon premier test, je suis « tombé sous le charme » : il m’a fallu moins d’une demi-heure pour déployer une ancienne application (simple) basée sur Struts sur le cloud de Google

Aucune modification n’a été nécessaire !

Certes : il n’y a avait pas de transaction, de base de données, de Spring, de Hibernate …

Voir le résultat : http://kbdsoft.appspot.com/

Un dashBoard permet de suivre l’activité de l’application :

Mais,

Attention : l’accès gratuit est limité aux 10 000 premiers inscrits.

Affaire à suive (aussi !) ..

InfraRED est très utile pour le diagnostic de problèmes de performances et permet, par exemple, de répondre aux questions suivantes :

• Combien de temps prend une transaction Web particulière?
•  Combien de temps un utilisateur attend avant le chargement d’une page particulière?
• Quelle es la décomposition des temps consommées par chaque composants (http, struts, JDBC, …)?

Il collecte les mesures de temps de réponses sur divers aspects d’une application et les rend disponible pour l’analyse ou à des fin d’alerte ou pour assister dans la phase de recherche de causes pour des problèmes de lenteurs.

InfraRED exploite les mécanises de l’AOP (Aspect Oriented Programming) pour instrumentaliser le code source en ajoutant les instructions de mesure des temps de réponse (AspectJ & Aspectwerkz) au byteCode des applications, déjà déployées dans le serveur d’application J2EE.

 Pourquoi utiliser Infrared ?

  Exemple d’utilisation d’InfraRED

Une fois installé, InfraRED instrumente le bytecode des applications et ajoute des instructions pour le suivie et la calcul des temps de réponses. Il est capable de différencier les types d’appel selon les couches (web, java, JDBC..) :

Il est capable de présenter les temps de réponses pour les classes de Struts (1.2.x)

     Il est capable de présenter les temps de réponses pour les appels de JSP 

SpringSource, continue dans sa lance pour rendre Springframwork incontournable dans le monde java et tout ce qui est en relation avec Java EE.A la base un Ioc, Springframwork a relevé le défi « annoncé » de simplifier le développement Java EE, et peut être avec une arrière pensé «à peine cachée» de s’y substituer.La majorité des projets Sping simplifient le coté « back end   », quelques autres assistent les technologies du client GUI (IHM) : Sping MVC, SpringRCP, support JSF, …Mais voilà, Sping est en phase finale de livraison d’une intégration du monde Flex, à Java EE  avec le monde Java EE, un projet lancé en 2007.

C’est le projet Spring BlazeDS Integration.

Rappelons, que BlazeDS est un complément à Flex pour connecter un(e) RIA (Rich Internet Application) basé sur Flex à des services java dans le Back-end.

En effet, un(e) super RIA sans données « synchronisés » avec les applications du Système d’Information, n’a aucun sens pour des applications d’« Entreprise ».

Ainsi, Spring BlazeDS Integration, est supposé amener vers Flex, une bonne partie des habitués et fidèles de java et Spring Ioc.

Un super cadeau à Adobe (j’espère pour SpingSource qu’il a bien négocié son effort).

Rappelons, qu’un autre projet open source, plus ancien, Granite Data Services (GraniteDS or GDS) est en concurrence avec BlazeDS. Mais que ce dernier, n’ayant pas eu le support direct de SpringSopurce, offre, lui-même, sa propre intégration avec Spring.

Eclipse & Flex :D’un autre coté, la fondation Eclipse, toujours soutenue par IBM, continue à préparer la prochaine version de Eclipse, la fameuse Eclipse e4 (qui est encore à la version 0.9M1 et annoncé pour la mi-2010.).Le plus intéressant, c’est l’effort consenti sur la migration de SWT vers Flex : Code ton application en SWT/java et publie le résultat sous forme SWF de Flex (avec du ActionScript).  L’idée est simple et même pas originale, me dirait on de coté GWT !Le projet n’est pas aussi évident, c’est popur cela que Eclipse creuse d’autre piste en parallèle, SWT vers dojo et RAP (Eclipse Rich Ajax Platform).Spring, Eclipse & Flex : quelle relation ?La question qui se pose alors : Est-ce qu’il s’agit d’une simple réponse, à la demande des utilisateurs de Flex, ou bien d’une prédiction que Flex va remporter la guerre des RIA en relation avec le virage SaaS, et pas seulement la bataille du Web 2.0. Tout cela pour contrer SUN ? et JavaFX ?Si cela se confirme, il est temps d’investir sur Flex! Qui n’est malheureusement pas un standard, et dont la pérennité dépend d’un seul acteur (bien qu’il soit open source).A suivre ..