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).

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…

Le test sera fait sur un dossier « workspace » Eclipse contenant divers projets (répertoires et fichiers). La taille totale d’origine est de 108 Mo.

On exécute donc les trois tests de compression :

Répertoire d'origine
108M    Workspaces-IAM

time tar cfz Workspaces-IAM.tar.gz Workspaces-IAM
real    0m5.585s
user    0m5.472s
sys     0m0.180s

time tar cfj Workspaces-IAM.tar.bz2 Workspaces-IAM
real    0m20.843s
user    0m20.041s
sys     0m0.280s

time tar cfJ Workspaces-IAM.tar.xz Workspaces-IAM
real    1m4.557s
user    1m3.272s
sys     0m0.628s

Résultats de la compression :

• Workspaces-IAM.tar.gz : 71M (réduction de 34,26%)
• Workspaces-IAM.tar.bz2 : 67M (réduction de 37,96%)
• Workspaces-IAM.tar.xz : 64M (réduction de 40,74%)

Passons à la notation.

Note technique, réduction de :

• 1er : XZ avec 40,74%
• 2eme : BZip2 avec 37,96%
• 3eme : GZip avec 34,26%

A ce stade, c’est XZ qui la meilleure note technique.

Au niveau de la partie financière, on va utiliser le temps ‘real’ donné par l’utilitaire time et l’exprimer en millisecondes.

• 1er : GZip avec 5585 ms
• 2eme : BZip2 avec 20843 ms
• 3eme : XZ avec 64557 ms

La note financière sera faite en attribuant une note financière (F) à chaque solution selon la formule : F = (Pmin×Tmax) / P

Où :

• Pmin : le prix de la solution la moins chère
• Tmax : la plus haute note technique
• P : prix de la solution en question

Ce qui donne comme résultat :

Note financière (temps de compression) :

• 1er : GZip avec 40,74 (c’est le moins cher dont il prend directement la note technique du plus fort)
• 2eme : BZip2 avec 10,92
• 3eme : XZ avec 3,52

Ici c’est le GZip qui a la meilleure note financière.

Ensuite pour la note technico-financière, on a : la note finale (N) de chaque solution sera calculée en faisant la somme de 60% de la note technique (T) et 40% de la note financière (F) : N = (0,6 × T ) + (0,4 × F). La solution ayant obtenu la note finale (N) la plus élevée sera déclarée gagnante.

Note technico-financière :

• 1er : GZip avec 36,85
• 2eme : BZip2 avec 27,14
• 3eme : XZ avec 25,85

Le grand gagnant pour la compression est donc GZip.

Conclusion : Je garde le GZip pour tous les jours, et le XZ si j’ai vraiment (vraiment) besoin d’économiser de la place.

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.

Se connecter sur son poste (ou une machine virtuelle de « build ») en tant que root, puis exécuter les commandes suivantes :

mkdir tzdata_build
cd tzdata_build/

La commande suivante va récupérer les sources de tzdata et les fichiers associés Debian

apt-get source tzdata

