Catégories
Blog

Glances 2.2 a besoin de vous

L’activité sur ce blog étant inversement proportionnelle à mon activité sur le logiciel Glances, vous pouvez, je l’espère, comprendre le peux d’activité sur ce site. Le développement de la future version 2.2 de Glances me prends les quelques temps libres qui me reste. Je fais donc appel à vous, chers lecteurs, pour m’aider à valider et trouver les derniers bugs dans cette version en cours de développement.

Quoi de neuf ?

La version 2.2 apportera, en plus de son lots de corrections de bugs les fonctionnalités suivantes:

  • un nouveau mode nommé « browser » (option –browser) permettant de superviser un ensemble de serveurs Glances ou SNMP à partir d’un point central
  • une vu en arbre pour les processus avec l’option –tree
  • amélioration de la fonction de tracé de graphique initialisé dans la version 2.1 de Glances
  • ajout du raccourci ‘F’ et de son option –fs-free-space pour afficher l’espace libre en lieu et place de l’espace utilisé
  • ajout du raccourci ‘2’ et de son option (–disable-left-sidebar) pour cacher la sidebar gauche et donc afficher tout l’espace du bas de l’écran avec les processus
  • ajout du raccourci ‘t’ pour trier les processus en fonction du temps CPU (« CPU times »)

C’est surtout sur la fonction « browser » que j’ai besoin de vous. En effet, je l’ai testé dans un environnement limité et je suis à la recherche d’administrateur système avec un bon petit parc de machines pour effectuer une validation plus complète.

Focus sur le mode browser

Ce nouveau mode permet donc de lancer Glances en tant que « super » client qui va afficher dans une première fenêtre la liste des serveurs Glances détectés sur son réseau ou configuré dans le fichier de configuration.

Sélection_251

Le mode de détection automatique repose sur le protocole Zeroconf qui fonctionne en client/serveur multicast. Il est nécessaire que les clients et les serveurs soit dans la version 2.2 de Glances (voir la procédure d’installation dans le chapitre suivant).

Remarque sur le protocole Zeroconf: Qui dit multicast, dit une détection uniquement sur le réseau local. En clair, votre « super » client Glances ne verra que les serveurs sur le même réseau Ethernet (à moins que vos routeurs ne soient compatibles avec le routage multicast).

En plus de ce mode dynamique (qui est bien sur désactivable à la fois coté client mais aussi coté serveur), il est possible de configurer une liste de serveurs dans le fichier de configuration de Glances (voir exemple ici).

Une fois la liste des serveurs affiché, il suffit de cliquer sur la touche ‘ENTER’ pour visualiser les statistiques de la machine (en clair, lancer le client Glances classique sur le serveur sélectionné).

Ce nouveau mode, très demandé par les utilisateur est en phase de développement et est susceptible d’évoluer dans les prochaines versions. Je suis d’ailleurs à l’écoute de vos remarques sur cette fonction.

Comment tester la version 2.2 de Glances ?

Je vous propose de simplement lire le Wiki officiel (en cliquant ici) qui va vous guider pour installer cette version de développement (bêta) sur vos machines sans « casser » le Glances existant.

D’avance merci !

PS: faite tourner le billet 🙂

Catégories
Developpement Open-source Reseau Systeme

Glances v2.0 RC – J’ai besoin de vous !

Cela fait maintenant plusieurs mois que je délaisse mon bébé blog pour me consacrer au développement de la version 2.0 de Glances. Avec l’aide d’Alessio Sergi, nous avons effectué un refactoring complet du code et apporté de nouvelles fonctions qui, je l’espère, vous serons utiles.

Sélection_175

Cependant, avant la mise à disposition officielle, j’ai besoin de vous pour tester la première Release Candidate (RC1). Le développement ayant été fait sous Ubuntu 14.04, je recherche donc des personnes de bonne volonté pour valider cette RC1 sur d’autres système d’exploitation: autres distributions GNU/Linux, BSD, Mac OS, Windows.

Comment tester Glances v2.0 RC1 ?

Le plus simple est de suivre les instructions de la page Wiki qui va vous permettre de tester cette nouvelle version sans impacter votre système existant (utilisation d’un environnement virtuel avec virtualenv).

Il est important de bien vérifier que l’on est sur la branche DEVELOP avant de lancer les tests suivants. Pour vérifier cela:

cd ~/tmp/glances
LANGUAGE=en_US.utf8  ~/glances-venv/bin/python -m glances -V

devrait afficher comme résultat:

Glances v2.0_RC1 with psutil v2.1.0

Quoi tester?

A vrai dire un peut tout…

Le mode standalone

Le plus simple est de commencer par lancer Glances en mode standalone (supervision de son propre système):

cd ~/tmp/glances
LANGUAGE=en_US.utf8  ~/glances-venv/bin/python -m glances -C ~/tmp/glances/conf/glances-monitor.conf

Votre terminal devrait afficher les statistiques (rafraîchissement par défaut de 3 secondes). En appuyant sur la touche ‘h’, vous obtiendrez une liste des différentes fonctions.

Mode client/serveur classique

