Entrez vos identifiants

x
OU
Vous avez oublié votre mot de passe ?
Utilisateur wiki : vous n'aviez pas d'email ?

Korben - Site d'actualité geek et tech

Go Top

Mettre en place un Reverse Proxy Nginx sur son serveur

A cause (ou grâce) au petit concours que j'ai lancé pour gagner le Nokia N900, vous êtes trèèèèèèès nombreux à être sur le site, à laisser un commentaire puis après aller vous ballader sur mes autres articles. C'est bien (yeah!) sauf que du coup l'Apache qui fait tourner le site a eu un peu de mal à gérer l'affluence.

J'ai donc du mettre en place un petit serveur Nginx pour faire office de Reverse Proxy afin d'alleger le tout. Je ne me prétend pas expert en nginx mais je vais tenter de vous expliquer avec mes mots (c'est à dire simplement) comment mettre ça en place chez vous.

Mais avant ça, petit cours de comment fonctionne un serveur http classique type Apache !

Lorsque vous arrivez avec votre petit navigateur sur Korben.info (qui tourne sous wordpress), voici ce qui se passe :

  • Votre ordinateur envoie une demande de connexion au serveur Apache
  • Votre navigateur peut alors se connecter au serveur Apache
  • Apache crée alors un nouveau process pour gérer votre demande
  • Si c'est du contenu statique que vous demandez (genre une image), Apache va la chercher et vous l'envoie (facile)
  • Mais si c'est du contenu dynamique (genre page en PHP), Apache la demande et doit attendre que PHP (souvent en appelant un petit coup MySQL dans la foulée) ai fini de générer cette page pour vous la renvoyer.
  • Votre navigateur reçoit alors le fichier demandé, il ferme la connexion avec l'Apache et vous affiche le contenu demandé

Great !

Sauf que ce qu'on ne vous dit pas, c'est qu'en cas de nombreuses demandes, votre Apache il souffre sa race ! En effet, il peut en quelques minutes bouffer toute la mémoire de votre serveur et faire tourner le CPU à plus de 100 % ! Pas cool ! Une des solutions consisterait donc à acheter un plus gros serveur mais avant de sortir le chéquier, il est possible de l'optimiser encore un petit peu.

On peut en effet confier la distribution des fichiers statiques à un serveur comme Nginx qui a l'avantage d'être très rapide pour exécuter cette tâche. La mémoire vive consommée par Nginx est très réduite, ce qui permet de le charger un peu sans exploser la mémoire. Ayant déjà une architecture Apache en place, je ne voulais pas passer ma nuit à tout migrer sur Nginx en tant que serveur web (et surtout ne pas me prendre la tête avec les reécriture d'URL qui se gère un peu différemment sous Nginx). J'ai donc décider de l'utiliser comme un Reverse Proxy. C'est à dire de faire tourner l'Apache (avec le blog et tout et tout) sur un autre port uniquement en local sur mon serveur et de demander à Nginx de s'occuper de la distribution de contenu pour vous mes fidèles visiteurs :-)

Au niveau du contenu statique, j'ai un sous domaine korben.info qui diffuse uniquement les images du site. J'ai donc choisi de faire distribuer ces fichiers directement par le Nginx plutôt que par Apache. Autre avantages de Nginx, c'est qu'il gère le loadbalancing, ce qui sera pratique quand je commencerai à faire plus de trafic que Facebook... (ouais j'y crois !!!)

Voici au final à quoi ressemble la config que j'ai mis en place :

Z'avez vu ? Je fais des beaux schémas ! C'est grâce à Pencil qui est sorti en 1.1 RC1 (ça c'était la news dans la news !!)

Bref, trêve de blabla, si vous êtes chaud, on attaque !

Avant tout, vous allez stopper votre Apache (sudo /etc/init.d/apache2 stop). Puis on va installer Nginx

sudo apt-get install nginx

Ensuite, on va éditer le fichier /etc/nginx/nginx.conf
Voici ce que j'ai mis dans le mien :


user www-data;
worker_processes  2;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    access_log  /var/log/nginx/access.log;
    server_names_hash_bucket_size 64;
    sendfile        on;
    tcp_nopush     on;
    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;
    gzip  on;
    gzip_comp_level   5;
    gzip_http_version 1.0;
    gzip_min_length   0;
    gzip_types        text/plain text/html text/css image/x-icon  application/x-javascript;
    gzip_vary         on;
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

worker_processes à 2, c'est pour indiquer le nombre d'instance de Nginx que je souhaite lancer pour traiter tout ce business... J'ai mis à 2 pour voir et je réduirai / augmenterai après mes tests.
worker_connections à 1024, cela veut dire que chaque process est capable d'encaisse 1024 connexions simultannées (pas visiteurs hein, connexions !). Pour le reste, je vous invite à lire la doc mais globalement, j'ai activé la compression gzip pour que ça booste encore un peu plus et j'ai laissé le timeout à 65 secondes.

A la fin, vous pouvez voir que j'apelle tous les .conf dans /conf.d/ et tous les /sites-enabled/
On va donc aller éditer ces fichiers.
Commençons par /conf.d/proxy.conf. Voici ce qu'il faut mettre dedans pour qu'il fonctionne comme un proxy. Idem pour la doc si vous voulez en savoir plus sur les paramètres mais globalement, vous pouvez régler ici les tailles de buffers pour gérer les entêtes et corps envoyés par les clients afin de pouvoir par exemple récuperer des gros cookies ou ce genre de choses (de ce que j'ai pu comprendre).


proxy_redirect          off;
proxy_set_header        Host            $host;
proxy_set_header        X-Real-IP       $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size    10m;
client_body_buffer_size 128k;
client_header_buffer_size 64k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffer_size   16k;
proxy_buffers       32   16k;
proxy_busy_buffers_size 64k;

Et pour finir, dans site-enabled, un peu comme dans la config Apache, j'ai édité le fichier default dans lequel j'ai mis les choses suivantes (mes commentaires sont dans le code ci-dessous) :


#PREMIERE CONFIG : Ici je dit que sur le port 80, pour le domaine
#korben.info, nginx va chercher les pages en local (127.0.0.1)
#sur l'Apache qui est configuré en port 8080
server {
        listen   80;
        server_name  korben.info;
        access_log  /var/log/korben.access.log;
        error_log  /var/log/korben.nginx_error.log debug;
        location / {
                proxy_pass         http://127.0.0.1:8080/;
        }
#Et je rajoute PHPMYADMIN dans la foulée
        location /phpmyadmin {
                proxy_pass         http://127.0.0.1:8080/phpmyadmin;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
                root   /var/www/nginx-default;
        }

}
#SECONDE CONFIG : Ici je dit que sur le port 80, tout ce qui est
#pour le domaine korben.info doit être envoyé directement
#par le Nginx et se trouve dans le repertoire /var/www/monsite/wp-content/uploads/
server {
listen   80;
server_name  korben.info;
location = /50x.html {
root /var/www/nginx-default;
 }
 access_log /var/log/pictures.nginx.access.log;
 error_log /var/log/picture.nginx.error.log;
index index.html;
location / {
     expires     max;
     root  /var/www/monsite/wp-content/uploads/;
        }
}

Ayé, on a fait le plus dur. Maintenant, on va configurer l'Apache pour qu'il cause sur le port 8080 uniquement. Voici ce que j'ai mis dans le fichier /etc/apache2/ports.conf

NameVirtualHost *
Listen 127.0.0.1:8080

Et dans mes site-enabled Apache, j'ai bien mis en début de fichier afin d'indiquer une nouvelle fois (on n'est jamais trop prudent) que tout se passe sur le port 8080.
Dernière petite chose. Pour que l'Apache logue correctement les IPs qui se connectent à votre serveur, il faut installer le module suivant :

sudo apt-get install libapache2-mod-rpaf

Et voilà ! Il ne reste plus qu'à démarrer l'Apache sur son nouveau port, et le Nginx sur le port 80.

  • sudo /etc/init.d/apache2 start
  • sudo /etc/init.d/nginx restart (ou reload ou start)

Allez ensuite sur votre site et si ça ne fonctionne pas c'est que vous vous êtes planté quelque part dans la config. En cas d'abandon de votre part, il suffit tout simplement de shooter le nginx et de remettre l'Apache sur le port 80 et ça sera reparti comme en 40 ! :-) Si vous souhaitez apporter des corrections / précisions à ce petit tuto, n'hésitez pas !

A vous la toute puissance de l'internet rapide, le succès avec les femmes et un meilleurs référencement (oui car Google tient compte maintenant du critère de vitesse dans le référencement des sites)

Love !


Facebook Twitter Email Copier Url

75 Responses to “Mettre en place un Reverse Proxy Nginx sur son serveur”

  1. Hei Lian dit :

    “Mais si c’est du contenu statique”, a priori c’est dynamique qu’il faudrait marquer là ^^

    Bonne fête sinon :p

  2. raph dit :

    le schéma ma fait trop rire!

  3. Korben dit :

    @Hei Lian: oups, boulette ! merci

  4. Avish dit :

    Sympa le schéma de la mort qui tue.

    Au premier coup d’œil les performances, sont très proche de lighttpd :D (voir un poil mieux).

  5. Merci pour ce tuto extrêmement intéressant. Peux-tu expliquer le choix de Nginx par rapport à un lighttpd, par exemple ? Facilité de configuration ? Meilleures perfs ?

  6. Korben dit :

    @gordontesos: C’est ce que tout le monde m’a recommandé. Après je ne sais pas si lighttpd est plus efficace que nginx. Faudrait faire ou trouver des benchmark.

    Par contre, j’ai trouvé ça http://www.wikivs.com/wiki/Lighttpd_vs_nginx

    a+

  7. Aldarone dit :

    C’est clair comme explications et ça va me servir très bientôt (mon apache ayant quelques soucis avec certains proxy qui ne ferment jamais leurs connexions et en ouvrent une cinquantaine par seconde…)

    Par contre, tu as une idée de la config à utiliser dans le cas où on utilise des virtual hosts avec apache ?

  8. Foxrider dit :

    Pas mal du tout ces infos sur nginx. Je connaissais pas mais je met de côté, ca servira surement un jour ou l’autre !

    Et je vais aussi aller jeter un oeil sur pencil ^^ Ca me parait bien prometteur !

  9. Korben dit :

    @Aldarone: euh oui. J’utilise les virtualhost avec apache. T’as rien a changé dans la config apache à part le port.

  10. Aldarone dit :

    Impeccable ! Dans ce cas je pense qu’avant la nouvelle année j’aurai mon petit nginx aussi :)

  11. KetA dit :

    Une idée de la façon dont on déplace les uploads d’images de wordpress vers un sous-domaine ?

  12. Marabok dit :

    “En effet, il peut en quelques minutes bouffer toute la mémoire de votre serveur et faire tourner le CPU à plus de 100 % !”

    Faire tourner un CPU à + de 100% c’est possible ça ? =o)
    (non on parle pas d’overclocking :-)

  13. Korben dit :

    @Marabok: euh, ce qui est sûr c’est que quand je fais mon sudo top et que le serveur par en vrille, j’ai déjà eu des trucs genre 120% , 150% ! Donc c’est possible au niveau soft… après le cpu je ne crois pas non ;-)

  14. Korben dit :

    @KetA: avec une petite regle de reecriture

    RewriteRule ^/wp-content/uploads/(.+)$ http://pictures.korben.info/$1 [R=301,L]
  15. Cricket dit :

    Un ptit coup de WP-SuperCache peut faire du bien aussi, si tu ne l’as pas installé :)
    http://wordpress.org/extend/plugins/wp-super-cache/

  16. Korben dit :

    @Cricket: si j’ai super cache aussi … Et sinon, memcached peut aussi s’interfacer avec tout ce basar… Mais faut voir si trop de cache ne ralenti pas le systeme. A tester

  17. Lazarius dit :

    Pas mal du tout comme système, je vais penser à tester ça sur mon serveur apres les fêtes surement ;)

    Merci pour le schéma explicatif qui réveille ^^

  18. Anis dit :

    Aller hop, dans mes signets !
    Merci, ça pourra servir :)

  19. if is Dead dit :

    Et si on sert plus de contenu dynamique que statique, ça va pas ralentir le tout ?

    Parce que bon, ça rajoute une passerelle inutile entre apache et le visiteur tout ça.

    Passer les images sur le port 8080 n’est il pas plus intéressant ?

  20. Gusix dit :

    je pense que tu aurai pu tenter de remplacer ton apache par un lighttpd moins gourmand en ressources. Mais je met de coté. Merci

  21. faire tourner le CPU à plus de 100 % ! Pas cool !
    En effet !

    Pour ça, c’est vrai qu’on est les méchants :-)

  22. Sinon tu pouvais aussi configurer Apache en mpm worker (le comportement que tu décris c’est celui du mpm prefork), avec PHP en FastCGI, pour obtenir le même niveau de performance (voire mieux car sans intermédiaire), sans rien à changer sur ton site :)

  23. Guillaume dit :

    Mettre phpmyadmin en direct sur internet tu n’as pas trop peur ?
    en plus bien l’expliquer dans ta conf c’est un poil dangeureux pour moi

  24. Dju dit :

    sympa ce p’ti tuto, merci pour l’explication je me demandais comment t’avais mis tout ça en place.
    et btw, j’adoore tes schemas, ils ont le mérites d’être clairs, tout en me filant mal aux côtes :p

  25. iMeee dit :

    Ah NGinx … :) Moi j’utilise directement NGinx. C’est un très bon serveur web, stable, performant, etc … Il a toutes les qualités ! Deplus il fait reverse proxy, proxy mail (imap/pop etc …) et pleins d’autre choses. Pour le worker_processes c’est le nombre de processus, sa doit être égal aux nombre de CPU visible par ton OS. Sinon oui MemCached améliorerais bien les performances tout comme APC, eAccelerator, etc … (cache d’opcode). Et il y a des extensions WordPress toutes prêtes pour sa qui fonctionnent nickel !

  26. trobert94 dit :

    Tiens justement Korben, je voulais savoir si tu avais fait quelque chose pour rendre wordpress un peu plus rapide, parce que c’est quand même assez lourd comme truc.

    T’as rajouté / modifié des trucs pour que ça aille plus vite ou c’est juste le serveur qu’est bon ? :)

  27. Obidoub dit :

    Ben alors on te paye un serveur à 1700€ et c’est pas suffisant??

  28. j’ai codé que dans de l’embarqué et dans les couches basses mais je trouve dingue qu’un process soit créé à chaque requète !

    Je comprends que c’est plus efficace si quelqu’un envoie plusieurs requètes d’affilé mais pourquoi ne pas instaurer un contexte de session (utilisateur, adresse IP, port,…) dans un cache et rechercher dans ce cache lorsqu’une nouvelle requète se présente) ?

    bon je dis ça j’ai réfléchis 3 secondes et j’ai jamais codé sur des hosts dans un système d’exploitation public et probablement que faire comme ça créerait des dépendances, mais puisque ton serveur ne fait que ça ça ne serait pas forcément génant (?).

  29. Miroir dit :

    Ah ouais mais c’est d’ la triche, c’est pas d’ l’hébergement mutualisé :-)

    Et moi avec mes pages web où j’ai même pas le droit à du PHP ! XD LOL

  30. kasi dit :

    Alors au final quel est l’ordre d’idée de gain de performance vu le commentaire : “Apache limite il s’enmerde” :) ?

  31. titux77 dit :

    Si y a plusieurs CPU, l’utilisation CPU pourra être supérieur à 100% (c’est le total de l’utilisation de tout les CPU).
    Il vaut mieux regarder le load average pour savoir dans quel état est le serveur de ce coté, en gros ça permet de savoir si les ressources CPU commencent à être trop insuffisantes pour traiter la demande.

    Ca aurait été pas mal d’avoir un comparatif nginx avec HAProxy et Squid pour cette utilisation de Reverse Proxy.

  32. MSTRLO dit :

    Rien compris sauf le schéma ! <3 Schéma

  33. foo dit :

    Pourquoi mettre la version 0.6.32?

  34. iMeee dit :

    @foo:

    Généralement sur un serveur en production on met une version stable …

  35. Dju dit :

    p’tain il est rapide google, chez toi.
    je tape “nginx” dans google, et ton site est deka

  36. Dju dit :

    *deja la*

    et testé avec du proxy et du php, ca marche plutôt bien et consomme effectivement bien moins qu’apache…
    que du bon :)

  37. Jérôme dit :

    Pas mal le schéma :-)
    tant qu’à continuer l’optimisation, 93 requêtes sont effectuées pour afficher cette page dont 10 + 1 sharethis pour les CSS et 12 + 1 sharethis pour le JS, en fusionnant les 10 CSS dans un seul fichier et de même pour le JS, tu économises 20 requêtes soit 20%.
    Une utilisation des sprites CSS pour les 6 petites images du header ( http://css-tricks.com/css-sprites/ ) économiserait 5 requêtes.
    Et pour finir, passer tout ça sous le sous-domaine pictures.* (délivré par NginX) et enlever le reverse proxy puisqu’il ne reste plus que le contenu dynamique délivré par Apache.

    That is just my 2 cents :-)

  38. John Smith dit :

    Finalement on se décide à utiliser nginx :)
    Il était temps !
    Et Jérome à raison, il y a grand intérêt à servir tout ce qui est statique par nginx directement (images du blog, js, css…etc)

    Bon, prochaine étape : virer Apache pour de bon et passer à du 100% NGINX + PHP-FPM.
    Regarde aussi du côté de cherokee pour le contenu dynamique qui assure à mort.
    http://www.cherokee-project.com/

  39. Alkpone dit :

    Pourquoi pas lighttpd qui gere php avec fast-cgi ?

  40. Dju dit :

    @Alkpone: meme si LightHttpd est plus léger qu’apache, il a pas mal de memory leaks. du coup il faut le redemarrer systematiquement au bout d’un certain temps… :(

    @John Smith: php-fpm est il mieux que php-fastcgi ?
    car apres avoir testé nginx+php-fcgi, à utilisation égale, apache est plus gourmand.

    Mais étant plus léger, il a aussi pas mal de fonctions en moins par rapport à apache. Donc un remplacement total est difficilement envisageable avec un blog/php type wordpress/dotclear qui fait de l’url-rewriting conditionnel etc…
    Par contre en tant que reverse-proxy frontal devant apache, ca roxe bien :)

  41. John Smith dit :

    @Dju: PHP-FPM est juste une sorte de patch pour PHP-FCGI..et oui, c’est beaucoup plus efficace d’utiliser PHP-FPM couplé à NGINX plutôt que NGINX et le spawn fcgi de lighty (truc habituel connu des utilisateurs d’nginx).

    Perso, ce que j’utilise c’est cherokee + fcgi et nginx en reverse proxy qui sert également le contenu statique.
    Cherokee est extrêmement puissant et les possibilités sont presque infinies, il est aussi très léger, et très très configurable.
    La configuration peut se faire à partir d’un interface d’administration, et il y a des règles pré-configurés pour wordpress, et tout les CMS connus.

    Cherokee vaut largement NGINX à mon avis quand il sagit de PHP.
    Par contre il est inférieur pour ce qui est statique :)

    A+

  42. PapyGeek dit :

    @Korben: sinon je donne un ptit tuyau comme ça : comme Nginx est super fort pour servir les fichiers statiques, et comme wp-supercache génère des fichiers html (statiques donc), pourquoi ne pas les servir directement avec nginx ?

    C’est ce que je fais sur papygeek.com, et ça gère.

    Pour ceux que ça intéresse, j’avais aussi parlé d’nginx il y a quelques temps ici : http://www.papygeek.com/software/optimiser-son-serveur-web-avec-nginx/

    Je referais peut-être un petit article pour expliquer ma conf de maintenant.

  43. Eno dit :

    Pour ceux qui veulent vraiment optimiser leur site, je vous conseil de regarder Varnish ;)

  44. Maxence dit :

    @if is Dead utiliser un port différents que le 80 pour le web n’est pas une bonne idée, car souvent dans les grosse boite si par chance le port 80 est ouvert c’est malheureusement tout ce qui y a avec le port 25

    Sinon pour éviter cette passerelle comme tu dis, si korben à au moins 2 ip sur sa machine, il peut très bien utiliser picture.korben.info avec une autre ip (celle qu’nginx écoutera) que celle de http://www.korben.info et tous ça sur le port 80

    Pour ma part j’utilise apache pour php et lighttpd pour les images,scripts et autre fichier qui changent très rarement et aussi pour faire du pseudo streaming vidéo, pratique pour proposer à ses visiteur du streaming vidéo à bas cout quand on héberge ses propres vidéos. (mais je crois qu’apache dispose d’un module pour ça maintenant)

  45. foo dit :

    @iMeee: la 0.6.39 est stable ainsi que la 0.7.64

  46. John Smith dit :

    @foo: Comme tu peux le voir dans le post de Korben, il a choisi de ne pas compiler NGINX par la source, et a décidé de l’installer par les packages debian/ubuntu (je sais pas quelle distrib il a) où la version stable est la 0.6.32.
    La 0.7.64 est “unstable” dans les packages ;)

  47. laurentgina dit :

    Très bon article Korben,

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

  48. Eno dit :

    @laurentgina:
    – Optimiser ton code
    – Optimiser les images
    – Striper les infos dans les images
    – Utiliser la compression pour le transfert ( gzip ect … )

  49. glop78 dit :

    Hello :)

    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

  50. Henry cow dit :

    Ceux qui ont testé, ça peut booster une vieille Dédibox ce proxy?

  51. John Smith dit :

    @glop78: oui, pas besoin de toucher aux virtuals hosts d’Apache (ou de n’importe quel autre HTTPD)

    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é)

  52. Korben dit :

    Merci pour vos conseils supplémentaires les gars !! Je vais lire tout ça au calme

  53. DjinnS dit :

    Tu devrais déjà configurer Apache correctement, PHP correctement et MySQL correctement avant d’aller raconter des conneries.

    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.

  54. John Smith dit :

    @DjinnS: t’es marrant toi.
    Pour ce qui est des proxy, Squid est pourri…
    Varnish est pas mal avec son système de cache “intelligent” mais par contre pour les fichiers statiques, il est infiniment mieux d’utiliser nginx (qui est le moyen le plus rapide de les servir connu par l’Homme).
    Voir aussi nCache : http://code.google.com/p/ncache/ qui est l’équivalent de Squid/Varnish basé sur le code du serveur russe :P

    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 :/

  55. Eno dit :

    Apache est bien il faut juste le tuner et avoir un loadbalancer / reverse proxy devant et un serveur pour le contenu statique ;)

  56. Alain Ternaute dit :

    Bonjour.

    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.

  57. DjinnS dit :

    Je dois être marrant, sans doute, mais tu devrais toi aussi apprendre à configurer Squid avant de cracher dessus. T’être même regarder un coup du coté des headers HTTP, t’être, non ? Squid peut cracher 2K pages/secondes, sans forcer. C’est sur, c’est pourri …

    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.

  58. foliop dit :

    @John Smith: Justement c’est ce que j’ai fait mais ca pointe directement à la racine du serveur

  59. arteta dit :

    @DjinnS:
    Plutôt d’accord avec toi, sauf sur le ton utilisé :)

    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).

  60. Hmmm je vais faire mon chieur, comme d’hab, mais je ne vois pas tellement à quoi ça sert…

    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.

  61. Eno dit :

    @Frédéric de Villamil: Y’a aussi le fait que Apache est très vulnérable aux attaques de type DoS et gère très mal un haut trafic si il est tout seul.
    Donc bon c’est pas vraiment inutile.

  62. Merci pour ce tutorial, je cherchais justement des infos sur nginx car j’ai aussi mon pauvre serveur qui chauffe.

  63. @Eno:

    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.

  64. if is Dead dit :

    @Maxence: Merci beaucoup pour ta réponse :D

    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 :)

  65. if is Dead dit :

    Je m’auto réponds au cas où ça intéresse quelqu’un:

    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é :D

  66. Toto dit :

    Bonjour.

    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.

  67. Toto dit :

    @John Smith: Un tuto détaillé sur Cherokee serait le bienvenu.

    Merci d’avance.

  68. Bonjour,

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

