Gnome (je rappelle que je suis sous GNU/Linux Debian), dispose déjà d’une petite application de capture d’écrans (gnome-screenshot), qui permet en autres de faire des captures de l’écran complet, de fenêtre seule, immédiatement ou de manière programmée. La capture est soit enregistrée sur le disque dur dans un répertoire cible, soit dans le presse-papiers pour un copier/coller futur.

C’est déjà très bien, mais insuffisant, quand on veut, juste une partie de la fenêtre/écran, pouvoir faire des annotations ou des encadrés. Pour tout cela, je passais par le logiciel de retouche d’images The GIMP. Globalement la solution me convenais, jusqu’à la découverte de Shutter. Avant c’est long (capture, gimp, application cible, etc.), maintenant c’est rapide (tout en un)…

Shutter est une « application évoluée » pour la capture d’écrans. Bien entendu, il sait faire tout ce que fait l’application de base fournie avec Gnome, mais il ajoute dans les fonctionnalités qui m’intéressent :

• Capture de sélection avec possibilité d’ajuster la sélection pendant la capture à la manière de l’outil Rectangle dans The GIMP (on peut donc ajuster les limites de la sélection avant la capture)
• Édition de la capture dans un mini-éditeur, pour permettre par exemple l’ajout d’un encadré, du texte, des flèches, etc. ou bien de recadrer une nouvelle fois la capture
• Enregistrement dans un fichier png (ou autres formats) dans un répertoire cible et dépôt dans le presse papiers pour une utilisation immédiate en coller.
• etc.

Pour le détail, le mieux est de visiter la section Screenshots sur le site de l’application.

Pour l’installation sous Debian Squeeze, c’est :

apt-get install shutter libgoo-canvas-perl

(et leurs dépendances)

La conclusion, c’est que j’en suis satisfait et je sens que je vais passer moins de temps dans la rédaction de procédures ou tutoriels

Un nouveau thème, dont le principal objectif est d’avoir une largeur extensible sur toute la largeur de l’écran (du navigateur).

Cela va permettre plus de flexibilité sur les articles tutoriel, pour les captures d’écran.

./

Il fonctionne à ce jour (août 2008) avec Windows 95, la batterie est morte par contre (c’est bien normal). Evidemment ce n’est pas une bête de course, et avec ses 500 Mo de disque dur, je ne vais pas aller loin maintenant.

Bon, il faut aussi revenir dans le présent, j’ai fait l’aquisition du fameux eeePC d’Asus, j’ai pris le premier modèle, le numéro 701 livré avec la distribution Linux Xandros, ceci via le site de commerce Amazon (très bon prix).

Dès réception, j’ai installé à la place du Xandros, la version Ubuntu eee, histoire de capitaliser sur la distribution Linux que j’utilise sur mon portable actuel et principal (rappel : un Dell D820).

L’installation s’est passée sans problème, et il marche bien. Il est évidemment moins rapide que mon D820. L’impression la plus importante que j’ai, c’est sa petite taille. Sinon la qualité de l’écran est bonne, la taille reste petite aussi avec une résolution faible (800×600) qui nécessite de faire un Zoom Out dans Firefox pour voir les sites web dans toute leur largeur.

La raison de l’achat, est simplement, que vu son faible prix, j’avais envie d’avoir une machine pour s’amuser à tester des choses en dehors de mon ordinateur principal. Il est certain que je ne vais pas m’en servir pour travailler tous les jours avec. Cependant je me vois bien l’amener en vacances avec moi plutôt que le ‘gros’ D820.

Et pour finir une photo d’une petite comparaison de taille avec l’écran fermé entre le Asus eeePC et le Toshiba T2150CDS.

./

Par exemple, vous devez exécuter une requête chaque 20 secondes, le temps de réponse de la dite requête est 4,5 sec. Donc si on démarre à T0, on a T0+4,5 sec la requête, puis on demande à JMeter de faire une pause pendant (20 sec – 4,5 sec = 15,5 sec), puis une nouvelle requête, etc.

Voici comme le faire avec JMeter.

Dans l’élément User Defined Variables, on place une variable qui sera la durée fixe (en millisecondes) de l’intervalle.

On place également un élément Transaction Controller qui contient l’élément HTTP Request (ou plusieurs éléments HTTP Request). A l’intérieur de l’élément HTTP Request (ou du premier élément), on ajoute un élément User Parameters, dans lequel on ajoute une variable START qui sera initialisée à « ${__time(,)} », c’est à dire au temps en millisecondes de début de la requête.

Ensuite en dernier élément du Transaction Controller, on ajoute un élément Test Action, qui sera chargé de mettre en pause le thread group durant l’intervalle de temps d’attente. Pour cela on définit sa durée avec la formule suivante : « ${__longSum(${INTERVALLE},${START},-${__time()})} ». Cette dernière fait le calcul du temps à attendre par rapport à la variable START et la variable INTERVALLE.

On ajoute les autres éléments restants (cookie manager, http request defaults, etc). Puis, on peut lancer un petit tir de contrôle de bon fonctionnement. Ici le Thread Group est à 1-1-4 (1 user, ramp-up à 1 sec, 4 boucles).

Le résultat est ci-dessous. On voit que les requêtes durent en moyenne 5,7 secondes, et que chaque requête est appelée chaque 20 secondes (l’élément Transaction Controller donnant le temps passé de la requête HTTP + du Test Action).

Et voilà, avec ce type de scénario, on peut répondre à un besoin du type « je veux que mon utilisateur exécute chaque 20 secondes une requête quelque soit le temps de réponse de la requête« 

Le script JMeter est téléchargeable ici.

./

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 !

./