Je vous propose ensuite de passer au mode client/serveur qui peut être testé sur une unique machine (le client et le serveur étant lancé sur la même machine) ou bien sur deux machines différentes.

On commence par lancer le serveur:

cd ~/tmp/glances
LANGUAGE=en_US.utf8  ~/glances-venv/bin/python -m glances -C ~/tmp/glances/conf/glances-monitor.conf -s

Puis le client:

cd ~/tmp/glances
LANGUAGE=en_US.utf8  ~/glances-venv/bin/python -m glances -C ~/tmp/glances/conf/glances-monitor.conf -c @IPSERVER

Votre terminal va alors afficher les statistiques du serveur.

Mode client/serveur SNMP

C’est une nouveauté de la version 2.0. Ce mode permet de lancer un client vers une machine ou le serveur Glances n’est pas lancé. Il va ainsi essayé de se connecter a un serveur SNMP (si celui-ci est installé sur votre serveur). Cette fonction est encore expérimentale et ne fonctionne correctement qu’avec des agents SNMP GNU/Linux.

Pour tester, il suffit de lancer le client:

cd ~/tmp/glances
LANGUAGE=en_US.utf8  ~/glances-venv/bin/python -m glances -C ~/tmp/glances/conf/glances-monitor.conf -c @IPSERVER

Votre terminal va alors afficher les statistiques minimale du serveur (par exemple, on a pas la liste des processus).

Sélection_176

Mode Web serveur

Egalement une nouveauté de la version 2.0, ce mode permet de lancer un serveur Glances qui va proposer une interface Web. Glances utilise pour cela le framework Bootle qui a déjà fait ses preuves dans de nombreux autres projets libres.

Pour lancer le serveur en mode Web, il faut saisir la ligne de commande suivante:

cd ~/tmp/glances
LANGUAGE=en_US.utf8  ~/glances-venv/bin/python -m glances -C ~/tmp/glances/conf/glances-monitor.conf -w

Puis pointer son navigateur Web préféré sur l’adresse suivante: http://<ip serveur>:61208/

Glances - Mozilla Firefox_177

Comment remonter un bug ou une demande d’amélioration ?

Il faut disposer d’un compte Github et de cliquer sur le lien suivant: Remonter un bug dans Glances.

Dans la description, faire systématiquement apparaître:

  • la version de Glances testée ( ~/glances-venv/bin/python -m glances -V)
  • votre environnement de test (système d’exploitation, hardware, version de Python…)
  • un descriptif le plus précis du problème et de la manière de le reproduire (en Anglais de préférence)

Je compte sur vous 🙂

Catégories
Open-source Planet-libre raspberry Video

Test d’OpenElec sur Raspberry Pi

Billet mis à jour le 1 mai 2015 avec OpenELEC 5.0.8.

Avec l’apparition du Raspberry Pi et de son GPU Broadcom VideoCore IV intégré, les logiciels de « media center », c’est à dire les systèmes permettant de connecter directement un PC à une télévision pour exploiter sa bibliothèque vidéo, se sont rapidement intéressés à ce nouvel OVNI technologique. Ainsi plusieurs distributions Linux orientés « media center » ont vus le jour pour nous permettre et permettent, pour moins de 30€, de disposer d’un système intégré pour lire des vidéos HD téléchargés plus ou moins légalement sur le Internet.

Nous allons dans ce billet nous intéresser à l’une d’entre elle: OpenElec (Open Embedded Linux Entertainment Center) qui dispose d’un bonne notoriété sur les réseaux sociaux, notamment grâce à une interface de navigation fluide et à une documentation bien fournie (notamment leur Wiki). Il faut juste garder en tête que toutes ces distributions « media center » se base sur le même noyau composé de Raspbian (le système d’exploitation Debian adapté au Raspberry Pi) et XBMC pour le logiciel.

OpenElec screenshot

Installation d’OpenElec

Pour installer OpenElec, les auteurs du projet ont eu la bonne idée de créer un script qui va partitionner et graver la dernière version du système (3.0.1 au moment de l’écriture de cet article) sur une carte SD que vous n’aurez plus qu’à insérer dans votre Raspberry Pi.

Voici les lignes de commandes à saisir sur votre machine GNU/Linux pour installer la version 5.0.8 d’OpenElec sur une carte SD disponible via l’identifiant système /dev/sdb (c’est bien sûr à contrôler avec la commande « fdisk -l » pour être sûr que /dev/sdb correspond bien à votre carte SD histoire de ne pas effacer un autre disque dur):

wget http://releases.openelec.tv/OpenELEC-RPi.arm-5.0.8.tar 
tar xvf OpenELEC-RPi.arm-5.0.8.tar 
cd OpenELEC-RPi.arm-5.0.8/
sudo ./create_sdcard /dev/sdb

Installation de votre Raspberry Pi