On récupère maintenant les dépendances pour la génération du .deb. (Ne pas s’étonner de voir des choses liées à Java, car la génération tzdata s’occupe aussi du tzdata-java

apt-get build-dep tzdata

Ensuite on décompresse les sources avec cette commande :

dpkg-source -x tzdata_2011n-0squeeze1.dsc

Puis on se place dans les sources :

cd tzdata-2011n/

Ici commence l’étape « sensible », on va ajouter deux lignes, la première pour le début du DST et la seconde pour la fin. J’ai trouvé ce qu’il fallait ajouter niveau Maroc (pour l’année 2012) en parcourant les archives de la liste tzdata.

Donc on fait un petit « vi » sur le fichier « africa » (pour le Maroc) :

vi africa

Voici le diff par rapport à la version actuelle du tzdata de Debian Squeeze :

diff africa.orig africa

2c2
< # @(#)africa 8.33
---
> # @(#)africa 8.34
795a796,797
> Rule Morocco 2012 max - Apr lastSun 2:00 1:00 S
> Rule Morocco 2012 max - Sep lastSun 3:00 0 -

On note que les lignes ajoutées sont sans limite dans le temps (chaque année au dernier dimanche d’avril on ajoute 60 minutes à 02h00 du matin – donc il sera 03h00 – et on retire 60 minutes le dernier dimanche de septembre à 03h00 du matin – donc il sera 02h00 – ).

Par ailleurs, on note aussi que pendant le mois lunaire du Ramadan, le décalage de +1h sera retiré. Malheureusement, la date de début (et de fin) du Ramadan dépendant des observations de la Lune quelques jours (voir la veille) avant pour déclarer son début (idem pour la fin), il faudra donc prévoir 2 mises à jour (une avant le ramadan autour du 20 juillet 2012 et une juste avant la fin du ramadan autour du 18 août 2012)

Il faut également modifier le fichier changelog pour incrémenter le numéro de « sous-version » Debian. Pour cela, éditer le fichier suivant :

vi debian/changelog

Sur la première ligne changer (par exemple) le « squeeze1″ par « squeeze2″, ce qui donne la ligne suivante :

tzdata (2011n-0squeeze2) stable; urgency=low

Bon revenons à la re-génération du tzdata, exécuter la commande suivante pour la lancer :

dpkg-buildpackage -rfakeroot -b

Ensuite, pour installer les mises à jour, exécuter la commande suivante :

dpkg -i ../tzdata_2011d-0squeeze2_all.deb ../tzdata-java_2011d-0squeeze2_all.deb

NB. Le paquetage tzdata-java n’est utile que si vous avez Java sur votre poste de travail ou serveur.

Les nouveaux paquetages sont générés dans le répertoire parent (cd ..), la nomenclature du paquetage tzdata « 2011d-0squeeze2_all » représente une « micro-sous-version » du paquetage. Ainsi lorsque la vrai mise à jour Debian va sortir, celle-ci aura un numéro de version plus important (ex. tzdata_2012b-3squeeze1), et donc votre poste se mettra à jour normalement et remplacera votre version personnalisée.

Voilà.

./

Par contre, j’avais un problème par rapport à mon ancien téléphone, le Nokia N8 : la durée de vie de la batterie, elle était trop courte. (J’ose à peine le dire, que j’avais un problème de batterie… car déjà que c’est difficile de dire au gens que l’on a un Nokia… par rapport aux « iphone lovers » et « android men », et encore plus que c’est pas un Symbian mais un Meego (Linux), et de justifier son choix…)

Enfin, toujours est-il que : A quoi sert un téléphone portable à ce prix (650 euros la version 64Go), si il ne tient pas une journée de 16h (du matin au soir) ?

J’étais très frustré en effet, par exemple lorsque je partais en déplacement sans réelle possibilité de recharger le téléphone durant la journée, d’avoir mon téléphone avec la batterie vide à partir de 18h !

Bon et bien, finalement, je me suis décidé à faire une recherche sur Google : « Nokia N9 battery life », puis de faire plein d’expériences durant une semaine pour trouver ce qui n’allait pas.

Au final, la batterie du Nokia N9 est largement autonome pour 1 jour (et visiblement plus) si 1/ on fait attention à 1 bug déclaré de fuite de batterie, et 2/ aux applications qui utilisent un peu trop souvent la connexion Wifi/3G.

Voici mon retour d’expérience sur mes découvertes sur la vie de la batterie d’un Nokia N9.

Je commence par la fin. Ce matin à 7h, j’avais 93% de batterie (recharge lancée avant de coucher vers 23h hier soir), aujourd’hui j’ai passé environ 1h de communication aujourd’hui (dont 55 min à suivre), plus environ 20min d’activité sur le téléphone (principalement le jeu gratuit Stack The Stuff (excellent) et divers bricoles avec la connexion Wifi), 11h14 d’inactivité (économiseur d’écran), soit 12h25 depuis la dernière recharge d’après le logiciel Battery Usage. Il est 19:41, il reste 40% de batterie. La moyenne de consommation en idle est 10mA, 223 mA pour l’active. C’est tout simplement très bien de mon point de vue (surtout avec 1h de communication). J’ai largement le temps de finir la soirée, et de mettre mon téléphone à recharger avant d’aller dormir.

On entre maintenant dans le vif du sujet : les deux points importants :

1/ Tout d’abord, il y a le bug 486 sur le programme meegotouchhome. Ce bug se produit à chaque reboot du téléphone, le programme meegotouchhome utilise environ 3-5% de CPU en permanence (alors qu’il doit être à 0% en veille) et ‘mange’ littéralement la batterie. C’est visible depuis le mode développeur avec le terminal (faire la commande ‘top’) ou bien avec l’application Battery Usage.

En attendant que Nokia corrige ce bug et qu’il soit déployé (peut-être en PR1.3?), le contournement consiste à maintenir son doigt enfoncé sur l’écran des icônes applicatifs (pour passer en mode déplacement des icônes/suppression des applications), puis bouger une icône (n’importe laquelle), puis cliquer sur le bouton Terminer. Ceci à chaque nouveau reboot du téléphone.

2/ Pour éviter d’avoir sa connexion wifi ou 3G active en permanence, si vous avez Nokia Pulse d’installé, désactiver son système de notifications en mode push. Pour cela : Paramètres > Notifications > Notifications (2ème fois) > Notifications push > Nokia Pulse à désactiver. Il est également possible de désactiver globalement les notifications push via l’interrupteur situé juste au-dessus sur ce même écran.

De plus…

Il est intéressant de désactiver la possibilité de faire des connexions data en arrière-plan si vous n’êtes pas en mode « économie d’énergie » et si vous voulez désactiver les connexions data, c’est cela qui m’a permis de voir que dès que j’allais sur le téléphone, un message m’indiquais que « la connexion Internet est désactivée, voulez-vous l’activer : Oui|Non », et de me dire qu’il y avait une application qui me mangeais la batterie (Nokia Pulse).

Ensuite, dans les petites choses en plus…

D’un autre coté, j’ai décidé d’activer le mode d’économie d’énergie en permanence. Via le menu Paramètres > Appareil > Batterie > Mode économiseur de batterie à Activer

Un des avantages de ce mode (d’après ce que je vois sur mon téléphone), c’est que le téléphone va rester en mode GSM avec l’opérateur, et activer la 3G seulement en cas de besoin de connexion data (que je le veux donc). Le mode GSM consomme bien entendu moins que le mode 3G.

Un inconvénient du mode d’économie d’énergie, c’est que la planification des mises à jour de comptes émail, de synchronisation de calendrier, ou bien des fils twitter ne va plus se faire automatiquement (même si c’est configuré). Il faudra les lancer manuellement ou bien repartir sans le mode d’économie d’énergie. Ce qui n’est pas spécialement grave pour moi, car étant informaticien, je suis quasiment en permanence sur mon ordinateur avec la connexion Internet et mes emails consultablent tout de suite (et puis c’est bien mieux de consulter ses mails quand on le décide, plutôt que d’être dérangé par eux).

Aussi, réduire au maximum le délai d’affichage actif, c’est-à-dire le délai après lequel l’écran s’assombrit et passe en veille. Pour ma part pour l’instant il est à 15 secondes.

L’application Track & Prot. qui semble-t-il permet d’avoir une traçabilité à distance de votre téléphone (et sans doute pour le verrouiller aussi) est aussi une consommatrice de batterie via l’activation du GPS. Je n’ai pas testé cette application, j’ai juste vu dans les forums que c’était aussi une application consommatrice de batterie, alors je l’indique ici.

Voilà, voilou.

La version 2.6 est une version qui apporte de jolies améliorations tout en amenant son lot de corrections d’anomalies.

Voici quelques captures de quelques nouveautés importantes :

La plus ‘remarquable’ c’est l’ajout d’une barre d’outils sur la fenêtre principale de JMeter, qui permet d’avoir à portée de clic les principales actions de JMeter (dont le lancement d’un tir).

Ensuite, une amélioration qui me semble importante pour ceux qui utilisent JMeter pour tester des applications de type GWT RPC, SOAP/XML, etc. C’est l’ajout d’un onglet Données POST dans l’échantillon Requête HTTP. Celui-ci permet de visualiser et éditer bien plus facilement les données envoyées lors de l’exécution de la requête.

Dans le genre ‘quick and dirty’, c’est-à-dire lorsque vous devez faire un test de charge rapide pour un client (ou chef) qui vous le demande à la dernière minute genre à 17h30 un vendredi soir (si vous ce que je veux dire…;-)), voici le récepteur Graphique agrégé amélioré :

