wOueb by Romain DECKER / Another IT Guy Blog

Ceux qui manipulent régulièrement des équipements réseaux (notamment Cisco) doivent toujours avoir dans leur trousse à outil un serveur TFTP pour faire des copies de configuration, et/ou de code (firmware, IOS, etc.).

Petit rappel :

Le TFTP, pour Trivial File Transfert Protocol, un protocole simplifié de transfert de fichier qui fonctionne en UDP sur le port 69.

Personnellement, j’utilise depuis 6 mois TFTP32, un serveur TFTP opensource et accessoirement IPv6 Ready (même si ça ne sert pas beaucoup beaucoup encore aujourd’hui).

On peut noter que TFTPD32 peut également faire : client TFTP, serveur SNTP (serveur de temps), serveur Syslog, serveur DHCP (attention à ne pas oublier de le couper si vous en avez déjà un en fonction sur votre réseau), et serveur DNS.

Il est possible de :

• le télécharger en tant que simple exécutable,
• l’installer en tant qu’exécutable,
• l’installer en tant que service.

Il existe même une version 64 bits de TFTPD32 : elle propose exactement le même programme, mais compilé en 64 bits.

Pour ceux que ça intéresse, la page de téléchargements, et la Foire Aux Questions.

Vous disposez d’un ou de plusieurs serveurs Linux ? Vous voulez tester les performances de votre disque en lecture/écriture ? Il existe plusieurs solutions, mais je ne vais en détailler que deux :

• la commande hdparm,
• une création/lecture de fichier avec la commande dd.

Test avec hdparm

hdparm est un utilitaire qui permet de modifier les paramètres d’un périphérique disque, mais il permet également de lancer un test de performance des temps de lecture via la commande :

hdparm -Tt /dev/sda

Ce qui donne sur mon serveur :

Paramètres :

• -t : test des performances de lecture,
• -T test des performances du cache.

Attention : la commande hdparm, si elle est mal utilisée, peut entraîner la corruption d’un disque.

Test avec la commande dd

La commande dd permet de créer, convertir et manipuler des fichiers sur Linux : en la combinant avec une autre commande et les bons paramètres, on peut en tirer les temps d’écriture et de lecture pour un fichier d’une taille donnée.

Le test de vitesse d’écriture se fait de la façon suivante :

time sh -c "dd if=/dev/zero of=/home/woueb bs=4096 count=256000 && sync"

On créé un fichier /home/woueb composé de 256000 blocs de 4Ko.

Et pour le test en lecture, on fait l’inverse : on lit le fichier /home/woueb précédemment créé.

time sh -c "dd if=/home/woueb of=/dev/zero bs=4096 count=256000 && sync"

Et voilà le travail !

Après un court article d’introduction sur Memcached, je reviens sur son monitoring.

Pour rappel :

Memcached est un système de cache d’objets distribué et non répliqué. Il va stocker des objets en RAM, pour diminuer les temps de réponses des applications.

Chaque serveur Memcached démarre avec une certaine quantité de mémoire allouée. Comme le système est de type LRU (Least Recently Used), ce sont les données les plus anciennes qui seront supprimées une fois la limite de la mémoire atteinte. Et inversement, il n’est pas non plus judicieux d’allouer trop de RAM car la perte d’une instance Memcached entrainerait la perte des données stockées (si elle n’est pas protégée/répliquée).

Pour surveiller les serveurs Memcached, on peut jouer avec beaucoup d’outils / de scripts (templates Cacti, Nagios, etc.), mais il existe une solution dédiée au monitoring  et au debugging de Memcached : phpmemcacheadmin.

Se présentant sous la forme de quelques fichiers PHP à déposer sur un serveur Web, on peut y ajouter et monitorer autant de serveurs Memcached que l’on souhaite.

On y retrouvera un tableau de bord avec divers statistiques :

• mémoire utilisée pour le cache,
• nombre de requêtes,
• nombre et taux de hits (données présentes en cache, environ 75% dans mon cas),
• trafic réseau,
• etc.

Il est également possible de consulter des statistiques « live » par serveur surveillé.

Consultation "live" des statistiques

Enfin, il est possible de consulter les valeurs stockées via la page « Execute commands on Servers », et d’interagir avec : insertion, suppression, flush des données, etc.

Exécution de commandes via phpmemcacheadmin

Très bon complément de votre système de monitoring global, phpmemcacheadmin permet une vue plus complète de vos serveurs Memcached, pour une installation simplissime.

