Pour être très clair, je n’ai pas testé cette combinaison.

A l’heure actuelle, comme je l’ai souvent dit, je fonctionne sur une pile Nginx (front) / Apache (back) / eAccelerator / Memcached. Sachant que WP-Super-Cache se place au niveau de Apache.

La pile de Julien serait Varnish / Nginx / eAccelerator / memcached.

Franchement, cette pile m’a l’air extrêmement intéressante. Je ne l’ai pas testée, mais j’aimerais vraiment faire un petit benchmark, parce que je suis sûr que les perfs seraient intéressantes, voire encore meilleures que celles de la pile actuelle !

Si vous avez testé cette configuration, je vous remercie de m’en donner des feedbacks !

AbriCoCotier.fr, 2011. | Permalien | 9 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Apache, Nginx, PHP, Varnish

La différence de Varnish est qu’il est un site statique par essence, et donc contrairement à Nginx, il n’est pas capable de passer par WSGI pour servir des pages non-générées. Nginx a également l’avantage de fonctionner avec une pile de connexion, et Varnish est donné comme fonctionnant avec un système de cache interne, mais je n’ai pas réussi à en voir plus dans les trois articles que j’ai lu. Les voici :

Apache, Varnish, nginx and lighttpd

Ce billet montre des comparatifs de performances, qui tendent à montrer dans des conditions assez correctes et objectives que Nginx et Varnish font jeu égal, avec un léger avantage pour Varnish.

Gérer son cache web avec Varnish

Chez HAute-Disponibilité, on peut en apprendre un peu plus sur le système de cache de Varnish, mais je ne m’y suis pas penché davantage.

Booster votre blog WordPress avec Varnish

Sur ce billet de Nicolargo, on peut comprendre comment fonctionne la configuration de Varnish. Ce billet m’a permit de faire le comparatif entre les configurations Nginx et Varnish que je vais présenter ci-dessous.

Comparatif des configurations

Pour bien comprendre la différence entre Nginx et Varnish (tous deux en frontend, sur le port 80, et servant le contenu non statique à Apache sur le port 127.0.0.1:8080), je vais copier-coller les deux configurations l’une à côté de l’autre et les expliquer.

Pour Nginx

Pour Nginx, on va avoir un seul fichier important. Ce sera celui relatif au site servi (donc le fichier de conf sera dans /etc/nginx/sites-available) :

server {
  listen      212.227.159.187:80;
  server_name monsite.fr;
  # On distribue les fichiers statiques directement
  location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|txt|srt|swf)$ {
    gzip_static on;
    root  /var/www/htdocs/abricocotier.fr/;
    access_log  /var/log/nginx/monsite-server-access.log;
    error_log   /var/log/nginx/monsite-server-error.log;
    error_page 404 = /erreur-404;
    expires           30d;
  }

location / {
    proxy_pass    http://127.0.0.1:8080/;
    include /etc/nginx/conf.d/proxy.conf;
    #root   /lerepertoiredemonsite/;
    #index  index.html index.htm;
    }

}

Tout tient dans ce fichier.
On y voir que le premier bloc d’instructions vise à dire à Nginx de traiter tous les fichiers portant les extensions classiques pour des fichiers statiques.
Le deuxième bloc dit à Nginx d’envoyer toutes les requêtes qui restent (non-traitées jusque là) sur localhost:8080.

Pour Varnish

Grâce au billet de Nicolargo, j’ai pu rapidement m’installer une configuration Varnish très simplement en local. C’est pas plus compliqué que pour Nginx.

Dans le fichier /etc/varnish/default.vcl, on met le nom du site qui sera passé au serveur de backend (donc on prend un peu le problème à revers par rapport à Nginx) :

backend www {
.host = "monsite.fr";
.port = "8080";
}

Puis, à la suite, dans le même fichier, les instructions de traitement pour les requètes :