Voici la configuration que j’ai utilisé pour le test:

  • Un téléviseur Samsung UE46B6000 (pour une description de mon système home cinéma avant l’arrivée de mon Raspberry, cliquez ici !)
  • Un Raspberry Pi model B (j’ai ensuite utilisé un model A)
  • Une carte SD 4 Go (mais une de 2 Go suffit) avec OpenELec 3.0.1 (voir le premier paragraphe pour l’installation)
  • Un disque dur USB contenant mes vidéos (attention de bien alimenter le disque par une source externe car le Raspberry Pi n’y arrive pas).
  • Un câble HDMI pour la liaison numérique avec le téléviseur (vidéo, son et télécommande avec la norme HDMI CEC).
  • Une souris pour manipuler l’interface d’OpenElec ou mieux encore votre télécommande si votre téléviseur est compatible avec la norme HDMI CEC (comme c’est le cas pour mon téléviseur Samsung via l’implémentation de la fonction Anynet+)
  • Un câble réseau (pour l’accès distant et l’accès au NAS) (optionnel et seulement pour le model B)

Après branchement, le système devrait démarrer automatiquement et l’interface va apparaître sur votre téléviseur. Si vous avez un modèle B, l’accés en SSH (l’adresse IP de votre Raspberry Pi est donnée dans le menu configuration) se fait à l’aide de l’utilisateur root et du mot de passe openelec.

Test de la bête

J’ai d’abord testé OpenElec avec un Raspberry Pi model B puis quand j’ai reçu mon model A j’ai basculé vers ce boîtier car je n’utilise pas mon NAS pour stocker mes films mais un simple disque dur portable connecté directement au Raspberry Pi.

Le démarrage du système est assez rapide (entre 1 minute et 1 minute 30), on arrive directement sur l’interface XMBC customisée à la sauce OpenElec. La navigation dans les différents menus se fait de manière relativement fluide. Le « relativement » n’est pas vraiment un problème quand comme moi vous utilisez une télécommande. Par contre on ressent une certaine difficulté du Raspberry Pi à suivre le rythme quand on utilise une souris. A noter que l’utilisation direct de la télécommande est assez blufante, une vraie bonne idée cette norme HDMI CEC.

Sur ma configuration, je n’ai presque pas eu de configuration à faire mis à part un calibrage de l’écran. En effet, je perdais des petites bandes d’image sur les cotés. Le plus simple pour faire cela est de lire un film et de cliquer sur le bouton « Vidéos – Paramétrage » puis « Étalonnage de l’écran ». Vous aurez alors droit à un wizard qui va vous permettre de bien redimensionner la vidéo par rapport à votre télévision.

On peut ensuite passer au test de lecture vidéo qui est l’objectif principal de notre boîtier.  Pour cela j’ai fait tourner pendant une journée entière OpenElec en lecture d’un rip HD Xvid 720p de « The art of flying » qui avec ses traveling n’est pas une vidéo facile à décoder.

The art of flying

Le résultat est très concluant, aucune saccade constatée de la vidéo lors de la lecture (mais bon je suis pas non plus resté toutes la journée devant l’écran :)). Le son 5.1, récupéré directement via la liaison HDMI, est bon. J’ai également fait des tests avec des trailers en HD 1080p et il n’y a également aucun problème de lecture. Le GPU fait vraiment bien son boulot.

Le Raspberry Pi ne chauffe presque pas (j’ai mis la carte dans un boîtier transparent que l’on peut trouver pour quelques € pour que la carte ne prenne pas la poussière et pour éviter que mes enfants mettent les doigts dessus, c’est curieux ces bêtes là…).

A noter qu’avant la rédaction de ce billet, j’avais demandé à mon copain Twitter des retours d’expériences sur les « media center » du Raspberry PI. De nombreux followers m’avaient signalés qu’il avait des problèmes de lags lors de la lecture de vidéo HD 1080p sur OpenElec. Je n’ai pas constaté de problème sur ma configuration et je pense que leurs problèmes viennent du fait qu’il utilise des vidéos stockées sur un NAS. Il faut donc regarder du coté du réseau et notamment si vous utilisez un dongle Wifi sur votre Raspberry Pi.

Problème d’avance et de retour rapide

Note: ce problème n’est plus présent dans la version 5.0.8 d’OpenElec.

Lors des tests, j’ai constaté un problème au niveau de l’avance et du retour rapide lors de la lecture des vidéos. C’est un problème connu au niveau de XBMC.

Il existe heureusement une solution de contournement qui consiste à remplacer le « fast forward » (& rewind) par le « step forward » (& rewind). Pour cela, il faut éditer le fichier remote.xml (à chercher sur votre configuration via la commande « find / -name remote.xml »), puis à éditer la section FullscreenVideo:

  <FullscreenVideo>
    <remote>
      <title>Stop</title>
      <back>Stop</back>	
      <reverse>StepBack</reverse>
      <forward>StepForward</forward>
    </remote>
  </FullscreenVideo>

Le pas par défaut est de 30 secondes, pour le changer il faut éditer un autre fichier nommé advancedsettings.xml qui est à créer pour l’occasion (cliquer ici pour voir comment créer ce fichier selon la documentation de XBMC) puis à l’éditer avec le contenu suivant:

