Lighttpd vs Apache vs Lighttpd + Apache

Il fut un temps où on ne se posait pas de question quant au serveur web, on prend Apache et on en parle plus, aujourd’hui les choses ont changé, Apache reste quand même le plus utilisé avec plus de 66% des parts de marché, suivi par IIS, puis tous les autres « petits » derrière, néanmoins en fonction des besoins, certains de ces petits peuvent s’avérer bien plus performants qu’Apache, aujourd’hui on va tester 3 configurations possibles avec Apache et Lighttpd.

d’après ce qu’on peut lire un peu partout sur le net, Lighttpd (lighty pour les intimes) est beaucoup plus performant quand il s’agit de servir des pages statiques, mais qu’en est-il vraiment ? et comment s’en sort-il avec le contenu dynamique ? (des sites statiques ça n’existe plus de nos jours ^^).

pour notre test, on va prendre un site très léger, basé sur Zend framework (donc loin d’être statique), contenant une page qui affiche 9 images au hasard a partir d’une tables mysql contenant environ 1000 enregistrements (seulement les emplacement des images sont stockés dans la base). Le serveur de test est un kimsufi L (petit processeur et 1Go de RAM).

versions utilisées :
Apache 2.2.9
Lighttpd 1.4.19
PHP 5.2.6

pour les tests on utilise siege, on lance donc un siege avec 100 concurrency sur 10 minutes, voici la commande :

siege -c100 -t10M URL_DU_SITE

on note également le Load average de la machine a la fin de l’opération.

1ère configuration : Lighttpd tout seul

voici le resultat :

Load average : 4.87
 
Lifting the server siege...      done.
Transactions:		       23859 hits
Availability:		      100.00 %
Elapsed time:		      600.37 secs
Data transferred:	       83.25 MB
Response time:		        2.02 secs
Transaction rate:	       39.74 trans/sec
Throughput:		        0.14 MB/sec
Concurrency:		       80.21
Successful transactions:       23859
Failed transactions:	           0
Longest transaction:	        5.20
Shortest transaction:	        0.10

2ème configuration : Apache2 tout seul

le résultat :

Load average : 77.51
 
Lifting the server siege...      done.
Transactions:		       23543 hits
Availability:		      100.00 %
Elapsed time:		      599.66 secs
Data transferred:	       82.16 MB
Response time:		        2.04 secs
Transaction rate:	       39.26 trans/sec
Throughput:		        0.14 MB/sec
Concurrency:		       80.22
Successful transactions:       23543
Failed transactions:	           0
Longest transaction:	       10.51
Shortest transaction:	        0.05

3ème configuration : Lighttpd + Apache

maintenant faisons le test en couplant les 2, dans cette configuration tout ce qui est statique (images, css, js, etc.) sera servi par lighty alors que les scripts php eux, seront traités par apache, pour cela on active le mod_proxy dans lighty, et on ajoute le code suivant dans le vhost de notre site :

 $HTTP["url"] !~ "\.(js|css|gif|jpg|png|ico|txt|swf|html|htm)$" {
               proxy.server  = ( "" => (
                               ( "host" => "127.0.0.1", "port" => 8080 )
                       )
               )
       }

vous l’aurez compris, Apache écoute sur le port 8080 (c’est fait en changeant le fichier /etc/apache2/ports.conf).

voici le résultat :

Load average : 14.79
 
Lifting the server siege...      done.
Transactions:		       22684 hits
Availability:		      100.00 %
Elapsed time:		      600.25 secs
Data transferred:	       79.10 MB
Response time:		        2.13 secs
Transaction rate:	       37.79 trans/sec
Throughput:		        0.13 MB/sec
Concurrency:		       80.53
Successful transactions:       22684
Failed transactions:	           0
Longest transaction:	        8.61
Shortest transaction:	        0.07

plutôt surprenant !

Conclusion :

Lighty s’en sort très bien au vu des transactions/s (ou le nombre total de transactions traitées), contrairement a ce qu’on pouvait attendre, coupler les 2 nous fait perdre en performances (on enregistre quand même un load average nettement inférieur a la config d’apache tout seul).

personnellement ce que je retiens, c’est que lighty n’est pas si mauvais que ça pour le contenu dynamique, les performances restent quand très proches dans les 3 cas, donc autant utiliser la solution qui nous plait :-)

Share

4 Comments

  1. La perte des performances n’est pas due au fait d’utiliser mod_proxy justement ? Ou est-ce le fait d’avoir les 2 serveurs en parallèle ?

    Je songeais à utiliser Apache sur un port pour servir des pages et lighty sur un autre port pour servir des fichiers à télécharger. Il y a une entête spéciale pour servir d’énormes fichiers avec une faible empreinte mémoire tout en délestant le langage de script employé.

    Répondre

  2. il y a fort a parier que mod_proxy soit la cause de la perte de performances, mais dans ce cas c’est toute la solution qui consiste a coupler les 2 qui est mise en cause, or, c’est la plus répandue.

    une solution qui me parait pas mal, serait, d’utiliser 2 serveurs distincts, un sous apache, l’autre sous lighty, avec apache en front, et dans le code tous les appels vers les fichiers statiques (images, css, js, etc.) se feront sur l’autre serveur en passant par un sous domaine par exemple, et pour simplifier la maintenance du site, les fichiers seront sur l’un des deux serveurs (physiquement) et montés en NFS sur l’autre.

    je ne sais pas ce que ça vaut, mais c’est surement pas fait pour les petits sites a faible trafic :-)

    Répondre

  3. Je n’ai jamais entendu parler de ces serveurs. Franchement je pense qu’on devrait freiner un peu les avancées technologiques pour que les hommes puissent s’adapter d’abord à ce qu’il y a. Maintenant je constate qu’on n’a même pas le temps de maîtriser à fond la dernière découverte technologique qu’une autre se crée à son tour. Ce qui fait qu’on se perd parfois dans tout ça.

    Répondre

  4. En NFS ! C’est histoire de perdre en perf ?

    Si vous voulez accélérer tout ça, fabriquez vous un rootfs en squashfs, puis mettez les pages web à servir en tmpfs (abusivement appelé ramfs).

    Pour la réplication, utilisez git ou svn. Il faut être fou pour ne pas utiliser de gestion de conf. Le html et le php sont du code source comme un autre.

    Le squashfs n’est pas obligatoire, mais la création du tmpfs à partir de svn ou git peut être largement automatisé.

    Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *