noApache
Bon. C’est la rentrée demain, et je n’ai absolument pas envie de dormir. Alors plutôt que de faire quelque-chose d’utile, je vais venir raconter mes douces pensées sur le monde des serveurs web.
L’autre jour, je discutais avec des copains de la mise en prod d’un site Django avec Gunicorn+Nginx. La question qui a été posée, c’est « pourquoi Nginx et pas Lighttpd ? », et la seule réponse que j’ai pu trouver c’est « Bah, le seul intérêt de Lighttpd c’est de ne pas être Apache, et Nginx lui a volé la vedette ».
Ce qui souligne un élément que vous avez sans doute déjà remarqué : on s’acharne à faire la peau à Apache. Pourquoi diable ? Il paraît qu’Apache est lourd et possède plein de fonctionnalités inutiles qui le rende ultra-lent. Ah. Bon voyons voir ce que donne un “ab -n 1000 -c 100 http://monurl/jquery.js” entre 2 serveurs hébergés chez OVH (100Mbps, donc) :
- Apache: 131 requêtes/s, 0.8s/requête
- Nginx: 132 requêtes/s, 0.8s/requête
OH MON DIEU, Nginx traite 1 requête de plus par seconde ! Mais dites donc, c’est fulgurant ! Vous n’allez quand même pas me dire que les gains de performances se jouent sur des microsecondes complètement masquées par la latence du réseau ? Non, impossible !
Les lecteurs assidu se rendront compte à ce point que je suis en train de les arnaquer. En effet, je parlais de mise en prod de Django, et je leur ai servi du benchmark sur du fichier statique. Je dois avouer avoir largement la flemme de faire le benchmark sur du Django. Et pour cause : pour une page à la con, sur mon serveur j’ai besoin d’environ 150ms pour générer la page. Ajoutez à cela que, sauf grosse erreur de ma part, Django est mono-thread, vous imaginez bien que le demi poil de cul d’avance de Nginx ne va pas réussir à faire grand chose.
J’entends quelqu’un au fond me crier « Et la RAM ? », mais lui il va retourner dans son coin parce que certes en gros Nginx prends 2x moins de RAM qu’Apache sur mon installation, mais on parle de ~5Mo VS ~10Mo de RAM, contre les 256Mo que demande WordPress pour fonctionner, je pense qu’on est large.
Donc, si comme moi vous n’êtes pas Facebook, à priori que ce soit Apache ou Nginx, au niveau des performances vous n’allez pas voir la différence. Alors comment choisir l’un ou l’autre ? D’après moi, il y a plusieurs éléments à prendre en compte, le premier étant la constatation suivante : on pourrait prendre le code d’Apache, l’encadrer, et le vénérer jusqu’à la fin des temps tellement c’est bien écrit. Je ne déconne pas, Apache est super bien écrit. Et je vais même aller plus loin : c’est du code C, certes, mais c’est du code C lisible. Ils font très, très fort. Sans oublier la librairie APR dont je vous ai déjà parlé, qui est en grande partie à l’origine de ce miracle.
Une autre raison c’est qu’Apache, c’est du béton armé. En dehors de certaines failles amusantes comme celle qui tourne en ce moment, ce serveur est testé et éprouvé comme peu de logiciels sur cette planète. Inutile de rappeler qu’il y a peu c’était 90% des sites web servi par Apache, et qu’encore aujourd’hui on doit être dans les 60%. Quelqu’un arrive à imaginer ? 60% du web servi par Apache ! En plus de la preuve de viabilité technique (ndlr: les parts de marché de IIS ne prouvent que la viabilité technique des commerciaux de Microsoft), c’est aussi l’assurance que le projet ne sera jamais abandonné, et qu’on peut compter dessus sur le long terme.
J’aimerais aussi pointer du doigt un reproche qu’on fait à Apache : il est trop complet. Attendez une seconde. Trop complet ? Si on met de côté les soit-disant problèmes de performance, ça veut dire que quoi que je veuille faire, Apache pourra le faire. Une fois qu’ils sont performant, les autres serveurs web n’ont qu’un but dans la vie : être aussi puissant qu’Apache. D’ailleurs, les outsiders se prenant trop au jeux pourraient bien finir dans un était « pire » que leur concurrent…
Et pour finir ma petite liste d’arguments, je tiens à faire remarque que tous les administrateurs système Unix connaissent Apache. C’est obligé, sinon c’est qu’ils viennent d’une autre planète. Ce qui veut dire que quand je monte un projet sous Apache, je sais que si j’ai besoin que quelqu’un d’autre travaille dessus, que ce soit à cause de l’agrandissement de l’équipe, la reprise du projet, ou même pour une urgence, il n’y aura pas le moindre souci.
Bon, et en plus je tiens à préciser que je trouve la configuration de Nginx complètement dégueulasse, pour en avoir mis un en prod sur ce serveur même. Sans oublier la doc à moitié en russe… Qui a été traduite depuis, mais avouez que l’anglais comme « langue par défaut » c’est plus pratique quand même.
Finalement, de nos jours pour un projet petit ou moyen, le serveur le plus bas de gamme que vous trouverez pourra probablement accueillir 100 fois plus de visiteurs que ce dont vous avez besoin, alors la question qui se pose est : est-ce que les pouillèmes de performances gagnés par Nginx valent le sacrifice d’un serveur stable, éprouvé et maintenable ?
Leave a Comment August 29, 2011