<advancedsettings>
<video> <!-- "VideoSettings" instead of "video" for builds prior to May 22, 2006 -->
  <usetimeseeking>true</usetimeseeking>  <!-- Whether to use time based or percentage based seeking. -->
  <timeseekforward>15</timeseekforward>  <!-- Time to seek forward in seconds when doing a short seek.  Defaults to 30. -->
  <timeseekbackward>-15</timeseekbackward>  <!-- Time to seek backward in seconds when doing a short seek.  Defaults to -30. -->
  <timeseekforwardbig>600</timeseekforwardbig>  <!-- Time to seek forward in seconds when doing a long seek.  Defaults to 600 (10 minutes). -->
  <timeseekbackwardbig>-600</timeseekbackwardbig>
</video>
</advancedsettings>

Conclusion

Le Raspberry Pi est vraiment un joujou surprenant par ses capacités à faire des choses habituellement réservées à du matériel beaucoup plus cher. Avec les solutions intégrées comme OpenElec, on n’a même plus la complexité de configuration et ces solutions de « media center » deviennent à la porté de n’importe quel bidouilleur.

… pour faire la fine bouche

Il manque encore le support du HDMI Ethernet Channel qui permettrait au Raspberry d’utiliser via le câble HDMI la liaison Internet de la télé. C’est prévue dans la norme HDMI 1.4 mais pas implémenté dans les modèles actuels du Raspberry Pi (voir la page suivante pour les explications).

Allez, à vos claviers, parlez moi de votre configuration « media center ». Utilisez-vous OpenElec ou bien une autre distribution ? Si oui pourquoi ?

Catégories
Hardware Open-source Planet-libre Systeme

Test d’un Linutop 4 avec Linutop OS 5

J’écris cet article depuis le Linutop 4 que j’ai eu gracieusement en test pendant quelques semaines (au passage merci à l’équipe Linutop). Pour rappel, le Linutop 4 est un mini PC Fanless et totalement silencieux (pas de disque dur mais une mémoire Flash) utilisant un OS maison nommé Linutop OS 5. Il a comme cible les entreprises souhaitant disposer d’un client bureautique léger et les utilisations de type bornes Internet ou affichages dynamique d’informations.

Les caractéristiques

On commence par un bref aperçu des caractéristiques du boîtier:

Note: le système Linutop OS 5, pré-installé par défaut, occupe environ 450 Mo des 2 Go de la mémoire flash interne.

Premier contact

C’est la première fois que j’utilise une machine totalement silencieuse et je dois avouer que lors du premier démarrage, j’ai vérifié que je n’avais pas oublié de brancher l’alimentation avant de voir apparaître la bannière de configuration sur mon écran. Même par rapport à l’utilisation d’un PC portable, le silence est vraiment total.

L’avantage d’utiliser l’OS maison (Linutop OS 5) est qu’il n’y a aucune configuration à faire sur la machine. Une simple fenêtre de configuration est affichée au première démarrage de la machine et permet de fixer les paramètres comme le langage, le clavier… Pour la majorité des utilisations, il n’y a rien à faire mis à part cliquer sur le bouton OK.

Une fois cette étape passée, on se retrouve sur une distribution GNU/Linux basée sur Ubuntu (et donc bénéficiant des paquets de cette distribution) avec XFCE comme gestionnaire graphique.

Les premières minutes d’utilisation ont été un peu difficile pour moi. En effet, étant habitué à travailler sur des machines puissantes (voir sur-dimensionnées), la relative lenteur du temps de réaction pour les opérations de bases (ouvrir et déplacer des fenêtres, charger des pages Web légères…) m’a sauté au yeux. Après quelques heures d’utilisation, je m’y suis habitué et si on ne demande pas des choses trop lourdes à ce boitier il s’acquitte parfaitement de ses tâches.

Une machine pour quoi faire ?

Les caractéristiques hardware de la machine limite l’utilisation à certain domaine. J’ai essayé, dans ce chapitre de résumer les choses que j’ai pu tester.

Machine parfaitement adapté pour:

  • naviguer sur Internet (sauf si vous essayez de lire des vidéos en 720p sur YouTube)
  • de la bureautique classique (document, tableur, présentation)
  • écouter de la musique (bien qu’il manque à mon goût une sortie numérique)
  • faire du déport d’affichage (VNC, RDP/TSE) ou de l’administration via SSH

Machine utilisable pour:

  • regarder des vidéos DivX, MP4, OGG au format SD 480p (le format HD Ready 720p peut passer mais risque de faire chauffer votre machine tandis qu’il faut oublier la lecture de fichier en Full HD 1080p)
  • développer (si vous utilisez des IDE légères Troll> et pas des usines à gaz comme Eclipse <Troll)

Machine inutilisable pour:

  • gérer votre bibliothèque de photos / retouche (j’ai essayé et cela n’est pas exploitable)
  • faire du post traitement vidéo
  • faire plusieurs choses en même temps… (la RAM du boitier que j’avais en test était de 1 Go mais il est possible en option de passer à 2 Go)

Résumé des + et des –

Le hardware: Linutop 4

Les +

  • Le silence total !
  • Qualité de fabrication du boitier. Cela paraît solide
  • Le boîtier chauffe mais pas de manière excessive

