Code Artistique

admin janvier 16th, 2009

Parmis les outils sympathiques dont nous disposons pour alléger les ressources processeur d’un serveur Apache / Php il existe des solutions dite de caching Opcode.

En précompilant les scripts PHP et en les mettant en cache elles soulagent le compilateur Php. Elles permettent de manière significative d’alléger le travail du(es) processeurs d’un serveur et donc par extension d’accepter aussi plus de trafic sur un seul serveur ;-).

La solution que j’ai tésté sous débian et approuvé depuis maintenant 6 mois est Eaccelerator (Sans aucun problème)

Voici la suite de commandes à passer dans le shell de votre serveur linux :

aptitude install php5-dev
wget http://bart.eaccelerator.net/source/0.9.5.3/eaccelerator-0.9.5.3.tar.bz2
 
bunzip2 eaccelerator-0.9.5.3.tar.bz2
tar xvf eaccelerator-0.9.5.3.tar
 
cd ./eaccelerator-0.9.5.3
 
phpize
 
./configure
 
make
 
make install

Editer le fichier /etc/php5/apache2/php.ini
Insérer les infos de configuration au niveau des extensions :

extension="eaccelerator.so"
eaccelerator.shm_size="256"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

Créer le répertoire de stockage des fichiers précompilés

mkdir /var/cache/eaccelerator
chmod 777 /var/cache/eaccelerator

Réloader Apache

/etc/init.d/apache2 reload

Vérifier dans le phpinfo si Eaccelerator est actif et lancé.

Et ensuite les essais de montée en charge sous apache.. Croustillant

Un simple petit ab va vous donner des ailes quand à l’optimisation que le caching Opcode amène.

Avec eaccelerator :
ab -n 1000 -c 20 http://url
>>>> Requests per second: 156.29 [#/sec]

Sans eaccelerator :
>>>> Requests per second: 44.46 [#/sec]

Résultat on a divisé la charge serveur par 3 (en gros) ou si vous préférez le serveur maintenant accèpte 150 reqùetes à la seconde au lieu de 45 à la seconde.

J’ai lu que parfois certains système de caching Opcode avaient du mal à rafraichir leurs sources en cas de mise à jour massive de scripts php.  Eaccelerator n’est à priori pas de ceux la.

Si vous faites évoluer votre version de php, n’oubliez pas de recompiler eaccelerator.
Avant la recompilation faites un

make clean

Références :
http://www.eaccelerator.net/
http://www.ipersec.com/index.php/2006/05/30/benchmarking-php-accelerators/
http://2bits.com/articles/benchmarking-apc-vs-eaccelerator-using-drupal.html

• Administration Linux
• Comments(0)

admin novembre 18th, 2008

Et bien j’espère que ce post servira bien un jour à toute personne qui rencontrera le même problème que moi et d’autres suite au passage d’un serveur debian de Stable à Testing ! Il se dit dans les milieux “autorisés” que la Testing peut supporter un environnement de production si on utilise pas de packages exotiques. Et bien cela n’est pas toujours aussi simple.

Suite à une simple mise à jour d’un serveur débian 2.6.24.5, et à un reboot pour prise en compte de modifications de lilo, voici que le serveur ne répond plus au ping ! Etrange.. , j’ai d’abord pensé à un kernel panic. Le temps de chercher un petit peu du coté de la modification faite dans lilo, ovh a pris la main sur ma machine, changé la carte mère et réseau !!!! Dingue, il leur a du coup fallu 4 heures pour me rendre la machine. => Dans le même état qu’au départ ! Encore plus incroyable. J’ai donc attendu tout ce temps pour rien, ou presque. Ovh me donnait une précieuse information en disant :

“Reboot soft éffectué en mode netboot bzimage le message suivant est apparut ‘failed to bring up eth0”

Piste intéressante. je me suis donc enfin jeté sur les logs du système :

tail -50000 /var/log/syslog | grep eth0

La réponse fut :

kernel: udev: renamed network interface eth0 to eth1

Mais qui donc a bien eu l’idée de renommer l’interface réseau eth0 en eth1. Pas étonnant que le serveur ne réponde plus au ping !!!

Un coup de Google m’a aidé à trouver ce post très intéressant que je reprend ci dessous

Nous avons donc a faire avec un bug débian finalement assez simple à corriger, mais pas simple à trouver !

Udev a crée automatiquement une ou plusieurs règles pour monter automatiquement les interfaces réseau.

Il faut donc modifier manuellement les règles générées par udev pour indiquer que le montage de l’interface réseau se fait sur eth0.

Trouvez une règle qui se nomme ….persistent-net.rules dans /etc/udev/

vi /etc/udev/rules.d/70-persistent-net.rules

Commenter la première règle qui doit correspondre en gros à cela :

#SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:22:33:44:55",
NAME="eth0"

Pour la ligne qui correspond à l’adresse Mac de votre carte réseau remplacer le ethxxx par eth0

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="01:23:45:67:89:ab", ATTR{type}=="1", KERNEL=="eth*",
NAME="eth1"
 
devient
 
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="01:23:45:67:89:ab", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Sauver le fichier puis rebooter le serveur (sans oublier de passer le boot de la machine sur hd dans le manager Ovh)

En espérant que la multiplication de ce type d’article permettra de vite trouver la solution à ceux qui rencontre le problème.

Références :
http://forum.ovh.com/showthread.php?t=39674
http://forum.ovh.com/showthread.php?t=34764

http://www.debianadmin.com/rename-network-interface-using-udev-in-linux.html

• Administration Linux
• Comments(9)