De nombreuses options de personnalisation du graphique généré ont été ajoutées, par exemple la possibilité de filtrer par le nom via une regexp les résultats à grapher, ou bien la possibilité de fixer l’échelle des ordonnées à une valeur permettant la comparaison aisée avec un graphique d’un premier tir.

Une petite boîte de dialogue qui peut sauver des heures de travail : la confirmation de la suppression. Si vous avez déjà utiliser JMeter, vous avez peut-être comme moi déjà eu « l’accident de suppression », sans le faire exprès vous avez supprimé un noeud de l’arbre important, genre un Groupe d’unités ou un Contrôleur Transaction avec plein de fils. Et là c’est la catastrophe ! vous n’avez pas sauvegarder votre script depuis un bon moment, et toutes votre variabilisation est perdue… En effet, JMeter n’a pas (encore) de fonctionnalité de retour en arrière (le fameux Ctrl-Z). Tout cela pour dire que cette petite boîte de dialogue va certainement être utile. NB. La fonctionnalité de retour arrière va peut-être être intégrée dans une future version de JMeter, un patch ayant été proposé et est en cours d’évaluation.

Une autre amélioration sympathique pour (par exemple) ceux qui utilisent beaucoup des scripts BeanShell (ou autres langages), c’est la console de visualisation du fichier journal de JMeter (le jmeter.log).