Les –

  • 1 Go de RAM en standard c’est vraiment trop peu
  • Impossible d’acheter un boîtier « vierge » sans l’OS Linutop (qui est vendu 79€ séparément). J’aurai donc aimé pouvoir acheter le Linutop OS 4 à 400-79 = 321 €…
  • Pas de port USB en version 3
  • Le prix (environ 400€), ce qui est cher pour la configuration hardware proposée

Le systéme: Linutop OS 5

Les +

  • Pack bureautique complet
  • VLC de base et qui fonctionne très bien sur les fichiers SD

Les + et –

  • Le choix de XFCE s’explique bien évidemment par la relativement faible consommation de ressource de ce gestionnaire. De mon point de vu, quitte à avoir un gestionnaire épuré et faiblement consommateur de CPU et de mémoire, autant partir sur une solution de type Openbox ou Fluxbox. J’ai donc essayé la distribution CrunchBang Linux (32 bits BTO) qui fonctionne parfaitement en version « live USBkey ». Et l’impression de lenteur est beaucoup moins importante qu’avec Linutop OS 5 pour une utilisation classique de surf Internet.

    CrunchBang Linux, une alternative intéressante à Linutop OS 5

Les –

  • Si vous souhaitez utiliser Linutop OS sur une autre machine, il vous faudra débourser 79 €. Je trouve cela un peu fort de café, surtout que des solutions libres et gratuites existent et fonctionnent parfaitement sur les boîtiers (par exemple CrunchBang Linux dont je parle ci-dessus)
  • Firefox qui est un peu trop lourd pour la RAM disponible. J’ai installé Chromium qui fonctionne sans problème.
  • Outil graphique: franchement c’est quoi ce mtPaint graphic editor ? C’est pour concurrencer Paint sous Windows ?

Quelques photos…

Pleins d’autres images à retrouver sur Flickr

Alors j’achète ou j’achète pas ?

On arrive donc à la conclusion de cet article et à la question fatidique: est que, dans le rôle d’un décideur informatique (ce que je suis dans le cadre de mon boulot), j’achèterai cette solution…

Le hardware (Linutop 4) est vraiment de très bonne qualité, le silence total et il ne semble pas trop chauffer même après quelques jours d’utilisation sans extinction. Mais à plus de 400 € (avec livraison), je trouve quand même l’addition un peu salée. Donc à moins de négocier les prix à la baisse (321 € par exemple…) ou bien d’obtenir pour ce prix une configuration plus musclée (au minimum 2 Go de RAM et mémoire Flash plus importante), je regarderai attentivement du coté de la concurrence avant de lancer mes achats.

Donc j’achète le boîtier vierge (sans OS) au prix maximum de 320€.

Concernant l’OS Linutop 5, je suis beaucoup plus sévère. Bien que je comprenne la volonté de fournir aux utilisateurs un système clés en main, je ne trouve pas celui-ci adapté au hardware (XFCE, Firefox, pack logiciel graphique…). De plus, faire payer cet OS (qu’ils soit inclus dans le prix des boîtiers Linutop ou bien 79€) n’est pas constructif: cela limite la participation de la communauté et peut mettre à dos le clan des barbus qui peuvent y voir une vente liée de système GNU/Linux (un comble)…

Je n’achète pas l’OS Linutop 5, et j’utilise sur les boîtiers Linutop des OS GNU/Linux gratuits, léger et alternatifs.

Catégories
Open-source Planet-libre Systeme

Des outils de test pour stresser votre système

Le développement logiciel nécessite des phases de test et de validation qui sont souvent menées sur des machines non chargées. Je vous propose donc de découvrir, dans ce billet, une série de petits logiciels permettant de simuler une charge sur votre système et qu’il faudra donc lancer en parallèle de vos applications à valider. J’ai uniquement sélectionné des logiciels libres, légers, en ligne de commande et disponible dans les dépôts Ubuntu standards.

Comment stresser une machine ?

Plusieurs leviers permettent de « stresser » une machine:

  • consommation CPU
  • utilisation de la mémoire MEM
  • entrée/sortie IO
  • lecture/écriture disque DISK
  • entrée/sortie réseau NET

L’utilisation conjointe de ces leviers permet de simuler une charge sur une machine cible. L’amplitude des paramètres appliquées à ces leviers est bien sûr à adapter à votre configuration hardware et système.

Note: l’utilisation des logiciels décrits si-dessous peut entraîner le plantage pure et simple de votre machine (cela m’est arrivé pendant mes tests…). Je vous conseille donc vivement de ne pas les appliquer sur une machine en production…

Fuzz

Le premier logiciel est Fuzz. Contrairement aux autres solutions, ce dernier ne génère pas de « stress » par lui même mais demande à d’autres programmes de le faire.

Ainsi, la ligne de commande suivante:

fuzz grep foo

va lancer 10.000 fois la commande « grep foo » en lui donnant en entrée des données factices. Ainsi votre machine va chercher la chaîne de caractère foo dans un flot de données. Nous pouvons donc voir, grâce à Glances (un peu de pub…),  que la charge CPU (recherche de sous-chaine) et IO (entrée-sortie disque) augmentent.

Le nombre d’exécution (-r par défaut 10.000) et le time-out (-t par défaut 120 secondes) sont bien-sur paramétrable en ligne de commande (voir le man).

