Ceci est particulièrement utile pour décorréler le temps de traitement par rapport au temps de réponse enregistré dans un outil de test de charge, comme JMeter.

Voici comme faire dans Tomcat :

Au niveau du fichier Tomcat_Home/conf/server.xml, on trouve la section suivante en commentaires :

<!--
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>
--->

Il faut d’abord la décommenter, puis modifier l’attribut pattern comme suit :

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt"
pattern='%h %l %u %t "%r" %s %b %D'
pattern="common" resolveHosts="false"/>

Le %D correspondra au temps de traitement de la requête en millisecondes.

Pour Jboss qui, (je le rappelle) contient un serveur Tomcat (plus exactement un dérivé appelé Jboss Web), c’est la même valve que l’on retrouve.

Cette fois-ci, il faut aller dans le dossier Jboss_Home/server/<default|nom instance>/deploy/jboss-web.deploy/server.xml, puis procéder au même type de changement sur l’attribut pattern :

<!-- Access logger -->
<Valve className="org.apache.catalina.valves.AccessLogValve"
prefix="localhost_access_log." suffix=".log"
pattern='%h %l %u %t "%r" %s %b %D'
directory="${jboss.server.log.dir}" resolveHosts="false" />

Bien entendu, dans les deux cas, il faut redémarrer le serveur pour la prise en compte.

Ensuite dans le fichier localhost_access_log.<date>.log, on aura des lignes de ce type :

123.45.67.89 - - [01/Mar/2010:00:05:39 +0000] "POST /App1/Modification.action HTTP/1.1" 200 24039 458

où le 458 à la fin correspond au temps de traitement exprimé en millisecondes.

On notera qu’il est possible de changer (ou d’ajouter) le %D en %T pour avoir le temps de traitement en secondes plutôt que millisecondes.

Plus d’infos sur la valve et les formats possibles ici.

PS. Bien entendu, Apache ou IBM HTTP Server propose la même fonctionnalité. Il peut même être très intéressant de l’activer à son niveau dans le cas d’une architecture de type Apache+mod_jk+Tomcat.

./

Windows Vista

Windows Vista est un (le ?) fiasco incroyable de cette année, sans entrer dans les détails techniques, je dirais simplement que je n’ai personne dans mes différents « paysages » : famille, collègues ou clients qui utilisent Vista (certains l’on testé sans le garder).

• Pour le paysage famille, c’est lié au fait qu’il n’y a pas eu de renouvellement de machines (pourquoi upgrader vers Vista sur sa machine courante ?) ou bien qu’ils sont sous Linux (ma filleule de 10 ans en l’occurrence).
• Pour le paysage collègues, c’est lié au fait que les nouvelles machines acquises sont sous Windows XP (licence Downgrade XP), et que cela ne dérange personne (plutôt le contraire).
• Pour le paysage clients, c’est lié également à la livraison de machines avec Windows XP, et aussi à la politique globale des DSI de conserver Windows XP.

J’ai même parfois suscité de l’intéressement de la part de collègues ou de clients avec mon ordinateur utilisant non pas Windows mais Linux / Ubuntu. Intéressement allant même jusqu’à l’installation pour certains, en espérant qu’ils continuent…

Virtualisation

La virtualisation est devenue pour moi (personnellement) très présente en 2008, tant sur mon ordinateur de travail quotidien (avec VirtualBox) pour :

• avoir Windows XP (Home Edition) pour ouvrir certains documents Microsoft et utiliser Adobe Lightroom pour mes photos
• avoir différents environnements de tests (bien souvent des Linux (Centos, Ubuntu ou RedHat))
• pour faire des démonstrations en donnant une formation (WebSphere Administration)

Que sur mes machines/serveurs ‘physiques’ de tests pour :

• tester Liferay (VMWare / Centos)
• mettre en place un cluster Alfresco sur Jboss (VMWare / Centos)
• avoir une machine DVL (VirtualBox / DawnLinuxVulnerable) pour effectuer des tests de sécurité
• tester la mise en cluster de CAS (VMWare / Central Authentification Service)
• etc.

