Passage à Debian 7 (testing), nom de code Wheezy

J’ai fait l’acquisition d’un disque dur de 1 Téra-octet pour remplacer le disque de 500 Go de mon ordinateur portable (le fameux Dell E6500). Et oui, l’espace disque se remplit vite avec des machines virtuelles, les fichiers ISO des quelques distributions Linux que je manipule (Debian, Ubuntu, Centos et RedHat) dans le travail et tout le rester (applications, documents, photos, vidéos, etc.)

Tout cela pour dire que j’ai profité de la migration vers ce nouveau disque pour passer à Debian Wheezy, la future version 7 (dépôt testing donc).

La version testing a été gelée fin juin 2012, donc plus de montée de version majeure des logiciels dans ce dépôt, la priorité est donnée à la correction des anomalies en prévision de la version finale prévu fin d’année ou début 2013. Noter que (il me semble) : une version testing gelée de Debian est plus stable qu’un Ubuntu venant de sortir.

Et donc, me voilà avec Gnome 3 et son gnome-shell qui vient bousculer ma façon de « voir » mes applications quand je travailler sur l’ordinateur. Je ne vais pas vous la jouer « c’est nul, je veux retourner à Gnome 2 » car cela fait un bon moment que je surveille Gnome 3 et le teste sur une machine virtuelle. C’est nouveau, et comme toute nouveauté, il (me) faudra une période d’adaptation, et de prise de nouveaux repères. En espérant que je ne fasse pas un retour-arrière comme à l’époque du passage de Ubuntu 9.10 vers 10.04.

Quelques retours sur mon installation Debian 7 et Gnome 3 : Continuer la lecture de Passage à Debian 7 (testing), nom de code Wheezy

Rapport de (très) gros test de charge avec la solution BlazeMeter

Dans ce premier billet, je vous présentais la solution de test de charge dans les nuages BlazeMeter, basée sur l’outil Apache JMeter, illustré par un petit test. Dans ce nouveau billet, on passe aux choses sérieuses : le (très) gros test de charge.

Mon objectif était le suivant : faire un tir de charge avec 100 000 utilisateurs virtuels actifs.

Pour faire ce type de gros test, depuis les nuages, il faut un serveur cible (ou une solution cible). Pour ma part, j’ai eu la possibilité d’avoir un prêt d’un très gros serveur situé dans un centre de données à Poitiers/France connecté directement sur une importante dorsale Internet via une liaison à 100 MBits/s. Autrement dit le serveur était bien placé sur Internet pour être attaqué par la solution BlazeMeter.

Le serveur en question est un Dell R815, ayant 4 CPU de 12 cœurs chacun (AMD Opteron 6176), soit 48 coeurs, accompagné de 256 Go de mémoire RAM, connecté à 1 Gbits/s (en ip bonding) sur un commutateur en liaison avec un pare-feu BSD (en mode NAT). Le système d’exploitation dudit serveur est GNU/Linux Debian 6.0.5 en 64 bits.

Le serveur était totalement disponible pour ce test (pas d’autres services tournant dessus).

L’idée étant de faire un test de charge pour « tester » la solution BlazeMeter, et non pas de tester la performance du serveur cible, j’ai choisi de ne mettre qu’un serveur Web Apache avec 3 pages HTML statiques. Le serveur Apache est configuré avec mod_deflate et mod_cache.

Le scénario de test sera le suivant :

  1. page d’accueil (+assertion réponse)
  2. page A (+assertion réponse)
  3. page B (+assertion réponse)

 

Apache JMeter dans les nuages : BlazeMeter, mon premier test

Voici un premier billet sur la solution de test de charge BlazeMeter, basée sur Apache JMeter.

 

 

Tout d’abord une petite présentation de BlazeMeter (d’après ma compréhension).

BlazeMeter profite de l’informatique dans les nuages (Cloud Computing), plus précisément de l’offre de serveurs à la demande d’Amazon AWS (ce type d’offre s’appelle PaaS pour Plateform as a Service), sur laquelle, les gens de BlazeMeter orchestre la mise en oeuvre de JMeter sur des serveurs virtuels pour lancer des tests de charge JMeter, avec en plus l’ajout de graphiques pour suivre son tir, ainsi que de rapports de test sur les résultats du test de charge.

Je suis assez admirateur de leur solution, qui montre que l’on peut faire une très belle solution de test de charge sous forme de SaaS (Software as a Service) avec ce beau logiciel Apache JMeter !

Je vous propose donc dans ce premier billet de découvrir la solution BlazeMeter à travers un petit test (micro) de charge sur mon blog. Continuer la lecture de Apache JMeter dans les nuages : BlazeMeter, mon premier test

JMeter article : Tutoriel Réalisation d’un scénario de test de charge pour l’application Spring PetClinic

Voici la suite de la présentation de JMeter par Antonio Gomes-Rodrigues. Dans son billet-tutoriel, on travaille sur l’application Démo Pet Clinic de Spring. Chaque étape pour la mise en place d’un scénario de test de charges y est détaillée, avec son lot d’astuces.

D’ailleurs j’ai même appris une astuce ! Celle qui consiste à mettre un compteur de temps en fils du serveur Proxy HTTP (de JMeter), afin que les requêtes générées lors de la session de navigation modèle aient directement un compteur de temps en fils !

Un dernier mot : merci à Antonio pour ce billet !

Apache JMeter 2.7 est sortie

Une nouvelle version de JMeter vient tout juste d’être publiée. A peine quatre mois après la version 2.6 datant du 1er février 2012, voici déjà la version 2.7 !

Cette nouvelle version corrige des anomalies bien entendu, mais également apporte quelques nouveautés et améliorations.