Si vous connaissez les applications qui tourneront en parallèle de la votre, il est facile de simuler votre environnement cible. Il manque par contre un peu de finesse pour tester votre application avec des contraintes pré-définies (par exemple avec une charge CPU de 75%).

Spew

Développé par HP et mis à disposition de la communauté, Spew est spécialisé sur le stress par entrée-sortie disque. Il permet d’écrire et/ou de lire des fichiers de test sur votre disque.

Pour générer un fichier de 5 Go nommé /tmp/bibi:

$ spew 5G /tmp/bibi
WTR:    90320.56 KiB/s   Transfer time: 00:00:58    IOPS:   180641.12

La même commande mais en forçant la relecture du fichier à la fin de l’écriture:

$ spew --read-after-write 5G /tmp/titi
WTR:    74740.25 KiB/s   Transfer time: 00:01:10    IOPS:   149480.49
RTR:  1761227.45 KiB/s   Transfer time: 00:00:02    IOPS:  3522454.90
On peut voir une montée en charge globale de la machine (LOAD) mais juste avec des entrées/sorties (IO):

Note: pensez à supprimer vos fichiers de test (/tmp/bibi)…

Stress et StressAppTest

Deux logiciels qui font fonctionnellement la même chose (jouer sur l’ensemble des leviers permettant de stresser une machine) mais de manière différente…

Stress est une application permettant de générer des processus (worker) ayant des caractéristiques communes:

  • CPU (consommation de la CPU grâce à l’exécution de la commande sqrt)
  • MEM (avec exécution des commandes malloc et free)
  • IO (avec execution de la commande sync)
  • DISK (execuiyon des commandes read et write)

Avec la commande suivante:

stress -m 10 --vm-bytes 512000000 -t 30

On se retrouve donc avec 10 processus consommant chacun 512 Mo:

Contrairement à Stress, StressAppTest ne génère par défaut qu’un seul processus qui va regrouper les caractéristiques de stress souhaitées.

Ainsi, la commande:

$ stressapptest -s 30 -M 256 -m 8 -C 8 -W

Log: Commandline - stressapptest -s 30 -M 256 -m 8 -C 8 -W
Stats: SAT revision 1.0.3_autoconf, 64 bit binary
Log: buildd @ allspice on Wed Jan 11 17:38:51 UTC 2012 from open source release
Log: 1 nodes, 4 cpus.
Log: Prefer plain malloc memory allocation.
Log: Using memaligned allocation at 0x7f9e9f157000.
Stats: Starting SAT, 256M, 30 seconds
Log: Region mask: 0x1
Log: Seconds remaining: 20
Log: Seconds remaining: 10
Stats: Found 0 hardware incidents
Stats: Completed: 458960.00M in 31.10s 14756.72MB/s, with 0 hardware incidents, 0 errors
Stats: Memory Copy: 458960.00M at 15298.83MB/s
Stats: File Copy: 0.00M at 0.00MB/s
Stats: Net Copy: 0.00M at 0.00MB/s
Stats: Data Check: 0.00M at 0.00MB/s
Stats: Invert Data: 0.00M at 0.00MB/s
Stats: Disk: 0.00M at 0.00MB/s
Status: PASS - please verify no corrected errors

Donne:

Je vous invite à consulter la documentation officielle du projet pour y découvrir les nombreuses options.

Pour finir…

Cette liste est très loin d’être exhaustive. L’idée étant de partager votre savoir…

Quel logiciel utilisez vous pour faire vos test de performances sur des machines chargées ?

Avez-vous des solutions multi-plateforme ?

A vos claviers 🙂

Catégories
Open-source Reseau

Tester une liaison TCP/IP avec nttcp

NTTcp est un petit utilitaire bien pratique, dans la lignée des IPerf, pour tester une liaison TCP/IP (ou UDP) en ligne de commande sous Linux. A ajouter à votre liste d’outils pour l’administrateur réseau

Installation de NTTcp

Il faut installer le logiciel sur les deux machines (ou plus) entre lesquelles vous voulez tester votre réseau TCP/IP.

Sous Ubuntu:

[shell]sudo aptitude install nttcp[/shell]

Utilisation de NTTcp

Sur la machine A ayant comme adresse IP 192.168.0.100 (d’un coté du réseau):

[shell]nttcp -i -v[/shell]

Sur la machine B (de l’autre coté du réseau à tester):

[shell]nttcp -t -T 192.168.0.100[/shell]

Par défaut, NTtcp va transférer 2048 « buffers » de 4 Kilo octets (4KB), soit un total de 8 Mo de B vers A.

Le résultat devrait ressembler à:

     Bytes  Real s   CPU s Real-MBit/s  CPU-MBit/s   Calls  Real-C/s   CPU-C/s
l  8388608    0.71    0.02     93.8840   3355.2754    2048   2865.11  102394.9
1  8388608    0.72    0.06     92.7279   1198.3084    5209   7197.55   93012.9

Les options disponibles

Pour inverser et effectuer un test de débit de A vers B, il faut utiliser l’option -r au lieu de l’option -t.

On peut notamment noter l’option -u pour forcer l’utilisation du protocole UDP en lieu et place de TCP.