Je n’ai pas fini d’utiliser la virtualisation. Tant mieux, d’autant que les clients commencent à y réfléchir très sérieusement, non pas pour faire des petits environnements de tests comme moi, mais plutôt pour avoir des desktops virtualisés et/ou des environnements serveurs virtualisés. Vmware ESX et le futur oVirt de RedHat vont certainement faire partir des choses à connaître en 2009.

Les performances applicatives, les tests de charges

Dans mon paysage client, tous ont des objectifs de performances pour les nouvelles applications qu’ils lancent. Signe d’une nouvelle maturité ? Oui et non. Certains ont vécus des soucis sur des applicatifs lancés qui se sont révélés peu performants et qui ont nécessité des diagnostics, des corrections et des optimisations à faire dans l’urgence (et souvent sous pression), d’autres n’ont pas envie tout simplement de vivre cela, et incluent le test de performance (de charges) en bout de chaîne avant la mise en production.
Là pour 2009, il va falloir éviter de mettre des « couches supplémentaires » pour palier aux problèmes, mais plutôt inclure la notion de performance et optimisation directement auprès du développeur. Ceci permettant d’avoir des applications avec de la performance en « natif ». Il y a bien des formations pour le développement orientées sécurité, pourquoi pas des formations orientées optimisation…

La sécurité applicative

Pour parler un peu de la sécurité applicative en 2008, je dirais : « encore inconnue » dans la réalité, bien qu’on en parle et que l’on aimerait bien l’avoir dans ses applicatifs, mais pour l’instant on n’a pas le temps de s’en occuper… (je dirais) De toutes les façons, les cabinets d’audit de sécurité vont nous dire quelles sont les failles que nous avons…

Les applications Web
On parle du Web 2.0 (et même d’Entreprise 2.0), des nouvelles façons d’utiliser l’outil Internet. Aujourd’hui (et ici au Maroc), les applications Web sont de « véritables applications ». C’est-à-dire qu’elles fournissent un lot de fonctionnalités important (on s’en doute), de la convivialité (ajax/flex merci), et tout, et tout. Cependant on notera la tendance des clients à demander des interfaces (écrans) qui remplissent complètement la largeur de l’écran de la machine. En gros avoir des applications qui profitent des espaces blancs habituels à gauche et à droite sur les cotés du navigateur (regarder sur ce blog ). Je pense que cela provient 1/ du fait que les écrans de machines (notamment les portables) sont devenus très larges, et 2/ des interfaces de type Gmail/Google qui sont extensibles.

On dit souvent que le navigateur est devenu le « nouveau » système d’exploitation, c’est à dire que finalement l’utilisateur ne voit plus que la dernière couche de ses applications. La tendance des « applications à écrans larges » est juste dans la continuité des choses.

OpenOffice(.org)

L’intérêt d’OpenOffice, sans forcément donner lieu à des passages vers OpenOffice, est grandissant. Mes interlocuteurs connaissent cette suite bureautique, et ont envie de savoir si c’est « compatible » avec la suite Microsoft Office, d’autant que parfois le passage à Office 2007 n’a pas toujours été bien vécu (pour mes interlocuteurs professionnels). Quant à mon entourage familial, je pratique la conversion à OpenOffice (sous Windows ou Linux) avec une petite formation à l’appui plutôt que leur installer une suite MS Office (je rappelle aussi que c’est payant : en France, ~99 euros pour Office 2007 en pack Etudiant / Famille !). Ensuite on ne me demande plus d’avoir MS Office…

On ajoutera que Microsoft dans le SP2 d’Office 2007 va permettre de lire des fichiers OpenOffice, ce qui viendra ajouter à la compatibilité bi-directionnelle des formats bureautiques.

SPAM

Le SPAM, bien que toujours (et même extrêmement) présents sur les ‘câbles’ Internet, n’est plus l’ennui récurent qu’il était. En effet, les filtres anti-spams tant du côté des serveurs de messageries que du coté des postes clients (outlook, thunderbird) sont devenus performants, à tels points que je n’ai que très épisodiquement un mail de spam sur mes différentes boîtes aux lettres. Merci.

Ubuntu