sub vcl_recv {
if (req.http.host ~ "(www\.monsite\.fr|monsite\.fr)") {
set req.backend = www;
} 

# Compatiblity with Apache log
remove req.http.X-Forwarded-For;
set    req.http.X-Forwarded-For = client.ip;
# Normalize Content-Encoding
if (req.http.Accept-Encoding) {
if (req.url ~ "\.(jpg|png|gif|gz|tgz|bz2|lzma|tbz)(\?.*|)$") {
remove req.http.Accept-Encoding;
} elsif (req.http.Accept-Encoding ~ "gzip") {
set req.http.Accept-Encoding = "gzip";
} elsif (req.http.Accept-Encoding ~ "deflate") {
set req.http.Accept-Encoding = "deflate";
} else {
remove req.http.Accept-Encoding;
}
}

# Remove cookies and query string for real static files
if (req.url ~ "^/[^?]+\.(jpeg|jpg|png|gif|ico|js|css|txt|gz|zip|lzma|bz2|tgz|tbz|html|htm)(\?.*|)$") {
unset req.http.cookie;
set req.url = regsub(req.url, "\?.*$", "");
}
# Pas de cache pour les requêtes POST
if (req.request == "POST") {
return(pass);
}
# Pas de cache pour l'interface d'administration de WordPress
if( req.url ~ "^/wp-(login|admin)" || req.http.Cookie ~ "wordpress_logged_in_" ){
return(pass);
}
}

Comme on le vois, ce n’est pas beaucoup plus compliqué, c’est juste que le problème est pris dans l’ordre inverse. Je pense que c’est dû au fait que Varnish est fait pour faire du reverse proxy, contrairement à Nginx, qui n’a peut-être pas été conçu juste pour ça. Mais Nginx a l’énorme avantage de fonctionner avec une pile de requête, donc je me dis qu’il présente une sécurité pour qui n’a pas un gros serveur sous la main mais peu voir affluer à certaines heures de grosses quantités de connexions (et n’ayant pas envie de voir son serveur tomber toutes les 5 minutes).

Je rajoute que le mode de configuration de Nginx est sans doute plus simple pour ceux qui ont un peu regardé la configuration sous Apache (je pense notamment à l’arborescence sites-available/ et sites-enabled/ avec lien symbolique entre les deux pour « activer » un site), et c’est donc un facteur de plus grande facilité d’utilisation.

Enfin, et en terme de performances (c’est ça qui nous intéresse), je n’ai pas réussi à trouver de comparatif clair entre les performances des configurations Nginx+Apache et Varnish+Apache. Je constate que de très gros sites utilisent Nginx+Apache (par exemple, WordPress.com et toute sa plateforme de blogs), mais j’ai l’impression que Varnish n’anonce pas clairement qu’il existe comme le fait Nginx (c’est à dire que quand on a Varnish+Apache, le header de la réponse ne comporte que Apache, donc le client ne peut pas savoir que Varnish est dans la boucle).

D’après un collègue techniquement fort (ce qui m’inciterait à le croire), Apache serait mis souvent en frontend quand on a besoin d’un serveur d’application Java en backend (Tomcat, Weblogic, Websphere, etc), car Apache sans plugin est un serveur statique. J’ai du mal à trouver de quoi étayer cette thèse sur le web, Wikipédia ne mentionnant jamais dans la fiche Apache que celui-ci est un serveur statique quand il n’a pas de plugins (même si en soit, c’est vrai : Apache sans plugin ne peut pas faire beaucoup d’autre chose que de servir des fichiers statiques). La fiche anglophone dit seulement que Apache est fait pour pouvoir servir du contenu static et dynamique. Bref : je continue à penser qu’Apache est une formidable machine à tout faire, mais qu’il y a mieux quand on prend un besoin spécifique (cela dit, Google a plusieurs fois dit qu’il utilisait une version d’Apache modifiée pour ses serveurs, donc il semble difficile de dire qu’Apache n’est pas un serveur rapide).

Bref : si un jour j’ai deux serveurs sous la mains et n’étant pas en productions, je tenterais de faire un ApacheBenchmark des deux configurations, avec un site WordPress en backend, celui-ci ayant une base de donnée correcte, afin que cela simule des conditions réelles.

AbriCoCotier.fr, 2010. | Permalien | 12 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Apache, Nginx, Serveur

D’abord le pourquoi : Pourquoi continuer à s’entêter à vouloir faire davantage de traitements par unité de temps sur des même machines, alors que le coût du matériel baisse sans cesse, et qu’il suffirait d’investir (peu) dans des serveurs plus puissants ?