Un petit coup de man:

[shell]

Usage: nttcp [local options] host [remote options]
local/remote options are:
-t transmit data (default for local side)
-r receive data
-l# length of bufs written to network (default 4k)
-m use IP/multicasting for transmit (enforces -t -u)
-n# number of source bufs written to network (default 2048)
-u use UDP instead of TCP
-g#us gap in micro seconds between UDP packets (default 0s)
-d set SO_DEBUG in sockopt
-D don’t buffer TCP writes (sets TCP_NODELAY socket option)
-w# set the send buffer space to #kilobytes, which is
dependent on the system – default is 16k
-T print title line (default no)
-f give own format of what and how to print
-c compares each received buffer with expected value
-s force stream pattern for UDP transmission
-S give another initialisation for pattern generator
-p# specify another service port
-i behave as if started via inetd
-R# calculate the getpid()/s rate from # getpid() calls
-v more verbose output
-V print version number and exit
-? print this help
-N remote number (internal use only)
default format is: %9b%8.2rt%8.2ct%12.4rbr%12.4cbr%8c%10.2rcr%10.1ccr

[/shell]

Catégories
Blog Developpement Open-source Reseau

Tester son site/blog sous IPhone sans IPhone

Vous voulez tester comment est vu votre site/blog sur un IPhone mais vous n’en avez pas un sous la main (ben ouep c’est pas libre alors…) ? Alors vous serez heureux d’apprendre qu’il existe une méthode assez simple pour que votre navigateur favori ( j’ai nommé Firefox) se fasse passer pour un IPhone…

Installation du plugin « User Agent Switchers »

La première chose à faire est d’installer le plugin « User Agent Switchers » qui va permettre à Firefox de se déguiser en IPhone. Une fois le plugin installé et le navigateur redémarré, un nouveau menu sous « Outils / Default User Agent » devrait apparaitre:

Il suffit de cliquer sur le bouton « IPhone 3.0 » pour que Firefox se fasse passer pour un navigateur IPhone. Pou revenir à un comportement normal de votre navigateur, il suffira de cliquer sur le bouton « Default User Agent ».

Tester son site/blog

Rien de plus simple, il suffit de se rendre sur l’URL de votre blog pour le voir s’afficher comme sur un iPhone. Par exemple Le Blog de Nicolargo (c’est juste un exemple, j’utilise le plugin WordPress WPTouch donc l’affichage devrait être adapté…).

Les esprits chagrins vont me dire que cela n’est pas du tout représentatif car la résolution de l’Iphone est beaucoup plus faible que la résolution de notre écran, c’est vrai mais… il existe des sites (par exemple TestIphone) qui permettent d’effectuer le même test mais dans une frame simulant la taille d’un IPhone. Perso le test chez moi du site TestIphone n’est pas concluant car je suis redirigé vers la version plein écran de mon blog…

Catégories
Open-source Reseau

Générer des paquets IP avec HPING…

… ou comment tester de manière efficace son réseau…

Installation (sur Fedora)

Après avoir récupéré les sources sur le site officiel, dézippé et détarré…

yum install libnet-devel libpcap-devel
ln -s /usr/include/pcap-bpf.h /usr/include/net/bpf.h
./configure –no-tcl
make
make install

Exemples d’utilisations

Un ping TCP simple (pardéfaut sur le port 0):

# hping 192.168.29.1
HPING 192.168.29.1 (eth0 192.168.29.1): NO FLAGS are set, 40 headers + 0 data bytes
len=46 ip=192.168.29.1 ttl=64 id=21068 sport=0 flags=RA seq=0 win=0 rtt=0.3 ms
len=46 ip=192.168.29.1 ttl=64 id=48983 sport=0 flags=RA seq=1 win=0 rtt=0.3 ms
len=46 ip=192.168.29.1 ttl=64 id=44368 sport=0 flags=RA seq=2 win=0 rtt=0.2 ms

Un ping TCP sur le port 80:

# hping 192.168.29.1 -c 2 -S -p 80 -n
HPING 192.168.29.1 (eth0 192.168.29.1): S set, 40 headers + 0 data bytes
len=46 ip=192.168.29.1 ttl=64 DF id=14101 sport=80 flags=SA seq=0 win=57344 rtt=0.2 ms
len=46 ip=192.168.29.1 ttl=64 DF id=6759 sport=80 flags=SA seq=1 win=57344 rtt=0.5 ms

Un ping ICMP (même fonction que le ping classique):

#hping 192.168.29.1 -1
HPING 192.168.29.1 (eth0 192.168.29.1): icmp mode set, 28 headers + 0 data bytes
len=46 ip=192.168.29.1 ttl=64 id=52414 icmp_seq=0 rtt=0.3 ms
len=46 ip=192.168.29.1 ttl=64 id=18412 icmp_seq=1 rtt=0.2 ms

Un ping TCP avec spoofing (c’est à dire génération d’un paquet avec une adresse IP source différente de celle de la machine qui lance le hping):

# hping 192.168.29.1 -a www.google.fr
HPING 192.168.29.1 (eth0 192.168.29.1): NO FLAGS are set, 40 headers + 0 data bytes