Sans dire qu’il s’agit de la meilleure distribution pour poste de travail, son petit coté « si il existe des drivers non-opensource pour un périphérique, alors on le distribue aussi » est bien pratique par rapport à d’autres distributions. Toujours est-il que je suis très satisfait d’avoir un poste de travail Linux / Ubuntu qui fonctionne bien, rapide, stable et qui sait profiter de mes 4 Go de mémoire (le coté 64 bits).

La future release de Ubuntu (9.04 Jaunty Jackalope, prévue le 23 avril 2009) s’annonce exceptionnelle avec OpenOffice 3, Xorg 1.6, le dernier noyau Linux 2.6.28, Firefox 3.1, Thunderbird 3, etc… (on en reparlera…)

Je finis ce bilan, par quelques notes :

1. Le blog n’a pas été toujours facile à maintenir à jour cette année, bon gré, mal gré, des événements et actualités professionnelles et personnelles. Mais cela reste très gratifiant à tous les points de vue.
2. JMeter fait son petit bout de chemin, les billets relatifs à ce sujet ont leurs visites qui augmentent de mois en mois. Peut-être est-ce dû au fait qu’il y a peu de documentation francophone sur JMeter (ce blog est assez bien placé sur google.fr avec le mot-clé Jmeter du coup). Le groupe « JMeter en français » n’est pas un groupe très actif, mais se réveille de temps en temps pour soulever des points souvent très intéressants.

Pour conclure, une bonne année 2008 d’un point de vue informatique pour moi. Les choses bougent, Linux est vraiment bien en tant que desktop.

J’en profite pour vous souhaiter une excellente année 1430 (calendrier musulman, car aujourd’hui c’est le 1er Moharem) et une excellente année 2009 (calendrier grégorien/international) !

./

(titre en anglais : Performance Testing Guidance for Web Applications)

C’est un livre de 221 pages, découpé en 8 parties (pour un total de 18 chapitres) :

1. Une introduction aux tests de performances, qui vous donnera un aperçu des différents types de tests de performances, les concepts clés et le vocabulaire utilisé.
2. Une approche modèle sur le test de performance, à travers 7 macro activités. Cette partie montre également comment intégrer les tests de performances dans les environnements Agile et CMMI.
3. Identification de l’environnement de test, qui montre comme collecter les informations nécessaires sur un projet à tester, allant des architectures systèmes au activités utilisateurs, etc.
4. L’identification des critères d’acceptance du tir de charges, qui permettent de déterminer les objectifs du tir.
5. La conception et la planification des tests, qui montrent comment modéliser la charge tout en prenant compte des retours des utilisateurs pour concevoir un test de performance adéquat.
6. L’exécution à proprement parlée, des tests des performances.
7. L’analyse des résultats du tir, et la génération du rapport, qui montrent comment organiser et présenter les données de façon faire passer l’information du rapport de manière efficace.
8. Pour finir, deux techniques de tests de performances pour une application Web, le tir de charges et le tir de stress.

Comme on peut le voir il s’agit d’un programme complet et méthodologique sur les tests de performances.

Je ne vous donne le contenu détaillé du livre, mais on en a pour « son argent » d’autant qu’il est gratuit. On en tire des enseignements, de la méthodologie, du vocabulaire et une vision très professionnelle du test de performances.

En conclusion, je vous recommande sa lecture.

./

En effet, vous allez développer une application hyper véloce, la faire fonctionner sur des serveurs hyper-rapides, mais votre utilisateur au bout de la ligne vous dit que c’est lent…

Vous (re)faites vos tir de charges, vous mesurez les performances, c’est excellent… sur votre réseau local. Vous placez un injecteur chez votre utilisateur final, et là c’est la surprise… c’est lent.

Le diagnostic est rapide : trop d’octets à transférer pour afficher un écran, avec une bande passante trop petite donc lenteurs. Et impossible d’augmenter la bande passante. Que faire ?

Bien entendu, il est possible (et il faut) optimiser ses pages HTML / XML, le taux de compression des images, etc. de son application. Tout ceci dans l’objectif de réduire le poids général en octets d’un écran.

Il y a aussi une astuce tout simple. La compression des données transitant entre le serveur Web et l’utilisateur final à travers la compression HTTP.

Cette compression basée sur l’algorithme des fichiers ZIP, est effectuée au niveau du serveur Web qui compresse à la volée les données à transmettre. Ensuite la décompression est assurée du coté des navigateurs Web.