Parmi toutes les optimisations possibles pour un blog, un site ou une application, on retrouve Memcached qui se positionne comme un système de cache d’objets distribué et non répliqué. Initialement développé par Danga pour Livejournal, c’est un outil open source qui est maintenant utilisé par de nombreux sites (Facebook, Youtube, mon blog, Flickr, etc.)

J’utilise Memcached sur le serveur de mon blog depuis quelques mois, et la différence avec/sans est assez flagrante.

Pour comprendre son utilité, je rappelle simplement que les temps d’accès à la mémoire vive d’un serveur sont nettement supérieurs à ceux d’un disque (nanosecondes VS millisecondes, cad un ratio compris entre 10 000 et 100 000).

C’est là que Memcached intervient. Il va créer des tableaux de données en RAM : cela va contribuer à réduire le nombre de fois qu’une même donnée stockée sur un périphérique de stockage mécanique est lue.

La principale chose à comprendre avec Memcached est qu’il s’agit d’un système d’usage général, et que les applications doivent être « conscientes » de sa présence. Ce n’est pas quelque chose de magique, qu’il suffit d’installer pour multiplier les performances par 10. Il faudra a minima installer un plugin si vous utilisez un CMS, voire repasser dans une partie du code.

Sous forme d’architecture client-serveur, Memcached se présente comme un démon qui écoute par défaut sur le port 11211. Le système créé des tableaux dont les clés de 250 octets pointent vers des valeurs qui peuvent avoir jusqu’à 1 Mo (mégaoctet). Si la quantité de mémoire allouée est pleine, les clés les plus anciennes sont supprimées (méthode Least Recently Used). Comme les données sont stockées en RAM, elles seront perdues si le serveur redémarre.

Il est possibles d’utiliser plusieurs instances Memcached. Par exemple, une application ABC peut mettre des données en cache sur 3 serveurs différents :

• memcached1.monappli.com
• memcached2.monappli.com
• memcached3.monappli.com

Chaque serveur sera autonome et ne communiquera pas avec ses voisins.

Il est possible de répliquer des instances Memcached, mais ceci est une autre histoire !

Un grand nombre de librairies clientes pour accéder à Memcached sont disponibles : C/C++, PHP, Java, Windows/.Net, Ruby, Perl, etc.

Performances : avec / sans Memcached sur un WordPress

Pour vérifier le gain de performances, j’ai utilisé un serveur de test, avec une installation de WordPress vierge. J’ai fait un test de charge avec ApacheBench, avec et sans Memcached activé.

Benchmark :

• WordPress sans Memcached : 8,75 requêtes / secondes,
• WordPress avec Memcached : 150 requêtes / secondes.

Nb : il s’agit d’une installation d’Apache2 avec un paramétrage par défaut sur une CentOS 5.5 32 bits, 1 vCPU 2 Ghz, 512 Mo de Ram.

En conclusion, Memcached est un élément non négligeable qu’il est bon d’intégrer dans la conception d’une application. Cependant, comme c’est une couche d’intégration supplémentaire, il faut faire en sorte que l’application soit consciente que système existe.

Je reviendrais plus tard sur l’installation de Memcached…

Sur un OS linux, on a tendance a utiliser régulièrement la commande « top«  pour visualiser l’activité des processus du serveur ou du PC. Seulement, le résultat affiché est relativement « fade » et n’est pas ergonomique (l’affichage ne tient pas compte de la taille de l’écran/du terminal).

Voici un exemple d’affichage de la commande « top » :

TOP : visualisation de l'activité des processus

Bien heureusement il existe un outil comblant certaines lacunes de « top » mais plutôt méconnu : « htop« . Démarrant plus rapidement, il offre un certain nombre d’avantages par rapport à son grand frère, notamment :

• interface plus conviviale et adaptée à la taille de l’affichage,
• possibilité de killer un processus sans connaître son PID,
• possibilité de modifier en live la priorité (nice) d’un processus sans connaître son PID,
• pas de délai entre les actions,
• support de la souris,
• etc.

Visualisation de la commande « htop«  :

Visualisation des processus avec HTOP

HTOP : visualisation de l'activité des processus

Verdict ? Adopté !

Lors d’installations ou de configurations de serveurs, on recherche souvent l’une ou l’autre informations sur les paramètres de PHP. Deux choix s’offrent à vous :

• faire un fichier php contenant la directive phpinfo() et l’afficher dans un navigateur,
• afficher le résultat de phpinfo() en ligne de commande.

Pour ce deuxième cas, j’ai déjà vu des personnes faire de longues commandes du type :

echo « < ?php phpinfo()? > » | php

Pour, il existe une commande toute faite :

php -i

Afficher un phpinfo() en ligne de commande

D’autres astuces ?