Tuto : Installation FastCGI, eAccelerator sur Release 2 Gentoo 32 bits

[bloggif]

J'ai vraiment galéré pour arriver à bout de l'installation de FastCGI (surtout en module apache) sur ma sur Release 2 Gentoo 32 bits avec PHP 5, c'est pourquoi je vous publie le petit mémo que je me suis fait car je suis sûr, ça servira à d'autres...

Avec cette installation, on ne touche à rien des éléments d'origines, suPHP fonctionne toujours, on bascule juste les sites que l'on veut en FastCGI.

J'ai rédigé ce mémo de mémoire quelques temps après avoir réussi l'installation et donc, il y a peut-être des erreurs, n'hésitez pas à poser une question en cas de problème !

UPDATE!
Maintenant, le tuto n'explique plus l'installation d'eAccelerator mais seulement d'APC pour plusieurs raisons :

- APC sera natif sans PHP6 donc autant s'y habituer tout de suite.
- Niveau performance, ils sont quasi pareil
- APC gère en plus la progression de l'upload avec PHP
- APC permet de mettre des variables (pages, stats, etc) en cache et donc d'economiser encore plus les ressources. Pour ceux que ça interesse, j'ai fais une petite classe PHP très très simple et efficasse pour gérer les éléments à cacher simplement.



FAST CGI PHP

On édite le fichier "/usr/local/portage-ovh/dev-lang/php5-ovh/php5-ovh-5.2.5.ebuild"

En ajoutant au dessous de "--with-curl \" ces deux lignes :


--enable-fastcgi \
--enable-force-cgi-redirect \


On crée le ebuild sous SSL :

ebuild /usr/local/portage-ovh/dev-lang/php5-ovh/php5-ovh-5.2.5.ebuild digest

Puis on lance l'installation sous SSL :

emerge php5-ovh


FAST CGI APACHE

Sous SSL on tape :


cd /home
mkdir src
cd src
wget http://www.fastcgi.com/dist/mod_fastcgi-2.4.6.tar.gz
tar -zxvf mod_fastcgi-2.4.6.tar.gz
cd mod_fastcgi-2.4.6
cp Makefile.AP2 Makefile


Puis on édite le fichier "/home/src/mod_fastcgi-2.4.6/Makefile" et on modifie la ligne ci-dessous :


top_dir = /usr/local/apache


Puis on continue avec SSL :


make
make install


Ensuite, on édite le fichier "/usr/local/apache/conf/httpd.conf"

Et sous la ligne "LoadModule suphp_module modules/mod_suphp.so" on ajoute:

LoadModule fastcgi_module modules/mod_fastcgi.so

Puis on cherche ces 4 lignes toujours dans httpd.conf :


User nobody
Group nobody
</IfModule>
</IfModule>


Et en dessous de ces 4 lignes on ajoute :


FastCgiWrapper On


A la fin du fichier httpd.conf, on trouve le vhost du site sur lequel on veut FastCGI et on ajoute/commente de cette manière :


#AddHandler x-httpd-php5 .php
suPHP_Engine off
<Directory />
suPHP_Removehandler .php
</Directory>

FastCgiServer /home/VOTRE SITE/cgi-bin/php-wrap -user userDuSite -group users -processes 1 -idle-timeout 3600

AddHandler php-fastcgi .php
AddType application/x-httpd-php .php
Action php-fastcgi /cgi-bin/php-wrap


Puis on crée le dossier "/tmp/fcgi_ipc" dans lequel on crée le dossier "/tmp/fcgi_ipc/dynamic"

Ces deux derniers dossier avec un chmod 0777, usager "root" groupe "root"

Puis on crée le fichier "/home/VOTRE SITE/cgi-bin/php-wrap" avec ce contenu :


#!/bin/sh
PHP_FCGI_CHILDREN=8
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=500
export PHP_FCGI_MAX_REQUESTS
exec /usr/local/php5/bin/php-cgi


Ce dernier fichier avec un chmod 0755, usager "USAGER DU SITE" groupe "users"

La variable PHP_FCGI_CHILDREN doit être configurée en fonction du traffic du site. Plus le nombre élevé, plus PHP peut traiter de requêtes en même temps (mais risque aussi d'augmenter le temps de traitement de chacune d'elle). Dans mon cas, relever cette valeur était indispensable car, sinon, la file d'attente des requêtes devient tellement importante que les délais de traitement sont intolérables (l'utilisateur attend qu'un processus fils soit dispo pendant X min/sec).



On peut redemmarer apache pour prendre en compte les modifications.


APC

Sous SSL on tape :


ln -s /usr/local/php5/bin/phpize /bin/phpize
ln -s /usr/local/php5/bin/php-config /bin/php-config
ln -s /usr/local/php5/bin/pear /bin/pear
ln -s /usr/local/php5/bin/pecl /bin/pecl

cd /home
mkdir src
cd src
wget http://pecl.php.net/get/APC-3.0.18.tgz

tar xvzf APC-3.0.18.tgz

cd APC-3.0.18
phpize
./configure && make
make install


Puis dans "/usr/local/lib/php5/php.ini" on ajoute/modifie :


extension_dir = "/usr/local/php5/lib/php/extensions/no-debug-non-zts-20060613/"

extension=apc.so

apc.enabled = 1
apc.rfc1867 = on

[s1tropez]

Merci beaucoup Bloggif pour le tutorial.
Dernière question qui n'en est pas vraiment une, mais bon ...
Ton EACCELERATOR fonctionne bien ?

j'espère que mon APC fonctionnera ...

[s1tropez]