Pour que cela marche, il faut bien entendu un navigateur récent (au moins IE 4.0, Firefox 1.0, etc) mais c’est le cas de tout le monde. Pour le serveur Web, il lui aussi doit être relativement récent (au moins IIS 5.0, Apache 2.x, etc). Il y a ensuite une configuration à faire à son niveau pour activer la compression.

Pour Apache, par exemple, c’est le module mod_deflate (et aussi mod_gzip) qui assure cette fonction. On peut ainsi ajouter dans son virtual host, les lignes suivantes (tirées que la documentation Apache) pour compresser tous les flux sauf les images.

# Insert filter

SetOutputFilter DEFLATE

# Netscape 4.x has some problems...

BrowserMatch ^Mozilla/4 gzip-only-text/html

# Netscape 4.06-4.08 have some more problems

BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine

BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# Don't compress images

SetEnvIfNoCase Request_URI \

\.(?:gif|jpe?g|png)$ no-gzip dont-vary

Après le redémarrage du serveur Apache, le résultat donne, par exemple, pour la page d’accueil de ce blog (juste le contenu HTML) :

• Avant, sans compression : 50 198 octets transférés
• Après, avec compression : 11 903 octets transférés

Soit une diminution de 38 ko (-76%) à transférer sur le réseau ! C’est pas mal comme optimisation ? Et en plus c’est transparent pour tout le monde.

Ainsi, avec l’activation de la compression, les bons temps de réponses de son application ne seront pas masqués par les temps de transferts réseaux importants, et l’utilisateur au bout trouvera l’application rapide.

[Quelques pointeurs]

• Apache – module mod_deflate
• Wiki : la compression HTTP
• La compression HTTP par son inventeur

./

]]> http://blog.milamberspace.net/index.php/2008/07/06/compression-http-ou-comment-reduire-le-temps-reseau-dans-les-performances-dune-application-80.html/feed 2 http://blog.milamberspace.net/index.php/2008/05/01/redbooks-linux-performance-and-tuning-guidelines-74.html http://blog.milamberspace.net/index.php/2008/05/01/redbooks-linux-performance-and-tuning-guidelines-74.html#comments Thu, 01 May 2008 18:58:39 +0000 Milamber http://blog.milamberspace.net/index.php/2008/05/01/redbooks-linux-performance-and-tuning-guidelines-74.html Linux ayant une place importante dans mon utilisation informatique, il est bien normal d’être à l’affût de bons documents dessus. IBM via son site de publications Redbooks nous propose un excellent document sur les performances et l’optimisation de Linux (il s’agit en réalité d’une mise à jour d’un document déjà sorti en juillet 2007).

Redbooks : Linux Performance and Tuning Guidelines

Ce livre nous propose ainsi une large introduction au fonctionnement interne de Linux au niveau de la gestion des processus, les architectures mémoire (en particulier les différences entre systèmes 32 bits et 64 bits), les systèmes de fichiers (ext3, ext2, etc.), la gestion des entrées / sorties et la gestion du réseaux. C’est extrémement instructif.

La suite est un panorama des outils disponibles sur les distributions Linux pour la supervision et le benchmark. Chaque outil est expliqué, en particulier l’interprétation des données affichées.

Les deux derniers chapitres nous montrent d’une part les méthodes d’identifications des goulots d’étranglements (bootlenecks) au niveau CPU, mémoire, disques et réseaux. Et d’autre part des techniques d’optimisation de sa machine Linux (orienté serveur).

Pour résumé, ce document doit être une référence pour tout bon administrateur système qui s’occupe de serveurs Linux ou tout personne soucieuse (comme moi) des performances des bécanes !

Bon lecture.
./

On aura ainsi :

• les « tireurs » ceux qui vont faire le tir de charges avec un outil dédié,
• les fonctionnels qui assistent les tireurs pour la scénarisation du tir,
• les préparateurs de données qui sont chargés de fournir des données aux injecteurs pour le tir,
• les gens du réseau pour la surveillance du trafic et de la bande passante,
• les DBA pour la surveillance de l’activité de la base de données,
• les superviseurs des serveurs d’applications pour monitorer l’activité de l’application,
• l’équipe de développement de l’application qui croisent les doigts,
• et bien sur les chefs du fonctionnel et les chefs de la technique

