Bonjour, j’ai fait le teste de apache, lighttpd et nginx sur un applicatif maison car la charge du dédié utilisant cette applicatif été déjà importe et apache commencer à donner des signes de fatige.

J’ai essayer de rester logique et de me rapprocher le plus coté serveur et client de ce que j’avais en production.

Les informations:

Server: AMD Phenom(tm) II X4 920 Processor, 12Go de ram ddr2 800MHz, gouvenor cpu performance, raid6 avec 8hdd, kernel 2.6.31-10
Client: Laptop Dell inspirons 1555, intel core2duo P8600, 4GB
Rewrite rules activé, gzip compression pour les fichiers js et css, mod expire, php fastcgi, redirection, alias, auth, status
Via le réseau j’ai vérifié les entêtes, la compression, le cache.. via l’extension webdevelopper de firefox
Les autres réglages sont par défault sauf:

Nginx:

worker_processes 20;
worker_connections 1200;
partial log
use epoll;
output_buffers  16 32k;
gzip_buffers    16 16k;
access log off for: jpg|jpeg|gif|css|png|ico|js

Lighttpd:

server.max-fds = 5000
server.max-open-files = 1000
server.event-handler = « linux-sysepoll »
no log
« mod_rewrite »,
« mod_redirect »,
« mod_alias »,
« mod_auth »,
« mod_status »,
« mod_setenv »,
« mod_simple_vhost »,
« mod_compress »,
« mod_expire »
For cgi:
« max-procs » => 60,
« PHP_FCGI_CHILDREN » => « 10″
« PHP_FCGI_MAX_REQUESTS » => « 10″

Apache:

Worker

Pour nginx j’ai du utilisé php-fpm pour le background fast-cgi de php.

Voila l’environnement gentoo utilisé:

Gentoo use flags:

www-servers/nginx-0.8.33  USE= »aio fastcgi ipv6 pcre ssl status zlib -addition -debug -flv -imap -perl -pop -random-index -realip -securelink -smtp -static-gzip -sub -webdav »
www-servers/lighttpd-1.4.26  USE= »fastcgi gdbm ipv6 pcre php ssl -bzip2 -doc -fam -ldap -lua -memcache -minimal -mysql -rrdtool -test -webdav -xattr »
www-servers/apache-2.2.14-r1  USE= »ssl static threads -debug -doc -ldap (-selinux) -suexec » APACHE2_MODULES= »actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias -asis -auth_digest -authn_dbd -cern_meta -charset_lite -dbd -dumpio -ident -imagemap -log_forensic -proxy -proxy_ajp -proxy_balancer -proxy_connect -proxy_ftp -proxy_http -substitute -version » APACHE2_MPMS= »-event -itk -peruser -prefork worker »

Et voila les résultats:

Un fichier js avec plusieurs variante d’options, pour voir les fichiers compresser et statique, sauf dans le cas d’un proxy (quoi que ces serveurs n’ont pas été testé comme ça) il faut plus tenir compte de la partie réseau, surtout que le teste est fait via en réseau gigabyte, la bande passante de l’internaute et de votre serveur sera en générale inférieure:

Ensuite différente taille de fichier statique non compresser tel que des images:

Et très important le php, interpréter via des rewrite rules ou en 404 not found, les temps de requêtes (les meilleurs sont les plus petit):

Le nombres de requêtes qui n’as pas fonctionné (ayant affiché une page d’erreur au lieu de la page normale):

Puis en fin le nombre que requêtes secondes, incluant celle n’ayant pas fonctionné (voir + haut):

Vu que nginx ayant dans ce cas énormément de requêtes n’ayant pas fonctionner, la vitesse ne luis sert à rien.

Conclusion

Apache est à la traîne sur tout les terrains.

Lighttpd: Il est très bon pour la compression de fichiers static car il les met en cache. Le fam permet de ne pas aller voir la date de modification à chaque accès mais il ne semble pas y avoir de gain. Pour les fichiers normaux il est un peu moins bon de nginx mais largement meilleur qu’apache. Il intègre tout ce qu’il faut pour la gestion et l’intégration de php via fast-cgi.

NginX: Il est très bon pour les fichiers statique, semble avoir des problèmes à dé-servir les fichiers php avec php-fpm pour fast-cgi server (ou php-fpm qui ne suit pas), il ne profite pas d’un cache pour les fichiers statique envoyé en compresser ce qui le rends un peu plus lent, par contre lors des benchmarks il été le seul à tirer partie à 100% de mon cpu multi-coeur, et cela ce resent dans les fichiers traditionnel est non compresser, tout est prévu en natif, donc pour les serveurs utilisant plein de fonctionnalité c’est très performant.

Attention, dans un cas optimale tout les images sont mis en cache coté navigateur via le mod expire, idem pour les css et php, donc si vos visiteurs reste longtemps et charge plein de pages d’un site, ou si vous avez plein de visites à une page la partie statique ou dynamique sera plus ou moins utilisé en fonction des cas.