Catégorie : Non classé

Apache JMeter 4.0 est sortie, bienvenue au nouveau thème Darcula!

Une nouvelle version d’Apache JMeter vient de sortir. Estampillée 4.0 c’est une version qui est accompagnée d’un nouveau thème nommé Darcula (et non c’est pas Dracula…). Le thème est sombre et apporte pour un petit coup de jeune à ce vénérable et dynamique JMeter.

La liste des nouveautés est longue, et voici quelques nouveautés notables de mon point de vue :

  • Possibilité d’avoir des messages d’erreur d’assertions personnalisés
  • Nouvel ordonnancement des menus/éléments : les plus courants sont en premier dans la liste
  • Nouvel élément de type Compteur : Precise Throughput Timer
  • Par défaut c’est en anglais que JMeter affiche son interface
  • Le plan de travail (workbench) a été retiré de l’arbre par défaut dans JMeter
  • 5 nouvelles fonctions font leurs apparitions :
    • __digest() pour effectuer des empreintes cryptographiques (MD5, SHA, etc)
    • __dateTimeConvert() pour faire des changements de format de date
    • __changeCase() pour les changements de casse de caractère
    • __isVarDefined() et __isPropDefined() pour savoir si une variable ou un propriété est définie

La liste complète des nouveautés et corrections d’anomalies est ici.

Amusez-vous bien avec Apache JMeter!

 

Shutter, Application évoluée de capture d’écrans (sur GNU/Linux)

Je fais beaucoup de captures d’écrans pour la rédaction de procédures, tutoriels (cf. ce blog;-) et autres diapositives de formation.

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.

Shutter : application de capture d'écrans

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 😉

 

Changement de thème pour le blog

Comme vous le constatez, le blog change de peau.

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.

./

Mon eeePC 701 et mon premier ordinateur portable (Toshiba T2150CDS) datant de 1996

Un tour de nostalagie avec mon premier ordinateur portable, il s’agit d’un Toshiba T2150CDS datant de l’été 1996. Le processeur est un 486 DX, cadencé à 75 Mhz ! La belle époque.

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.

Mon premier ordinateur portable datant de 1996

Continuer la lecture de Mon eeePC 701 et mon premier ordinateur portable (Toshiba T2150CDS) datant de 1996

Tir de charges : Quand les problèmes ne viennent pas du serveur d’applications

Pour les « grands » tirs de charges dont l’objectif est de tester une nouvelle application J2EE (ou JEE) avant sa mise en production, et afin d’éviter les crashs le jour du lancement, on mobilise en général une équipe des différents « corps de métier » informatiques.

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… Continuer la lecture de Tir de charges : Quand les problèmes ne viennent pas du serveur d’applications