Tout cela fait beaucoup de monde, on ajoutera en général un responsable général, chargé entre autre de synchroniser toutes les actions, et donner le GO du lancement.

Une fois que le tir lancé et terminé, l’expérience montre que c’est en général du coté du serveur d’applications J2EE que les problèmes sont visibles. Où s’ils ne sont pas visibles, on pense à lui en premier car c’est lui qui supporte l’application. Alors quand c’est vous le responsable de la supervision du cluster de serveurs d’applications, tout ce beau monde se retourne vers vous pour avoir l’explication, le comment du pourquoi, afin de comprendre la raison du non succès du tir de charge…

Pourtant vous avez fait une configuration des serveurs d’applications clustérisés aux petits oignons :

• configuration de la taille minimum et maximum idéale pour ce type d’application
• modification des paramètres de JVM pour avoir notamment un fonctionnement du Garbage Collector en (quasi) parallèle (Concurrent Mark Sweep)
• réglage des unités d’exécution min et max, temps d’inactivité
• réglage du pool de connexions à la base de données, avec activation du cache des requêtes SQL préparées
• réglage du gestionnaire de sessions
• activation du monitoring,
• et d’autres petits réglages de derrière les fagots : taille des files d’attente TCP, nombre des requêtes keep-alive, etc

Alors avec ce tunning de folie, difficile de comprendre pourquoi le serveur d’applications souffre lors du tir de charges…

Voici quelques cas, dont le problème est visible sur le serveur d’applications, mais l’origine est ailleurs :

1/ le serveur d’applications explose en OutOfMemory… C’est en général de la faute à l’application développée ou de l’utilisation du framework de persistence (genre Hibernate). Un exemple, c’est le chargement de plusieurs fois un million d’enregistrement dans la mémoire (car plusieurs centaines d’utilisateurs simulés et non plus les quelques développeurs et testeurs de la recette). On aura ainsi par exemple, 100 fois 10 Mo dans la mémoire soit au moins 1Go, donc des OutOfMemory si la taille maximum de la mémoire JVM est à 1024 Mo.

2/ le nombre maximal des unités d’exécution est atteint. C’est en général de la faute de l’application développée ou bien de la base de données. En effet si le nombre max est atteint, mais que la CPU du serveur n’est pas utilisée, on peut en déduire que les unités d’exécution sont en attente de quelque chose… Et souvent c’est de résultat de la base de données. Soit cette dernière est surchargée, soit il manque quelques index quelque part ou tout simplement il faut régénérer les statistiques de la base de données.

3/ Tout va bien sur le serveur d’application, sur la base de données, etc, mais l’application est « lente » à la réponse. Et bien là on peut se poser la question du réseau. Il convient de s’assurer que toutes les cartes réseaux soient configurées en 100 Mbits/s Full Duplex (ou en gigabit), que les switchs d’interconnexion également (port par port), et les routeurs si il y a lieu. Le mieux est de faire un test FTP (via un client classique vers le serveur, ou via JMeter). En effet, on verra que si l’une des interfaces est en 10 Mbits/s half duplex, par exemple celle du répartiteur de charges, et l’ensemble des serveurs derrière ne seront pas surchargés, mais l’application sera désespérément lente (goulot d’étranglement sur le lien réseau). (pour l’histoire, une interface réseau peut basculer en 10 Mbits/s HD tout simplement car l’auto négociation de vitesse avec le switch a échoué, et ainsi la carte prend la valeur la plus basse…

4/ Les pages de l’application affichent des erreurs 500… c’est en général un problème applicatif engendré par un problème externe. Par exemple l’atteinte du nombre maximum autorisé de fichiers ouverts pour un processus, ou bien la base de données n’accepte plus de nouvelles connexions…

Par ailleurs, on peut aussi avoir un cumul de ces problèmes, et chaque tir de charges montrent un nouveau problème…

Mais quand tout est bien réglé, c’est à dire que l’ensemble des composants de la solution est bien paramétré, avec de la logique, et bien le tir de charges se passe à merveille !

./