Merci beaucoup Bloggif pour le tutorial.
Dernière question qui n'en est pas vraiment une, mais bon ...
Ton EACCELERATOR fonctionne bien ?
Au niveau des performances, ça t'a donné quoi ?
Puis autre chose, tu as lancé l'install sur ton serveur en production ?

j'espère que mon APC fonctionnera ...

[bloggif]

Alors en fait c'est un peu la zone d'ombre ce eAccelerator :

Quand on l'installe sans avoir activé FastCGI, il se mets automatiquement en - cache enabled "false" - dans phpinfo quelque soit la configuration passée dans php.ini.

Dès qu'on installe FastCGI, il s'active, du moins dans le phpinfo, il passe sur - cache enabled "true" - etc. Le seul hic, c'est que la page qui permet d'administrer le module d'eAccelerator, ne reporte aucune page cachée (seulement la page courante) mais là je ne m'y suis pas fié, j'ai fais quelques tests pour calculer le temps d'execution avec et sans eAccelerator. Les résultats ne sont pas tranchés mais à priori, il y a une amélioration de la vitesse d'execution des scripts. Autre chose, ce qui me fais dire que le module fonctionne bien, c'est qu'il y a des fichiers dans le répertoire temporaire réservé pour eAccelerator. J'imagine que c'est bon signe :-p

Pour APC, je l''avais également installé pour faire un upload progress qui n'avait pas marché, je n'ai pas encore eu le temps de le tester vraiment avec FastCGI sauf pour constater qu'ACP aussi n'affiche pas les pages cachées dans son espace d'administration. Est-ce que lui aussi marche de manière transparente avec une admin qui déconne, ça je ne sais pas :S

Et oui... J'ai fais direct les tests sur mon serveur en prod lol, avec 100 connectés dessus... J'ai procédé par étape et passé je ne sais combien d'heures dessus ! Le mérite c'est que ça me permet d'apprendre en même temps, mais c'est vraiment pas simple quand on n'y connais rien en administration ! Ca fait 2 semaines que j'ai mon dédié et j'ai tellement peur d'oublier les procédures que je me fais des mémo partout pour ne rien oublier lol

[bloggif]

Bon j'ai fais des tests avec et sans eAccelerator et... y'a pas photo ! Je gagne entre 10 et 50% sur la vitesse d'execution des scripts quand eAccelerator est activé !

Ce qui est très étrange, c'est que sur phpinfo() ou sur la page "control.php" (founie dans le package d'eAccelerator), aucune n'indique un nombre de pages cachées supérieur à 1 (seule la page courante semble être prise en compte). Ceci n'a que peu d'importance car j'ai vérifié dans le répertoire temporaire d'eAccelerator et les pages d'opcodes sont bien présentent. Ceci dit, c'est vrai qu'il serait mieux de pouvoir voir en temps réel la liste des pages cachées...


Par contre, au niveau du module FastCGI d'apache, je ne sais pas comment tester son efficacité. J'ai essayé de "switcher" entre suPHP et FastCGI pour essayer de voir une différence mais je ne vois rien de flagrant... Je suis un peu surpris car j'avais lu qu'un passage par FastCGI pouvait faire gagner 15 fois plus de rapidité.
D'autre part, le dossier (dans /tmp) réservé au module FastCGI d'apache est toujours vide, je me demande si c'est bien normal ça...


Je précise que le module FastCGI d'apache n'est pas nécessaire au fonctionnement d'eAccelerator, seul le module FastCGI de PHP est indispensable.

[s1tropez]

Ah bah quand même !
10% à 50% c'est ce que j'avais vu sur les benchmarks d'un blog.
Il faut savoir que ça monte bien plus haut quand les pages sont en cache.
De l'ordre de 10x (ça c'est pour APC par contre)

Je vais installer voir ce que ça donne.

[bloggif]

Envoyé par s1tropez

10% à 50% c'est ce que j'avais vu sur les benchmarks d'un blog.
Il faut savoir que ça monte bien plus haut quand les pages sont en cache.
De l'ordre de 10x (ça c'est pour APC par contre).

Oui mais en fait c'est déjà le cas là, c'est une version cachée des pages qu'eAccelerator utilise, c'est grâce à ça que j'obtiens une vitesse d'execution améliorée des scripts.

Par contre, j'ai l'impression qu'il ne charge pas systematiquement la version cachée car, environ une fois sur 3, le temps d'execution redevient "normal"... Je pense que c'est parce qu'il va chercher souvent la version "originale" du script PHP sur le disque...

Pour ton install, n'hésite pas si tu as des soucis !

[progent]

Bonjour bloggif et merci pour le tuto,

PUIS ON CREE LE DOSSIER "/tmp/fcgi_ipc" DANS LEQUEL ON CREE LE DOSSIER "/tmp/fcgi_ipc/dynamic"

CES DEUX DERNIERS DOSSIERS AVEC UN CHMOD 0777, USAGER "root" GROUPE "root"

ces dossieurs sont bien en 777 + chown root:root, mais j'ai l'erreur suivante en relançant Apache :

* Starting apache2 ...
Syntax error on line 239 of /usr/local/apache/conf/httpd.conf:
FastCgiIpcDir /tmp/fcgi_ipc: can't create dynamic directory "/tmp/fcgi_ipc/dynamic": access for server (uid -1, gid -1) failed: read not allowed

Sais-tu d'où ça peut venir ?

Merci.

[bloggif]

Salut progent,

Essaye avec un chmod 755 ou avec "FastCgiIpcDir /tmp".

De plus, je vais apporter des modifications au tuto car j'ai réussi à faire fonctionner APC ou eAccelerator complétement avec les pages d'admin qui fonctionnent !

[bloggif]

progent > Est-ce que ça a fonctionné ? As-tu une messagerie MSN ou autre ?