Cette console permettant donc de voir les messages informatifs et d’erreurs lors de l’exécution de JMeter. Utile donc pour la mise au point de script BeanShell ou pour surveiller le bon fonctionnement de JMeter.

La version 2.6 de JMeter a plein d’autres nouveautés, étant donné que la présentation de ces nouveautés a été aussi améliorée, je vous invite à suivre ce lien pour avoir encore plus de capture d’écran des nouveautés et aussi consulter la liste exhaustive des anomalies corrigées.

Dans tous les cas, la montée en version est recommandée.

Bon courage dans vos aventures JMeter !

Néanmoins, je me suis dit qu’il serait bien de récupérer le Windows (et sa licence associée) en tant que machine virtuelle sur mon portable de travail, le tout avant de le ré-installer en Debian. Cela sera ainsi une machine Windows 7 que je pourrai utiliser pour faire des tests de fonctionnement (genre JMeter sur Windows 7 ou l’affichage d’un site avec IE 9/Win7, etc).

Le travail à faire consiste donc à « virtualiser » le nouveau portable. Cela s’appelle le « physique vers virtuel » ou « physical-to-virtual », P2V de son petit nom. Voici ma recette :

Ingrédients :

• Un nouveau portable tout neuf avec son Windows 7
• Un portable existant en Debian 6 avec Virtual Box 4.1
• Un CDROM (ou une clé USB) Gparted Live
• Le programme (gratuit) Disk2vhd de Microsoft / Sysinternals
• Un disque dur externe (optionnel) pour le transfert entre les deux portables

Préparation :

Le nouveau portable a un disque dur de 500 Go, répartie en 3 partitions :

1. SYSTEM_DRV (taille 1,5 Go)
2. Lenovo_Recovery (taille 9,8 Go)
3. Windows7_OS (taille 455 Go)

Les 455 Go pour le Windows sont trop importants, il faut réduire cela.

Ceci peut être fait après la virtualisation, mais comme je ne savais pas trop au début quelle serait la taille du fichier image final : 500 Go ou juste la taille des données utilisées ? j’ai préféré le faire avant.

Pour réduire la taille de la partition Windows, il est possible de le faire avec l’utilitaire de gestion des disques livré avec Windows. Cependant il n’est pas assez efficace, car il ne peut pas réduire au-delà du dernier secteur rempli, donc si vous avez des données à la fin de la partition, vous n’allez par pouvoir réduire de beaucoup (même avec une défragmentation avant).

J’ai préféré utiliser une clé usb Gparted Live. Ce dernier sait réduire une partition NTFS (windows) à la taille voulue, même si il doit pour cela faire le déplacement de données situées dans la partie à réduire.

J’ai donc réduit la partition Windows à 60 Go avec le programme Gparted.

Après la réduction, au démarrage de Windows (toujours sur le portable physique), il y a l’exécution d’une vérification du disque dur (un chkdsk). Et voilà pour la préparation.

Virtualisation du disque dur :

Bon, maintenant l’étape de virtualisation. Ici, l’utilitaire de Microsoft, Disk2Vhd va entrer en action.

L’idée de la virtualisation du disque dur est de transformer le disque dur entier (toutes les partitions) en un seul fichier. Ce dernier va être gros en taille (avec Disk2Vhd, c’est environ un peu plus que la taille des données utilisées), il faut donc prévoir un disque de destination cible ayant la taille ciblée. On peut utiliser un disque dur externe ou bien utiliser l’espace libéré dans l’étape de préparation ci-dessus. J’ai fait le deuxième choix, et donc j’ai créée une nouvelle partition « temporaire » sur le Windows.