PS: dans ce mode, vous n’aurez bien sur pas les réponses, qui seront envoyés à la machine spécifiée par l’option -a… c’est pour cela que c’est une attaque ben connue dans le monde des réseaux).

Quelques options…

-i : permet de fixer l’intervalle de temps (en seconde) entre deux pings
-c : nombre de paquets à générer
-q: affiche seulement le rapport final

Exemple:

— 192.168.29.1 hping statistic —
5 packets tramitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.3 ms

-V: active le mode verbose

Exemple:
len=46 ip=192.168.29.1 ttl=64 id=6825 tos=0 iplen=40
sport=0 flags=RA seq=2 win=0 rtt=0.3 ms
seq=0 ack=624676233 sum=fdf5 urp=0
-0: active le mode RAW IP
-1: active le mode ICMP
-2: active le mode UDP

Si vous voulez une liste de toutes les options, c’est par ici.

Catégories
Blog Web

Tester son site sous IE

IE vs FirefoxEncore un site pour tester son site sous IE si comme moi vous n’avez pas accès à une machine sous Windows. Il faut se rendre sur le site suivant: IPNetRenderer, choisir la version d’IE à tester (7, 6 ou 5.5), saisir l’URL à tester et cliquer sur le bouton « Render ». Quelques secondes plus tard, l’image de la visualisation d evotre site sur le navigateur testé est affiché.

Par rapport aux autres sites (voir article sur ce sujet), IE NetRenderer se détache par sa rapidité de traitement (moins de 20 secondes lors de mes tests).

PS: j’ai ainsi remarqué que IE a une interprétation bien particulière des normes CSS…

Catégories
Reseau

Test de bande passante sur les réseaux Wifi

Le but de ce post est de tester le débit réel (pas celui inscrit sur l’emballage) des réseaux Wifi. Nous allons pour cela utiliser le logiciel Iperf dont vous pouvez trouver un tutoriel ici.

Pour effectuer ce test il faut:

  • un PC (PC°1) branché en direct (par cable Ethernet) à votre borne Wifi (ou à votre box).
  • un autre PC (PC°2) disposant d’une interface Wifi. Le plus simple étant que ce PC soit protable pour faciliter les tests.
  • une borne Wifi (ou une box) correctement configurée.

Voici un exemple de configuration:

Installation de Iperf

La première chose à faire est d’installer Iperf sur les deux PC (voir le tuto pour plus d’informations).

Test de référence sans le Wifi

C’est le test de référence sans Wifi.

Voici la configuration du test:
PC°1: Branché directement par un câble Ethernet à la borne Wifi.
PC°2: Branché directement par un câble Ethernet à la borne Wifi.

Et le test à effectuer:

TEST°1:

Sur le PC°1:
# iperf -s
------------------------------------------------------------
Client connecting to al-firewall1, TCP port 5001
TCP window size: 65.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.2 port 50953 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 66.7 MBytes 55.8 Mbits/sec

Sur le PC°2:
# iperf -c
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 56.0 KByte (default)
------------------------------------------------------------
[ 6] local 192.168.1.1 port 5001 connected with 192.168.1.2 port 50953
[ 6] 0.0-10.0 sec 66.7 MBytes 55.9 Mbits/sec

Le résultat du TEST°1 est donc: 55.9 Mbits/sec
On est déjà loin des 100 Mbps des ports Ethernet…

Test de référence avec le Wifi

C’est le test de référence avec Wifi. Le PC Wifi (PC°2) étant le plus proche que possible de la borne.

Voici la configuration du test:
PC°1: Branché directement par un câble Ethernet à la borne Wifi.
PC°2: En Wifi, proche de la borne (moins de 1 mètre).

Et le test à effectuer:

TEST°2: Moins de 1 mètre

Sur le PC°1:
# iperf -s

Sur le PC°2:
# iperf -c

Test du réseau Wifi

On va alors s’éloigner petit à petit de la borne Wifi et effectuer le même test à chaque fois.

Voici la configuration du test:
PC°1: Branché directement par un câble Ethernet à la borne Wifi.
PC°2: En Wifi, la distance à la borne dépend du test.

TEST°3: 2 mètres
TEST°4: 5 mètres
TEST°5: 10 mètres
TEST°6: 15 mètres
TEST°7: 20 mètres
TEST°8: 30 mètres

Notes: Il faut bien entendu noter si il y a des murs entre le PC°2 et la borne Wifi et si oui noter le nombre de murs.

Rapport final

Le rapport final ressemblera à:

Type de borne Wifi: Réference, configuration…
Type de PC°1: CPU, Mémoire, OS
Type de PC°2: CPU, Mémoire, OS, Chipset Wifi
Resultat du TEST°1: … Mbits/secs
Resultat du TEST°2: … Mbits/secs
Resultat du TEST°3: … Mbits/secs
Resultat du TEST°4: … Mbits/secs
Resultat du TEST°5: … Mbits/secs
Resultat du TEST°6: … Mbits/secs
Resultat du TEST°7: … Mbits/secs
Resultat du TEST°8: … Mbits/secs

Si vous faite le test chez vous merci de nous faire connaître vos résultats !