PHP-FPM est disponible dans le dernier php (5.3)... mais qu'est-ce-que c'est ?

PHP-FPM (FastCGI Process Manager) est une alternative à PHP FastCGI avec toute une série d'amélioration.

Principalement utile pour les sites à fort taux d'utilisation.

Plusieurs VHosts avec un UID/GID différent et des PHP.ini différents.

FPM permet de faire tourner plusieurs VHosts avec un UID/GID différent et des PHP.ini différents.

Support de l'upload accéléré

Statistique de base

similaire à mod_status d'apache.

Redémarrage de secours en cas de destruction accidentelle de l'opcode

Un header d'erreur

une config style

[ini]
 fastcgi.error_header = "HTTP/1.0 550 Server Made Big Boo"

... provoquera l'envoi de cette erreur au lieu d'en "200 tout va bien" avec une page blanche.

amélioration de la gestion des processus en cas de graceful stop/start

En pratique ca permet de prendre en compte une nouvelle config qui nécessite un redémarrage sans interrompre ce qui avait commencé avec l'ancienne configuration.

Journalisation des scripts lents

avec

[xml]
    <value name="request_slowlog_timeout">5s</value>
    <value name="slowlog">logs/slow.log</value>

donnera

[log]
 Sep 21 16:22:19.399162 pid 29715 (pool default)
 script_filename = /local/www/stable/www/catalogue.php 
 [0x00007fff23618120] mysql_query() /srv/stable/common/Database/class.MySQLRequest.php:20 
 [0x00007fff23618560] getResult() /srv/stable/common/Database/class.Facade.php:106 
 [0x00007fff23618aa0] query() /srv/stable/common/mysite.com/ORM/class.UsersMapper.php:99 

Journalisation de Stdout & stderr

fastcgi_finish_request()

une fonction spéciale pour clôturer la connexion avec le client, mais continuer un traitement php à découvrir en détail ici

Autres points

• PHP-FPM est compatible avec ZendOptimizer

à lire aussi

• J'ai commencé une page wikipedia que vous pouvez compléter. ^[1]
• Le site du projet
• http://blog.developpez.com/julienpauli/p8432/php/php-fpm-rejoind-le-svn-de-php/ php-fpm rejoint le svn de php par Julien Pauli
• Le fichier de config de fpm
• dispo pour debian

la suite...

Voici déjà la quatrième interview de cette série concernant la vision de l'avenir qu'ont un panel d'utilisateurs divers et variés pour PHP.

C'est aujourd'hui Arnaud Limbourg qui s'y colle.

Je l'ai rencontré au dernier forum PHP, et j'avoue avoir bien rigolé avec lui, notamment lors du repas des conférenciers.

Il est le premier de cette série à utiliser PHP dans le cadre d'un site à fort trafic, et son point de vue vient donc très bien compléter ceux des intervenants précédents.

Peux-tu te présenter en quelques mots ? Arnaud Limbourg, actuellement responsable technique nouveaux médias chez 20 Minutes où j'ai en charge la maintenance, dans tous les sens du terme, du site 20minutes.fr et tout ce qui tourne autour. Cela fait environ 8 ans que je fais du PHP, surtout pour des back offices et plus récemment dans le cadre... Lire L'avenir de PHP vu par Arnaud Limbourg

Allez on va essayer d'utiliser Zend_log convenablement.

L'idée c'est de découper les moments de décisions.

1. J'écris mon code je décide de journaliser un message ou des infos
2. Je gère mes journaux, je décide où va tel ou tel message.
3. Je gère plusieurs staging, je change le comportement des mes dispatching
4. Je change le format de stockage de mon journal, je décide comment disposer des informations reçues
5. Je décide où je lis/récupère mes messages.

Julien débroussaille Zend_log dans sa Présentation du Zend Framework et une liste de tuto permet de compléter

J'écris mon code je décide de journaliser un message ou des infos

Pendant que je code ma réflexion doit se limiter à

1. quel message envoyer
2. quelles infos complémentaire envoyer
3. quelle gravité/sévérité/catégoriser de message j'envoie.

[php]
<?php 
$log->info('Hello log');
?>

ajoutons une info

[php]
<?php 
$log->info('Hello log je suis à la ligne ' . __LINE__);
?>

Bon là on a envoyé le message

Je gère mes journaux, je décide où vont les messages.

Ca se passe plutôt dans le script. On prépare un objet ($log). qui sera utilisé par la suite dans le code mais on va commencer à lui dire que faire de ces messages qui remontent.

[php]
<?php 
$log = new Zend_Log();
?>

Première chose (évidente) assigner les writers (les scribes).

[php]
<?php 
$redacteur = new Zend_Log_Writer_Stream('/repository/des/ficher.log');
$log ->addWriter($redacteur);
?>

là c'est dans un un fichier mais "stream" permet aussi un accès plus large,

[php]
<?php 
$redacteur = new Zend_Log_Writer_Stream('php://output');
?>

Et on a pas que "stream", ca peut-être aussi

• dans une base de donnée -> Zend_Log_Writer_Db,
• dans firebug -> Zend_Log_Writer_Firebug,
• dans un email -> Zend_Log_Writer_Mail,
• dans un mock -> Zend_Log_Writer_Mock
• dans

la suite...