Il faut dire que la procédure pour le faire n'a rien de bien complexe, puisque qu'il suffit d'appeler le binaire PHP en CLI avec l'option -S suivi de l'adresse IP et du port sur lequel il doit écouter, de la manière suivante :

# php -S 127.0.0.1:8080

le serveur de PHP se lance alors et indique qu'il attend des requêtes HTTP sur l'adresse IP et le port qui lui ont été passés en argument :

PHP Development Server is listening on 127.0.0.1:8080 in . ... Press Ctrl-C to quit.

Les lecteurs attentifs auront remarqué deux choses :

  1. La première partie du message est incomplète, puisqu'elle se termine par in ., au lieu de in path/to/current/directory, preuve que PHP 5.4 est toujours en cours de développement ;
  2. Il suffit d'exécuter la combinaison de touches Ctrl-C pour arrêter le serveur ;

Le serveur HTTP est donc apparemment bien lancé, et pour le vérifier, il suffit de taper l'URL http://127.0.0.1:8080 dans la barre d'adresse du navigateur de votre choix.

Si tout fonctionne correctement, vous devriez obtenir le résultat suivant, s'il n'y a pas de fichier nommé index.html ou index.php dans le répertoire depuis lequel vous avez lancé le serveur :

Not Found
The requested resource / was not found on this server.

De plus, vous devriez avoir la confirmation que votre requête a bien été traitée par le serveur dans votre console, car le message suivant devrait y apparaître :

[Tue Jul  5 13:31:08 2011] 127.0.0.1:51668: / - No such file or directory
[Tue Jul  5 13:31:08 2011] 127.0.0.1:51668: / - Sending error page (404)

En effet, conformément à sa RFC, le serveur web cherche, lorsque l'URL qu'il reçoit correspond à un répertoire sur le système de fichier, un fichier nommé index.html ou index.php.

Cependant, la RFC ne précise pas l'extension de fichier prioritaire, et pour savoir à quoi m'en tenir, j'ai donc mis dans le répertoire de démarrage du serveur les fichiers index.html et index.php.

Il en ressort que, pour le moment, paradoxalement, le fichier index.html est prioritaire sur index.php.

J'ai ensuite mis en concurrence le serveur intégré de PHP avec le serveur web le plus utilisé actuellement, à savoir apache, dans sa version  2.2.12, compilé en mode prefork.

Pour cela, j'ai défini le répertoire de départ du serveur de PHP vers le répertoire de départ par défaut de mon serveur apache, à savoir /var/www/, à l'aide de l'option -t :

# php -S 127.0.0.1:8080 -t /var/www/

J'ai ensuite utilisé l'utilitaire ApacheBench, aka ab, pour envoyer 1000 requêtes concurrentes réparties sur 10 clients pour différents contenus, et cela sur chacun des deux serveurs, apache et le serveur web de PHP écoutant respectivement sur les ports 80 et 8080.

J'ai commencé doucement, en demandant aux deux serveurs d'envoyer le contenu d'un simple fichier HTML, et j'avoue avoir été surpris du résultat, même si le serveur de PHP n'est en aucune manière destiné à la production.

En effet, ce dernier tient la dragée haute à apache, puisque tous deux se sont révélés capables de gérer approximativement le même nombre de requêtes par seconde.

À contrario, en demandant un fichier inexistant, très curieusement, les performances du serveur HTTP de PHP s'effondre par rapport à apache, qui parvient dans ce cas à traiter près de quatre fois plus de requêtes par seconde.

Et curieusement, les résultats du serveur de PHP ne s'améliorent pas dans le cas d'un appel à un fichier PHP ne contenant qu'un simple <?php echo uniqid(); ?>, car même si dans ce cas, l'écart entre les deux logiciels se réduit, apache parvient à gérer un peu plus du double de requêtes par seconde par rapport à PHP.

Les résultats ont cependant fini par s'équilibrer lorsque j'ai testé du code de production correspondant à une application basée sur Symfony 1.4 et conçue et distribuée par mon employeur PMSIpilot.

Dans ce cas de figure, le serveur intégré de PHP s'est même permis de faire mieux que son adversaire, en parvenant à gérer quelques requêtes supplémentaires par seconde.

Il est donc difficile de tirer une leçon de ces tests puisque les résultats sont relativement contrastés suivant les différents contextes de mise en œuvre et que j'ai de toute façon voulu comparer des choses incomparables.

En effet, apache est destiné à la production alors que le serveur de PHP est un outil de développement, et il n'est donc pas logique de comparer un outil taillé pour supporter des contraintes de mise en œuvre potentiellement fortes avec un autre qui ne l'est pas, un environnement de développement étant par définition beaucoup plus léger qu'un environnement de production.

Et reste indépendamment de ses performances, le serveur HTTP de PHP 5.4 remplit parfaitement son contrat, qui est de permettre au programmeur de disposer à moindre frais et très rapidement d'un serveur HTTP pleinement fonctionnel pour ses développements, et non d'offrir des performances extraordinaires ou au moins équivalentes à d'autres solutions.

Sa mise en œuvre est en effet extrêmement simple, ne demande aucune configuration ni installation, et il fourni via la console une trace compréhensible et exploitable de l'ensemble des requêtes qu'il reçoit.