Un nouvel échantillon Appel de Processus Système fait son apparition. Il permet de demander à JMeter de lancer et exécuter un programme situé sur la machine, tout en permettant l’ajout de paramètres et de variables d’environnement à ce programme. Continuer la lecture de Apache JMeter 2.7 est sortie

Mettre à jour la base tzdata (Olson database) sur son Nokia N9 (heure d’été)

Aujourd’hui au Maroc c’est le passage à l’heure d’été (qui a eu lieu à 2h du matin avec l’ajout de 60 minutes).

Dans un précédent billet, je montrais la façon de refaire une « mise à jour personnalisée » de tzdata sur Debian. D’un autre coté, ce matin je cherchais le moyen de faire la même chose sur mon Nokia N9 afin de le passer à l’heure d’été aussi (GMT+1 au lieu de GMT+0).

L’idée étant d’avoir le bon horaire, et aussi le bon décalage avec les autres pays, afin que notamment la date des emails, twitters, etc. soit la bonne.

Donc, j’ai passé un peu de temps à essayer de faire la procédure de mon précédent billet puisque le N9 utilise aussi le système de paquetage de Debian et que j’ai d’installé le SDK du N9. Malheureusement cela n’a pas voulu fonctionner tout de suite (une erreur en cachant une autre).

Après une seconde de réflexion, je décide de faire une recherche Google pour voir si quelqu’un n’a pas eu l’idée de mettre à jour son tzdata avant moi.

Et là bingo, on trouve ce fil de discussion sur le forum Maemo.

En quelques commandes, on peut faire la mise à jour d’un tzdata sans compilation/construction de paquetages sur un système Linux/Unix ! (on en apprend tous les jours).

Voici la recette appliquée chez moi :

Pré-requis :

  • le mode développeur activé avec soit un accès en SSH direct sur le N9 (via Wifi pour moi), soit depuis le terminal
  • l’utilitaire wget installé (je ne sais pas si il est natif à Meego/Harmattan)

1/ Passage en root via la commande :

devel-su - (mot de passe « rootme »)
develsh

2/ Récupération de la dernière version de la base tzdata depuis le site de l’IANA

wget http://www.iana.org/time-zones/repository/releases/tzdata2012c.tar.gz

3/ Décompression de l’archive

mkdir tzdata
tar xfz tzdata2012c.tar.gz -C tzdata

4/ Mise à jour de la zone Afrique

cd tzdata/
zic africa

Et voilà, l’heure de mon téléphone a été automatiquement changée (puisque l’on était déjà à l’heure d’été ce dimanche).

 

Faire une évaluation technico-financière de GZip, BZip2 et XZ

Cela fait un petit moment que je vois des fichiers compressés avec XZ, ce dernier est un format de compression basé sur l’algorithme LZMA2.

D’après ce que l’on peut voir sur Internet, il est très efficace pour la compression. Il est d’ailleurs utilisé dans certaines distributions Linux pour réduire la compression d’une archive afin que l’ensemble du live cd tienne dans le cdrom ou tout simplement pour réduire au maximum un paquetage (ici l’annonce du support dans Debian).

La question à 2 centimes qui se pose, c’est : est-ce que je vais remplacer le GZ par le XZ ?

Pour y répondre, je propose d’utiliser la méthode « évaluation technico-financière » que l’on retrouve souvent dans les appels d’offres publiques ici au Maroc.

Cette méthode analyse chaque offre commerciale selon deux axes en attribuant une note technique et une note financière à chaque offre en fonction de l’offre la moins chère, le prix de l’offre courante et sa note technique, puis calcule une note technico-financière selon un rapport 60% technique et 40% financier.

Pour cette évaluation, nous allons considérer les trois « répondants » suivants : GZip, BZip2 et XZ. Ils seront tous couplés avec l’utilitaire tar pour l’empaquetage des fichiers et répertoires.

  • L’axe technique, sera le taux de réduction (de compression), c’est-à-dire de combien, en pourcentage, a été réduit l’orignal.
  • L’axe financier sera mesuré avec le temps de compression mesuré avec l’utilitaire time (valeur real). Ne pas oublier le vieil adage : le temps c’est de l’argent…

Continuer la lecture de Faire une évaluation technico-financière de GZip, BZip2 et XZ

Création d’une mise à jour personnalisée de tzdata sous Debian Squeeze

Voici un mini-tutoriel du type pense-bête concernant la création d’une mise à jour de la base tzdata pour Debian.

Pour rappel, la base de données tzdata est le référentiel ‘mondial’ concernant les décalages horaires (horaires d’été / horaires d’hiver) ainsi que bien entendu des décalages entre fuseaux horaires. Cette base est utilisée pratiquement par tout système d’exploitation (hormis Windows).

Il est important que votre ordinateur (ou serveur) soit à jour concernant cette base. En effet, cela aide par exemple lorsque vous recevez une demande de réunion de quelqu’un qui n’est pas dans le même fuseau horaire que vous (genre Maroc / France), ou bien dans le monde des serveurs pour l’aspect corrélation des journaux.

Toujours est-il, ici au Maroc, les dates de début et fin de l’horaire d’été sont plus ou moins décidées chaque année quelques jours avant. Il est assez difficile d’avoir le paquetage tzdata à jour au moment du passage à l’horaire d’été sur Debian (il y a un délai pour la publication de la mise à jour du tzdata).

Donc, voici ce tutoriel pour faire la petite modification « DST » (Daylight Saving Time ou Horaire d’été) sur le paquetage source tzdata (de Debian) et générer la nouvelle version du .deb. Continuer la lecture de Création d’une mise à jour personnalisée de tzdata sous Debian Squeeze