La réponse est simple : j’ai eu la preuve sous mes yeux que c’était possible, et que, avec un peu de technique/connaissance/travail, on pouvait faire des choses incroyablement rapides, même avec des ordinateurs aujourd’hui considérés comme « vieux ». Rien que parce que les MegaHertz des processeurs constituent des millions de calculs par secondes, et donc que cette fréquence peut suffire, si elle est bien utilisée, à servir un nombre déjà énorme de pages sur un site.

Le problème est donc de coder dans un langage assez rapide (car assez proche du langage machine ou assez compilé) pour rapprocher les traitements à exécuter des fonctions de base du processeur. C’est possible avec des langages tels que le python (quand il est compilé), ou encore plus simplement avec Java, mais évidemment, cela freine toute simplicité de modification du code à la volée (car une compilation est nécessaire), comme le permet le PHP (qui y perd donc sa rapidité, car il est « relu » à chaque fois) (même si lui aussi peut être compilé/mis en cache, par exemple avec PHP Accelerator).

Bref, au final, je me demandais si un CMS « évolué » aurait un temps d’exécution meilleur en étant codé avec un autre langage (en l’occurrence, pour Plone, c’est Python). Dans « évolué », j’entends : « en ayant une perspective de fonctionnalités équivalentes » (c’est à dire avec un système d’extension). Le mieux pour faire un tel comparatif serait de le faire serait de le faire sur un même serveur (disons Apache + mod_python) et avec une même BDD (même serveur pour permettre d’être facilement interchangeable, et de ne comparer les performances propres que d’un seul maillon de la chaine). Allons à l’essentiel : à part le billet suivant « Notes on migrating this blog from WordPress to Plone« , ainsi que le tutoriel sur le site de Plone.org, je n’ai pas trouvé grand chose traitant de Plone et Apache/MySQL, étant donné que celui-ci étant bien plus conseillé d’être mis dans un environnement Zope+Plone+Blob. Le billet le plus intéressant sur les performances de Ploneque j’ai pu trouver  face à WordPress est celui-là : « Plone 4, un CMS plus rapide que WordPress« , qui appelle ce site.

On voit que Plone a des performances approchant le double de celles de WordPress. Sur le site de Plone, le graphique est un peu différent (performances trois fois supérieures à celles de WordPress) :

Ailleurs, sur 01net, un tableau comparatif de plusieurs CMS n’est pas très favorable aux performances de Plone (3/5 en « Robustesse et Performance »), à l’inverse de de eXo Platform, en Java, qui s’en sort beaucoup mieux (4,5/5), et en dessous de Typo3 et Drupal, tous deux (3,5/5) en PHP.

Alors, que faire ? Pour résumer, il ne semble pas que Plone s’en sorte beaucoup mieux que ce que j’aurais espéré par rapport à WordPress. Changer de CMS python alors ? Si je regarde chez DjangoCMS, PyLucid, ou Skeletonz, je ne suis pas sûr de trouver des fonctionnalités équivalentes à ce qu’il y a sur WordPress (grosse communauté, et grosse base de plugins/extensions). La solution pourrait donc venir d’ailleurs : je vois venir l’avènement progressif des CMS Ruby/Rails avec Phusion Passenger/Mod_Rails qui fonctionne avec Nginx, et donc les performances sont tout à fait bluffantes. Reste bien sûr à aligner les fonctionnalités, mais il semble que les projets de CMS en Ruby ne manquent pas, donc il ne me reste plus qu’à aller voir de ce côté là pour trouver mon bonheur

AbriCoCotier.fr, 2010. | Permalien | 9 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Nginx, Python (et Django), Wordpress

Après quelques vérifications, j’ai vu qu’effectivement, même si la configuration de mon Nginx indiquait qu’il fallait fournir le contenu en gzip, cette étape ne fonctionnait pas. J’ai fait d’autres recherches, qui m’ont permit de conclure que j’avais oublié d’inclure l’option gzip lors de la compilation de Nginx (oui parce que je l’ai compilé moi-même : la version proposée par mon OS étant à mon goût trop vieille – car désormais non supportée par Nginx…). Bref : a la compilation, j’ai oublié l’étape permettant à Nginx de prendre les fichiers, et de les convertir en gzip.

Cela dit, une bonne chose est que la version que j’ai installé permet, si on met dans la configuration d’un site la ligne :

gzip_static on;

…de vérifier à chaque envoi s’il existe une version gzippée du fichier, et si oui, de l’envoyer à la place du fichier demandé.

