Je confirme que Nginx est un excellent choix. Les performances sont excellentes et la configuration assez aisée.

Merci d’avance.

Je trouve Cherokee très interessant, surtout avec l’interface web d’administration.
Les benchs sont aussi en sa faveur.

John Smith : tu sembles très bien t’y connaître pour Cherokee : STP, pourrais-tu m’indiquer comment l’installer et le configurer efficacement sur un VPS (Xen, 256MB) Ubuntu server 9.10?
L’un des problèmes résidera en l’utilisation des .htaccess et des rewrite d’Apache : comment l’as-tu contourné?

Merci d’avance.

si vous voulez faire ce que Korben fait mais sans passer par l’intermédiaire de Nginx en ce qui concerne le contenu dynamique (donc aucune passerelle entre le visiteur et apache):

il vaut faut un serveur avec deux ip (ip fail over d’ovh par exemple)

ip1 : vous configurez votre DNS du www pour pointer dessus
ip2 : vous configurez votre DNS de images pour pointer dessus (ou bien static)

Dans la config apache vous mettez :

Listen ip1:80
NameVirtualHost ip1:80

DocumentRoot /www/
ServerName http://www.mondomaine.com

Puis, sous nginx (pas encore cherché) ou bien lighttpd (pas cherché non plus), il suffit de faire l’inverse en écoutant ip2:80.

Enfin, j’ai pas encore testé

Je n’avais jamais songé que je pouvais faire varier le traitement du port 80 sur un même serveur qui aurait deux ips.

Vu qu’OVH fourni des IP fail over, je suppose que c’est une solution efficace pour faire la même chose que propose Korben sans pour autant avoir d’intermédiaire…

Enfin, il me reste plus qu’à trouver comment

Hmmm WTF comme ils disent ? Je ne vois pas tellement le rapport entre :

La vulnérabilité d’Apache à un type de déni de service basé sur la manière dont Apache gère les fins de connexion, provoqué par des paquets forgés.

La manière dont Apache gère les fichiers statiques (en l’occurrence parfaitement)

Le fait que WordPress soit une usine à gaz mal foutue mettant régulièrement le serveur de Korbenichou à genoux parce que le très grand nombre de commentaires et de visites rend la mise en place d’un cache parfaitement caduque sur ce dernier.

Je te propose donc un truc : je monte un apache sur une machine de type Dedibox de base, pour lui faire servir des assets, et uniquement des assets. Et on lance un bench genre 10000 connexions par seconde sur ces ficihers statiques pendant quelques heures. Et on voit comment il tient.

En gros :

Ton Apache n’en a rien à foutre de servir du fichier statique, pas plus que ton nginx. Ton goulet d’étranglement se trouve au niveau de (cette merde de) WordPress et des plugins que tu utilises, donc du dynamique. Poser un Nginx en reverse proxy n’a d’intérêts que si
– tu as plusieurs serveurs applicatifs pour servir ton dynamique (exemple, nginx + des fastcgi servers pour ton WordPress auquel cas adieu Apache. C’est ce que j’ai mis sur mon infra.
– tu as plusieurs machines physiques ou virtuelles qui te servent le PHP / les assets.

En fait, je serais toi, je testerai nginx avec plusieurs worker, du PHP fastcgi, le wp-supercache posé sur du memcache histoire d’accélérer les i/o.

Mais ça ne résoudra pas le problème principal : WordPress et ses plugins à la con.

Sinon nginx intègre un cache (en proxy ou fastcgi via phpfpm par exemple) depuis la version 0.7.48:
=> http://wiki.nginx.org/NginxHttpProxyModule#proxy_cache

Ça marche plutôt bien.

Pour mon taff, j’ai utilisé Varnish, et j’ai vraiment été charmé, l’idée de pv faire des règles style: navigateur <> cache, backend <<>> cache, est juste génial, genre j’ai mi en place une politique de cache assez rapidement (en cache tout, si le cookie de session est seté, on pipe).

Pour finir, plutôt propre de réduire les threads prefork apache uniquement pour le php, pas si con que ca, et nginx délivre bien plus rapidement le static (jpeg, css, js, and co).

Le mode reverse de ngnix n’a pas toutes les possiblités de Squid.

Ngnix tient-il compte des headers cache-control ? Utilise-t-il un algo pour maintenir les objets hot en mémoire ? Etc .. etc … Squid le fait.

Varnish est sympa mais est très contraignant pour l’admin, puisqu’il doit se taper les règles et bien connaitre donc l’application. Ce qui est généralement du domaines des devs, mais comme c’est des quiches … Il est parfois préférable de leur prendre la tête avec les headers cache-control et les laisser gérer la cache … Varnish est jeune mais il est certain qu’un jour, il sera bien supérieur à Squid.

Bref, ici on ne parle pas de proxy mais d’un vieux proxy-pass à la apache pour balancer trois images. Rien d’extraordinaire et certainement pas la configuration ultime pour la performance, bien au contraire.

Pour faire de bô schémas (réseau ou autre), on peux aller sur http://my.lovelycharts.com/ on se fait un compte gratos et c’est bon.

Schémas exportables en PNG (ou JPG si on ne veut pas de transparence). Je précise juste qu’en compte free, on à le droit qu’à un seul schéma sauvegardé (zut !).

Dans le même genre, il y à Gliffy : http://www.gliffy.com/ mais je n’ai pas test.

Après en PHP, Apache sera surement un peu meilleur qu’NGINX avec un nombre élevé de connexions (et encore), mais quand on voit les ressources qu’il consomme, il y a de quoi flipper.
Puis Korben.info, c’est beaucoup de statique puisque des fichiers .html sont générés par WP-Super Cache. (d’ailleurs je trouve que W3 Total Cache est mieux )
Donc mieux vaut les servir également avec nginx, ainsi que le css, les images du thème et le js.

L’intérêt d’un reverse proxy est également de bien mieux contrôler le trafic qui arrive et de protéger le serveur backend (à condition d’avoir un autre serveur) en cas de DOS ou autre (nginx encaisse à max)

Enfin bon, je pense pas pouvoir convaincre les inconditionnels d’Apache…C’est un peu une peine perdu :/

Apache en worker avec PHP sera toujours plus lent que le prefork avec PHP en module (pour le commentaire qui en parle). Bench à l’appui.

Si tu veux du proxy, prends un vrai proxy comme Squid ou Varnish, là tu auras plus de performances pour tes fichiers statiques. Mais bon, des apache qui crache 20x plus de page que ton site ça existe (j’en ai) pas besoin de kikouloler avec Nginx.

Et utilise un opcode, ça sera déjà mieux si c’est pas déjà le cas.

Dans l’exemple de Korben, t’as juste a ajouter tes domaines à la suite :
server_name korben.info tondomaine1.com tondomaine2.net;
Il pointeront tous vers ton serveur HTTPD qui se trouve derrière nginx et qui se chargera des vHosts

@Henry cow: Le mieux pour booster une vielle dedibox serait de mettre Apache au placard, et d’opter pour un « vrai » serveur HTTPd (cherokee ou nginx sont très performants en php-cgi) et tu verra qu’un httpd qui consomme 100+ Mo de RAM n’est pas normal (contrairement à ce à quoi Apache nous a habitué)

Est il possible de faire ce type de config avec un dédié comportant plusieurs domaines ?
La le proxy pointe direct vers 10.0.0.1:8080 donc en gros la racine du serveur niveau http

Aurais tu des solutions pour améliorer la bande passante?