Ensuite, j’ai lancé le petit utilitaire Disk2Vhd, et j’ai sélectionné les trois partitions (je ne crois pas que le trois soient vraiment nécessaires) sans prendre la partition temporaire qui va recevoir le fichier image VHD.

Bien entendu le dossier cible a été configuré vers le lecteur de la partition temporaire.

On démarre la virtualisation, Disk2Vhd travaille assez vite (environ 1 min par Go pour moi).

Voilà, on a donc un beau fichier VHD d’environ 33 Go ensuite.

Il suffit de le transférer sur le portable qui contient VirtualBox.

On créé une machine virtuelle Windows 7 64 bits (1 CPU, 1,5 Go de RAM), et on pointe directement sur le fichier VHD (VirtualBox reconnait directement ce format).

On démarre la machine virtuelle.

Le Windows 7 n’est plus activé, il faut le refaire, en utilisant le code de licence sur l’étiquette Microsoft collée sur le portable (cachée derrière la batterie pour moi). Et hop.

Il ne reste plus qu’à installer les pilotes « virtual box » pour une meilleure intégration de la VM sur le portable Debian, et faire un partage de fichiers entre la VM Windows et le système hôte pour faciliter les échanges de fichiers entre eux.

Maintenant je peux ré-installer le nouveau portable en Debian et en formatant tout son disque dur.

Ce tutoriel est de Philippe Mouawad, membre PMC de JMeter et développeur actif de JMeter. Son tutoriel « JMeter Switch Controller ou comment contrôler les pourcentages d’échantillons » permet de répondre à une problématique assez récurrente lorsque l’on a un plan de test de charge avec une répartition des actions utilisateurs en pourcentages (50% font de la consultation, 25% des commandes, 25% des recherches par exemple).

Merci pour ce tutoriel.

Pour commencer cette nouvelle année, et à la vue des quelques articles et tutoriels francophones sur JMeter qui pointent de temps en temps sur le web, j’ouvre une page « Liens JMeter » sur ce blog afin de lister ces articles et tutoriels.

Sur cette page, donc, j’ai placé les liens que j’ai pu recenser depuis quelques années sur ce blog. J’espère que cette page aura une liste qui s’allongera de plus en plus !

Tout d’abord, un article de Thibault Duchateau pour savoir comment générer au lancement de JMeter un fichier qui servira de source de données CSV dans un test. La recette est à base de Groupes d’unités de début et de BeanShell.

L’autre article est d’Antonio Gomes-Rodrigues, auteur de plusieurs tutoriels JMeter / Performances sur Developpez.com, qui présente l’utilisation de JMeter pour réaliser un test d’une application JSF, avec la particularité du suivi utilisant le fameux VIEWSTATE.

Merci à leur auteur respectif pour ces articles qui viennent enrichir l’écosystème documentaire de JMeter.

J’ai eu (donc) pas mal de travail dernièrement, mais peu sur JMeter, ce qui m’a un peu éloigné du travail et des articles que je fais sur JMeter. Je vais essayer de changer cela pour l’année 2012, c’est-à-dire avoir plus de régularité dans des missions JMeter (tests de charges et formations).

Sinon, je viens d’avoir un ordinateur portable Lenovo Edge avec 8 Go de RAM, 500 Go de disque et un iCore 3 2,4Hz (2 coeurs avec chacun 2 hyper threading, donc 4 ‘cpu’ visibles). Il n’est pas là pour remplacer mon portable actuel (qui est super), mais il va me servir comme plate-forme d’hébergement de machines virtuelles pour mes tests et autres prototypages de solutions techniques. En effet, je ne fais pas que de la performance avec JMeter, je fais aussi de l’architecture technique web. Pourquoi le choix d’un portable ? C’est que d’une part, ce n’est pas cher aujourd’hui un portable (414 euros ttc avec les 8 Go), et d’autre part, c’est pour l’avoir à la maison, et un portable c’est plus silencieux qu’un poste de travail (ou serveur:-)), cela dispose d’une batterie jouant le rôle d’un onduleur, et cela prend peu de place.

Dans ce portable, je mettrais une Debian avec KVM comme solution de virtualisation. Ce choix, car je suis justement entrain de mettre en place KVM dans une mission, et je me rends compte seulement maintenant de ses nombreuses fonctionnalités, par rapport à Vmware et dans une moindre mesure à VirtualBox. J’ai mis en place la migration à chaud via une baie SAN sans effort par exemple.

./