Sauf que : il me fallait désormais prendre les différents fichiers textes non gzippés. J’ai un instant crû qu’un tar -czvf suffirait, mais je me suis retrouvé avec des headers pas bons. En utilisant la commande gzip, j’ai obtenu des résultats bien meilleurs. Du coup, j’ai pris quelques minutes pour créer un script convertissant en gzip tous les fichiers CSS et JavaScript d’un dossier et de ses sous-dossiers :

#!/bin/bash

#User Variables

DIR1=/var/www/monsite1/;
DIR2=/var/www/monsite2/;

FIND=find;
GZIP=/bin/gzip;

for d in "$DIR1 $DIR2"
do
    for i in `$FIND $d -name "*.css" -o -name "*.js"`;
    do
                $GZIP -c $i > $i.gz;
    done;
done;

Notez plusieurs choses dans ce script :

On trouve l’intégralité des fichiers avec extension css ou js via la commande find :

find path/ -name "*.css" -o -name "*.js"

On les convertit en laissant l’original via la commande gzip customisée :

gzip -c style.css > style.css.gz

Voilà ! Normalement, cette technique permettra d’économiser encore un peu de bande passante. Après, mettez ce script dans une tâche CRON pour qu’elle s’exécute assez régulièrement (au cas où vous mettriez à jour des fichiers CSS). Et enfin, en ce qui concerne la compatibilité avec les différents navigateurs, j’ai testé sous Chrome 4, Firefox 4, Opera 10.50 et IE7 (out ça sur Windows XP), et ça fonctionnait sans problème. J’ai bien conscience que peut-être, il y a encore des personnes sous IE5 ou IE6, mais elles commencent sérieusement à m’énerver. Donc je ne vérifie pas pour ces configurations. POINT.

Edit : Pour ceux qui viendraient me dire qu’il y a toujours le mod_deflate de Apache, je leur répondrais que je suis au courant, mais que chez moi Apache ne traite pas les CSS et les JS, donc cette solution n’était pas envisageable ici.

AbriCoCotier.fr, 2010. | Permalien | 1 commentaire | Plugin Better Feed, par Ozh
Rangé dans : Nginx, Programmation, Serveur

Or, comme chacun sait, au fur et à mesure de l’utilisation de tel ou tel CMS (ex : WordPress, Dotclear, Joomla, etc), CRM (VtigerCRM) ou autre logiciel installé sur un serveur, on finit par rajouter des personnalisations ici et là, et bien sûr on ne se souvient jamais de l’intégralité de ce que l’on a fait.

Pour ma part, j’ai donc choisi de sauvegarder l’intégralité du dossier /var/www, même si c’est assez lourd en terme d’espace disque. A cela, j’ai ajouté les fichiers de configuration de chaque serveur fonctionnant sur le serveur (pour moi, Apache et Nginx).

Le script shell suivant fait en fait d’abord une copie des dossiers/fichiers à sauvegarder dans un répertoire temporaire (qu’il aura créé juste avant), puis les mets dans une archive gzipée. J’attire votre attention sur le fait que chez moi, avec un dossier /var/www de 740Mo (c’est pas tant que ça), le script a fait tourner le CPU à 100% pendant environ 8 minutes. Pendant ce temps là, les pages ont très bien été servies (j’ai fait le test), et d’après ce que je voyais sur htop, il y avait une gestion des processus permettant à Apache et Nginx de fonctionner correctement, laissant au script le reste du CPU disponible. Toutefois, les quelques observations que je note ici sont à prendre avec des pincettes, elles ne sont le fruit d’aucune étude sérieuse, c’est pourquoi je recommande de n’exécuter le script qu’au milieu de la nuit (entre 3h00 et 6h00), pour avoir un impact éventuel sur les performances aussi limité que possible. De même, il faut bien voir que la quantité de fichiers associés peut être assez importante, et la taille de l’archive également, donc si vous n’avez pas beaucoup d’espace disque sur votre serveur, évitez de multiplier les backups (pour ma part, je pense qu’une à deux fois par semaine me suffiront amplement).

Voilà le script shell :

#!/bin/bash

#User Variables
DATE=/bin/date;
NOW=`$DATE '+%Y-%m'-%d_04_30`;
NBBACKUP=4;
BACKUPDIR=/home/the_user/filesbackup;
BACKUPTEMPDIR=/home/the_user/filesbackup/tmp;