La menace des failles 0-Day

capture-vjhj

"En avril 2014, les chercheurs en sécurité de Google sont tombé sur une vulnérabilité présente à l’intérieur de la bibliothèque cryptographique OpenSSL. Petit problème, OpenSSL est utilisé sur les 2/3 des sites web qui utilisent HTTPS mais aussi par les téléphones Android. Heartbleed était né."

Si comme moi vous êtes un passionné de sécurité informatique et que vous vous demandez qu'est-ce qu'un truc comme Heartbleed peut causer comme dommages, la lecture de cet article sur les failles 0-Day est pour vous...et je vous rassure je ne parle pas du dernier film Blackhat récemment vu au ciné ;)

Lire la suite

Vous avez aimé cet article ? Alors partagez-le avec vos amis en cliquant sur les boutons ci-dessous :

Twitter Facebook Google Plus Linkedin email
Rejoignez les 55278 korbenautes
et réveillez le bidouilleur qui est en vous
abonnez-vous en savoir plus
"Vous aimez bidouiller ?" Oui j'adore l'informatique et la technologie
Suivez Korben Un jour ça vous sauvera la vie.. Ou celle d'un(e) ami(e)
  • Rejoignez les 55277 bidouilleurs de la grande famille des Korbenautes
    «Je considère que votre email est aussi important que le mien.»
    Korben
  • Univers Populaires

  • Site hébergé par
    Agarik Sponsor Korben
  • Vidéos

  • DANS TON CHAT (BASHFR)

    Silverwolf : ... mais dis moi, tu le quitte ton ordi des fois ? Mais à d'autres moments que pour manger, dormir et les toilettes ?
    Iluvatar : tu crois que je quitte le pc pr manger ?
    Silverwolf : ...

    -- http://danstonchat.com/3691.html
  • Themes

  • Une astuce pour rendre

    Windows 10 plus rapide

    Si vous trouvez que Windows 10 est un peu lent, que vos applications ne se lancent pas très vite, que vos compilations prennent du temps, voici une petite astuce débusquée par Brominou pour accélérer le bouzin. Cliquez dans la zone de recherche de la barre Windows et tapez le mot clé...lire la suite

    Cryptool pour s'initier à la cryptographie

    Alors attention, ce n'est pas nouveau, mais je me suis dit que ce serait intéressant de vous en parler si vous ne connaissez pas encore. Cryptool est un logiciel open source éducatif qui va vous permettre de comprendre les principes de base de la cryptographie. Dans sa version 2, Cryptool intègre...lire la suite

    En ce moment dans l'univers "Windows"

    Voir tous les articles »