APACHECONFDIR=/etc/apache2;
NGINXCONFDIR=/etc/nginx;
WWWDIR=/var/www;

#Command Variables
RM=/bin/rm;
CP=/bin/cp;
MKDIR=/bin/mkdir;
MV=/bin/mv;
TAR=/bin/tar;
SCP=/bin/scp

$MKDIR $BACKUPTEMPDIR;
$CP -R $APACHECONFDIR $BACKUPTEMPDIR;
$CP -R $NGINXCONFDIR $BACKUPTEMPDIR;
$CP -R $WWWDIR $BACKUPTEMPDIR;
$TAR -czf $BACKUPDIR/files_backup.$NOW.0.tgz $BACKUPTEMPDIR/;
$RM -R $BACKUPTEMPDIR/

#$SCP -P 50000 $BACKUPDIR/*0.tgz user@ndd.com:/chemin

i=$(($NBBACKUP-1))
j=$NBBACKUP
$RM -f $BACKUPDIR/*$NBBACKUP.tgz
while [ $i -ge 0 ];
do
     for f in $BACKUPDIR/*.$i.tgz;
     do
         $MV $f ${f/.$i.tgz/.$j.tgz};
     done
     j=$(($j-1))
     i=$(($i-1))
done

Veuillez noter que celui-ci n’est pas optimisé pour le listing des opérations à réaliser. J’ai tenté le for i in chemin_1 chemin_2, mais l’interpréteur shell n’a pas voulu dans la mesure où il considérait les chemin comme des dossiers, et ne voulait apparemment pas boucler dessus.

Vers la fin, vous pourrez voir une ligne commentée, celle pour la commande scp, qui nécessite que vous ayez un serveur supplémentaire sous la main (ou un hébergement web) qui accepte les connexions scp.

Pour ce qui est de la sauvegarde d’un nombre défini de backups, je remercie Tym, c’est lui qui a donné la solution.

AbriCoCotier.fr, 2010. | Permalien | 6 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Nginx, Programmation, Serveur, Wordpress

En effet, une des choses qui me font peur est la différence de prise en charge des règles de rewrite d’URL par Nginx et Apache. Apache a un mod dédié à cela (mod_rewrite), et il a l’avantage d’être la configuration standard pour beaucoup d’applications web, ce qui permet de les prendre et de les utiliser sans rien connaitre à la technique derrière.

Le problème vient donc quand on souhaite faire fonctionner ces applications web sur Nginx tout seul alors qu’elles sont prévues (via leur .htaccess notamment) pour tourner sur Apache.

Une solution intermédiaire est celle, donc, de pousser au maximum le traitement des fichiers statiques par Nginx.

D’abord, on peut lui confier les fichiers ‘habituellement considérés comme statiques’…

location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|txt|srt|swf)$ {
root  /var/www/yoursite/;
access_log  /var/log/nginx/static-yoursite-access.log;
error_log   /var/log/nginx/static-yoursite-error.log;
expires           30d;
}

(tiré du post de PapyGeek)

… mais il faut faire très attention à cela, notamment si vous construisez/utilisez une application qui peut générer des fichiers (par exemple, des images) à la demande. Ainsi, si votre application prévoit de créer tel ou tel fichier au moment où il est appelé (par exemple, une application de création de captcha), là Nginx n’enverra pas la requète à Apache, alors qu’il faudrait. La solution est donc de laisser à Apache le traitement des requètes quand celles-ci occasion des erreurs 404 chez Nginx, ou plus exactement quand la ressource n’existe pas directement :

# si la ressource demandée existe, Nginx la retourne directement
if (-f $request_filename) {
break;
}

# toutes les autres requètes sont passées à Apache
if (!-e $request_filename) {
proxy_pass http://127.0.0.1:8080/;
include /etc/nginx/conf.d/proxy.conf;
}

Pour le reste, et pour que Nginx ne prenne que les requètes dont il existe un cache déjà créé, j’ai cherché et essayé plusieurs configurations, mais aucune de celles-ci ne fonctionnaient (pour être sûr que ça fonctionne, j’ai pris les URL des pages en cache, éteint Apache2, et restesté. MAlheureusement, ça ne fonctionnait jamais, et je n’avais que des erreurs 502 BAd GEtaway, ce qui signifie que Nginx me redirigeait sur Apache2, mais comme celui-ci était éteint, cela envoyait une 502 ; alors que bien évidemment, Nginx n’aurait pas dû avoir besoin de Apache2 pour traiter la requète.).

Sources :

• Documentation Nginx sur le HttpRewriteModule
• Un thread bien pratique sur le forum Slicehost.

AbriCoCotier.fr, 2010. | Permalien | 7 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Nginx, Programmation, Wordpress

Pour ceux qui demandent, je n’ai pas inventé tout seul la façon de mettre tout cela en place. J’ai tenté de suivre au mieux les conseils donnés par Papygeek pour installer Nginx. Je vous recommande son billet si vous souhaitez également tenter l’aventure.

Cette image n’a pas grand chose à voir avec l’article, mais je la trouvais très jolie, d’où son placement ici

• La mise en place fonctionnelle de Nginx en reverse proxy, devant Apache, a pris en tout et pour tout 1h30 (temps pour régler les divers problèmes compris), après lecture complète du billet. C’est donc 1h30 de tests et de résolutions de problèmes.
• L’erreur 502 Bad Gateway signifiait pour moi que Nginx transmettait bien les requêtes, mais Apache n’était pas correctement configuré pour les traiter.
• L’erreur 403 signifiait en gros que Nginx n’avait pas les droits pour renvoyer le fichier demandé, ou ne le trouvait pas (si le chemin vers les fichiers n’est pas correctement configuré dans le fichier de configuration par exemple) ou n’en était pas capable (par exemple si le fichier est un *.php et que Nginx n’est pas configuré pour le traiter, ça va lui poser problème).

Niveau temps de réponse.

J’attire l’attention sur le fait que les deux serveurs comparés n’ont pas du tout la même configuration, et que donc si comparaison il y a, elle est à prendre avec beaucoup de pincettes.

Édit : La configuration du serveur sur lequel est AbriCoCotier est la suivante : Athlon 3800+ (2 coeurs à 2ghz), 4Go de RAM. La configuration sur l’autre serveur est un AMD Opteron à 2,1Ghz (d’après cat /proc/cpuinfo ) et 2Go de RAM (d’après top ou free -m).

Sur le serveur où est AbriCoCotier, je n’ai qu’un Apache. Le temps de réponse d’une page d’accueil WordPress en cache (avec wp-super-cache) est le suivant :

• Pour le fichier HTML de la page : 216ms de latence.
• Pour le fichier CSS du thème : 84ms de latence.
• Pour la première image chargée : 181ms de latence.

Sur l’autre serveur, la configuration est un couple Nginx en reverse proxy, et Apache derrière. Le temps de réponse d’une page en cache également est le suivant :

• Pour le fichier HTML de la page : 412ms de latence.
• Pour le fichier CSS du thème : 153ms de latence.
• Pour la première image chargée : 75ms de latence.

Même si la deuxième page est plus légère que la première, et que donc, toute proportion gardée, j’aurais tendance à dire que ce test va dans le sens d’Apache, j’ai fait un second test, avec une page égale (la page de Readme.html de WordPress).

Pour le serveur d’AbriCoCotier, on a (j’ai pris le meilleur temps total sur 10 tests):

• Total : 264ms.
• readme.html : 58ms de latence, 113ms de download
• install.css : 85ms de latence, 1ms de download
• wordpress-logo.png : 78ms de latence, 14ms de download

Pour l’autre serveur, et sachant que le HTML a été traité par Apache, alors que le CSS et le PNG ont été traité par Nginx (pareil : j’ai pris le meilleur sur une dizaine de tests) :

• Total : 215ms.
• readme.html : 56ms de latence, 21ms de download
• install.css : 110ms de latence, 16ms de download
• wordpress-logo.png : 125ms de latence, 13ms de download

Donc là, le test tend à donner une légère avance à Nginx+Apache par rapport à Apache tout seul.

Mais je le répète : les deux serveurs ne sont pas matériellement comparables (celui sur lequel est AbriCoCotier doit être plus puissant), donc je ne sais pas vraiment ce que l’on peut conclure de ces tests.

Edit n°2 : au vu de ce que j’ai donné ci-dessus pour les performances « matérielles », il est compréhensible que l’Apache tienne correctement la route.

Cela dit, j’ai fait un test de la home pour chacun des sites (200 requêtes), et voilà ce que cela me donne :

Pour le premier serveur (avec abricocotier.fr dessus) :

coucou# ab -n 200 -c 5 http://www.abricocotier.fr/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking www.abricocotier.fr (be patient)
Completed 100 requests
Finished 200 requests

Server Software:        Apache
Server Hostname:        www.abricocotier.fr
Server Port:            80

Document Path:          /
Document Length:        47548 bytes

Concurrency Level:      5
Time taken for tests:   8.147451 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Total transferred:      9564400 bytes
HTML transferred:       9509600 bytes
Requests per second:    24.55 [#/sec] (mean)
Time per request:       203.686 [ms] (mean)
Time per request:       40.737 [ms] (mean, across all concurrent requests)
Transfer rate:          1146.37 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    1   1.1      1      10
Processing:    86  200  78.4    183     499
Waiting:       72  181  76.5    165     469
Total:         88  202  78.5    184     500

Percentage of the requests served within a certain time (ms)
  50%    184
  66%    226
  75%    253
  80%    266
  90%    318
  95%    351
  98%    396
  99%    410
 100%    500 (longest request)

Pour le deuxième serveur (appelons le deuxieme-serveur.fr ):

coucou:~# ab -n 200 -c 5 deuxieme-serveur.fr
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking deuxieme-serveur.fr (be patient)
Completed 100 requests
Finished 200 requests

Server Software:        nginx/0.5.33
Server Hostname:        deuxieme-serveur.fr
Server Port:            80

Document Path:          /
Document Length:        4813 bytes

Concurrency Level:      5
Time taken for tests:   3.885465 seconds
Complete requests:      200
Failed requests:        195
   (Connect: 0, Length: 195, Exceptions: 0)
Write errors:           0
Total transferred:      1031170 bytes
HTML transferred:       966500 bytes
Requests per second:    51.47 [#/sec] (mean)
Time per request:       97.137 [ms] (mean)
Time per request:       19.427 [ms] (mean, across all concurrent requests)
Transfer rate:          259.17 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   9.8      0      98
Processing:    10   95 266.8     55    1832
Waiting:        9   69 263.1     26    1797
Total:         10   96 274.9     55    1890

Percentage of the requests served within a certain time (ms)
  50%     55
  66%     59
  75%     62
  80%     64
  90%     71
  95%     79
  98%   1794
  99%   1832
 100%   1890 (longest request)

Au final, et si je lis correctement ce qui est retourné par le benchmark d’Apache, le serveur d’AbriCoCotier est capable de traiter 24 requêtes par secondes contre 51 pour celui avec Nginx+Apache.

Je ne suis pas certain que ce test soit correct, dans la mesure où je ne maitrise pas bien les outils abordés ici, mais je serais preneur d’un conseil ou de plusieurs si vous en avez.

Édit du 20 mai 2010 : Une chose qui peut être assez énervante, c’est de se faire « prendre » sa bande passante par d’autres sites, qui vont afficher sur leurs sites des images ou d’autres documents qui sont hébergés chez vous. Cela s’appelle le hotlinking (on parle d’image hotlinking).

Sur le site de Nginx, on trouve cela :
If you need to redirect referers from spefic site only, then you may use map:

http {

    map  $referer  $forbidden {

         hostnames;
         default           0;

         *.hotlink1.com    1;
         www.hotlink2.com/ 1;
         .hotlink3.com/    1;

         include   hotlink.conf;
    }

    server {

         set $referer "";
         if ($http_referer ~* '^<a href="http://%28[%5E/">http://([^:/</a>]+)') {
             set $referer $1;
         }

         location ...

         location ~* ^.+\.(jpg|jpeg|gif ... {

             if ($forbidden) {
                 rewrite  ^  <a href="http://.../;">http://...;</a>
             }

             root  ...
             ...
         }

hotlink.conf:

*.hotlink4.com    1;
www.hotlink5.com/ 1;
.hotlink6.com/    1;

[Image]

Edit du 20 juillet 2010 : Mise à jour de Nginx avec le configure suivant :

./configure –with-http_gzip_static_module –with-http_ssl_module –with-http_dav_module –with-http_sub_module

AbriCoCotier.fr, 2010. | Permalien | 11 commentaires | Plugin Better Feed, par Ozh
Rangé dans : Nginx, Programmation, Wordpress