bench Nginx, de 1.4.2 à 1.9.5, options http/2 thread aio et spdy

Depuis que j’utilise NginX, j’ai toujours gardé les binaires compilés de Nginx sur ma machine.

Aujourd’hui, je me fais un plaisir, reprendre chacun de ces binaires, et les tester sur mon portail phpmynewsletter, portail qui fonctionne avec du SSL, une HHVM avec un fallback en php-fpm. (Donc sur un serveur en production !)

Concernant http/2, je vous conseille l’excellente doc de Daniel Stenberg, ingénieur réseaux chez Mozilla : http://daniel.haxx.se/http2/http2-v1.8.pdf. (Autres lecures conseillées :
https://fr.wikipedia.org/wiki/SPDY
https://http2.github.io/)

Pour le protocole d’essai, je vais utiliser wrk, dépôt et explications sur Github dont l’installation est très simple, et que je préfère largement à ab de apache2-utils. J’utilise également un portail qui est réellement en production (au lieu d’utiliser un portail en localhost, ce qui explique des chiffres que l’on peut trouver bas, mais qui ont au moins le mérite de se rapprocher de ce que vous pourrez avoir, vous, en réel. Le matériel est un core i5, 16 go de Ram, et une partition sur un disque en raid mirroré, donc pas de raid 0. Enfin, le moteur PHP derrière tout ça est une HHVM).

Je détaillerai pour chaque test la config par le simple résultat de la commande « nginx -V », et chaque test sera déroulé 5 fois. Je ne posterai que le meilleur résultat de chaque bench.

Chaque wrk sera lancé selon la commande :

Qui signifie : 12 threads, 400 connexions ouvertes pendant 30 secondes.

Tout d’abord, on installe wrk, super simple, en root :
Sur Debian (moi 7,xx, noyau 2.6.xx) :

 

Juste pour info sur CentOS / RedHat et Defora :

 

Les configurations de chacun des Nginx testés :

Nginx 1.4.2 :

 

Nginx 1.6.0 :

 

Nginx 1.9.4 avec spdy, ssl 1.0.2d (dernière version de Nginx disponible avec spdy, à partir de Nginx 1.9.5, spdy est replacé par http/2) :

 

Nginx 1.9.5 sans thread aio, http/2, ssl 1.0.1e :

 

Nginx 1.9.5 avec thread aio, avec http/2, ssl 1.0.1e :

 

Nginx 1.9.5 avec thread aio, avec http/2, ssl 1.0.2d :

 

 

Les résultats :

Nginx 1.4.2 sans spdy, ssl 1.0.1e :

A noter, 51 connexions en Time Out…

Nginx 1.6.0 sans spdy, ssl 1.0.1e

Ouch !!! 1400 requêtes exécutées en moins et 80 timeout en plus (je vais avoir un oeil qui va tomber…)

Je n’ai pas utilisé la V1.7.1, qui a pourtant bonne réputation, d’autres sujets étaient sur le feu (désolé, on priorise parfois !), donc je suis passé à la v1.9.3…

Nginx 1.9.3 sans spdy, ssl 1.0.1e :

Je respire ! Nombre de requêtes encore en baisse à 27700, mais par contre une meilleure gestion des timeout (qui étaient dues à Nginx, les modules php ayant été pour l’occasion poussés à 300 secondes de timeout). Donc un taux de 100% de réponses assurées, et quand on est webmaster, administrateur, ça, c’est VRAIMENT important ! Sic !!!

Nginx 1.9.4 avec spdy, ssl 1.0.2d :

On repasse au dessus des 30.000 requêtes exécutées pour arriver à 33.000, 1110 requêtes secondes… Bien, suis content !

On passe aux choses sérieuses. La version 1.9.5 de Nginx abandonne le mode spdy au profit de 2 nouvelles choses importantes : http/2 et thread_pool (attention, c’est un module encore expérimental qui reste à utiliser avec modération… Je laisserai un mot sur quelques bugs rencontrés à ce sujet).

Nginx 1.9.5 sans http/2, sans thread_pool, ssl 1.0.1e :

De bonnes performances, on est encore au dessus de 30.000 requêtes, mais plus de spdy, et toujours pas de http/2 activé, ni thread_pool… Voyons la suite, activons http/2…

Nginx 1.9.5 avec http/2 activé, sans thread_pool, ssl 1.0.1e :

A noter pour mieux comprendre : je rappelle que le serveur est un serveur de production, c’est à dire qu’il tourne en conditions réelles, avec des vrais sites dessus (dont une grosse base de données cinéma), que le protocole http/2 est une fonctionnalité offerte par certains navigateurs : (source : https://www.keycdn.com/blog/keycdn-http2-support/ du 6 octobre 2015)
caniuse-http2-browser-supportJe rappelle aussi que Nginx 1.9.5 avec le module http/2 est censé être compilé avec openssl 1.0.2, alors que ce dernier exemple de bench est avec un openssl en 1.0.1 (des conséquences ?).
J’ai également constaté un bug… Lors de mon authentification sur le forum de Phpmynewsletter.com, je suis sans cesse envoyé sur une page 403, et une erreur de connexion, sur Chrome Version 45.0.2454.101 m, alors que j’ai un résultat tout à fait correct sur Firefox 41.0.1. Un autre bug : des soucis avec des uploads de fichiers volumineux (dossier de presse cinéma) sur le portail cinéma… Pas top ça…
Et en conclusion : que le protocole http/2 ne peut donc pas donner de résulats probants avec un appel via wrk (ou curl, wget, ab ou quoi que ce soit !)

Enfin bon, donc l’avant dernier test, avec le pool thread_aio… :

On est pas mal… Plus de 31.000 requêtes, pas de timeout… Je veux voir la différence avec le dernier test…

Nginx 1.9.5 avec thread aio, avec http/2, ssl 1.0.2d :

Conclusion…

Que dire ?....

Que penser de tout cela ?…..

Nginx évolue, gère mieux les time out et sert mieux donc toutes les connexions. Le serveur utilisé n’est pas neutre, d’autres process tournent ! Il ne fallait non plus s’attendre à des chiffres de folie, je le savais. Ce que je crois, c’est que dans son ensemble le serveur physique et la gestion des processus sont arrivés aux limites de ce qu’ils peuvent donner à Nginx.

La vue usager est par contre plus intéressante : les pages s’affichent quasi instantanément, plus d’attente de chargement qui d’un objet qui attend sur le précédent qui attend sur le précédent, etc… Tout s’affiche d’un bloc.

Oui, mais alors… Les GTMetrix et autres sites de tests de chargement des pages ?
Et bien ils ne sont pas encore près aux tests http/2, ils retombent donc dans l’usage d’un navigateur commun, ordinaire,…ancien !

La seule chose qui compte, ne l’oubliez jamais : c’est l’usage et le confort de vos usagers, visteurs, membres, etc… Sur votre ou vos sites hébergés ainsi.

On aurait pu pousser le test avec usage différencié de php5-fpm et hhvm, ajouter ou pas du memcache et autres modules de tunning de vos php. Je ne l’ai pas fait, c’est totalement volontaire !

Je suis très content des résultats, tout simplement !

Allez, @+

Quand les sessions de php.ini ne sont pas potes avec hhvm (session.save_path qui part en sucette !)

hhvm-logo1

Je viens d’installer une hhvm sur mon petit serveur qui me va bien, et après avoir customisé les paramètres du fichier php.ini (paramètres  php de base de la Hip Hop Virtual Machine), je constate que la modification du répertoire des sessions n’a pas été prise en compte !

(Peu importe l’avis des puristes, seul compte le résultat, j’ai déplacé mon répertoire de sessions dans /home qui dispose d’une trèèèèèèès grande place, la racine ayant été taillée pour ne pas risque de débordement…)

Donc, le bug connu de hhvm dans sa config, est de garder le répertoire initial :

et que hhvm refuse de prendre en compte mon

Ce n’est pas grave, je ne vais pas aller batailler avec Facebook et ses développeurs qui nous font déjà la grâce bienveillante de nous mettre à disposition ce code. Je choisis donc la solution la plus simple qui existe : créer un lien symbolique !

Je vais faire un petit tour dans mon nouveau répertoire de stockage des sessions et « ls -l » :

Bref, c’est ok !
applause-sign

L’avantage est qu’il n’y a rien à modifier pour cette directive qui reste tout simplement :

Sinon, je pense que je ferai un petit topo rapide sur cette petite merveille… Enfin, moi j’adore !

Pour information, PHP est en version 5.6, derrière un petit Nginx, et je vais me lancer dans quelques benchs, histoire de vérifier les qualités de tout ce schmilblic !

schmilblic

 

@+ !

 

 

Nginx, SSL et certificat

Dans le billet relatif à l’installation de Nginx, je vous avais présenté une compilation qui me correspondait, à savoir : https://blog.aulica-conseil.com/index.php/installation-full-de-nginx-1-4-2-ngx_pagespeed-inside/

Pour ajouter le certificat qui vous permettra d’éviter cette page :
connexion-non-securisee

 

 

 

 

Lire la suite

Se protéger (un peu) avec Nginx…

nginx
Adepte de Nginx, je souhaitais partager avec un vous un petit retour sur la protection ! Aujourd’hui, voici un petit moyen simple de prévenir, ralentir (mais pas empêcher !!!) les attaques, DDOS par exemple. (En gros et selon wikipédia : « Une attaque par déni de service (denial of service attack, d’où l’abréviation DoS) est une attaque informatique ayant pour but de rendre indisponible un service, d’empêcher les utilisateurs légitimes d’un service de l’utiliser.[…] La suite c’est par ici : http://fr.wikipedia.org/wiki/Attaque_par_d%C3%A9ni_de_service). Lire la suite

Hotlinking ? Watermarker vos images sous nginx (et avec php accessoirement !)

Tout le monde sait ce qu’est le hotlinking, et si vous ne le savez pas, on peut juste dire que c’est faire un lien pour illustrer son portail avec une ressource qui ne nous appartient pas. En gros, un portail A fait un joli article sur la crise de la mouche en amazonie centrale avec des images faites par un amateur et hébergées sur un site B.

Le site A ne dépense rien en bande passante, tandis que B qui a site très modeste voit sa bande passante exploser pour peu que A ait une certaine notoriété.

Certains petits malins qui ont des sites comme B auront un serveur dédié, un serveur Nginx installé dessus, et en grattant un peu le web, il sera tombé sur notre article de ce jour pour se dire : « OK, j’autorise le hotlink, mais alors A, tu vas faire de la pub pour moi… »

Le webmaster de B a tout compris…

Comment faire ? Lire la suite

ngx_pagespeed_cache… Faire encore mieux !

Après avoir mis en place le mode pagespeed (voir le billet précédent : https://blog.aulica-conseil.com/index.php/installation-full-de-nginx-1-4-2-ngx_pagespeed-inside/) (et j’espère que comme moi vous apprécierez ce mode et ce qu’il apporte), on va voir que l’on peut encore améliorer les performances, en plaçant le cache en RAM !

C’est très simple, et ça se déroulera en 3 étapes :

  • Création du répertoire en RAM
  • Configuration de Nginx.conf
  • Reload du serveur

Lire la suite

installation full de nginx 1.4.2 ngx_pagespeed inside

Allez vite fait, comment installer Nginx, version 1.4.2, version full, avec plus particulièrement le mod ngx_pagespeed :

On va commencer par résoudre en préalable toutes les dépendances, connecté root :

Téléchargement de pagespeed et psol :

 Téléchargement et préparation de nginx :

J’en profite pour installer le dernier module rtmp :
(https://github.com/arut/nginx-rtmp-module et je vous en parlerai plus tard…)

Et enfin on compile, voici ma liste d’option :

Je fais vite fais une sauvegarde du binaire antérieur :

Et je peux lancer la compilation :

Une fois terminée, je copie le binaire obtenu :

Dans chaque bloc « server » de /etc/nginx/nginx.conf où l’on veut activer le mode pagespeed, on ajoute bien :

Pour vérifier votre installation (présence de la ligne X-Page-Speed)

On n’oublie pas que toute la doc se trouve là :
https://developers.google.com/speed/pagespeed/module/using
et que chaque configuration est à tester !

NB : pour booster encore un peu votre pagespeed, je vous invite à voir ce billet :
https://blog.aulica-conseil.com/index.php/ngx_pagespeed_cache-faire-encore-mieux/

Installer Sympa, Mailing list server sur Nginx, c’est possible !

Sympa est l’outil idéal pour gérer des mailings list, mais la documentation pour une installation sur Nginx est encore assez légère.
J’héberge un client sur un dédié Debian et serveur web Nginx.
Je lui installe donc ce « Sympa » sur mon nginx.
On va faire une installation standard :

Je ne rentre pas dans le détail de la configuration de Sympa, ce n’est pas l’objectif dans ce billet, retour à Nginx :
Dans notre nginx.conf, on va créer un serveur (sous-domaine) :

Dans la doc Sympa, on vous dira de passer par un socket :

Le hic c’est que vous aurez souvent un joli « 403 » affiché à ‘écran, en fonction des droits que vous aurez accordé dans votre système.
Oui passer par le port 8999 est moins rapide, mais nous sommes ici dans une configuration mode « user standalone » !
Si vous développez un portail complet en perl, alors oui vous aurez à passer par les sockets. Aujourd’hui, ce n’est pas le cas !

Si vous n’avez de wrapper perl installé :

Ajouter un script de démarrage /etc/init.d/perl-fcgi :

et enfin :

Recharger Nginx, et accéder à votre liste : http://lists.votredomaine.com

nginx: « Vary: Accept-Encoding » dans les entêtes

Si vous utilisez GTmetrix (par exemple et entre autres !!) pour mesurer la rapidité et la qualité de vote site web, vous pourrez peut être avoir ceci :
The following publicly cacheable, compressible resources should have a « Vary: Accept-Encoding » header: …
(liste de fichiers js, css, html, xml ou encore json…).
GTmetrix vous collera alors un affreux C et baissera votre note de qualité…

La remarque concernant le « Vary: Accept-Encoding header » :

« Bugs in some public proxies may lead to compressed versions of your resources being served to users that don’t support compression. Specifying theVary: Accept-Encoding header instructs the proxy to store both a compressed and uncompressed version of the resource. »

En d’autres termes, il faut activer l’entête « Vary: Accept-Encoding » pour tout ce qui est « fichier » !
Pour Nginx, il faut 2 conditions, que nous poserons au niveau du serveur, paragraphe http:

  1. Activer le module Gzip_Vary (http://wiki.nginx.org/HttpGzipModule#gzip_vary)
  2. Il faut qu’une des directives gzip, gzip_static ou gunzip soit active !
  3. préciser les types mime élus dans la directive gzip_types.

En résumé, voici le bout de code du paragraphe http :

Et enfin, pour affiner son propre gzip_types, fonction de son application web, la liste des types MIME : http://fr.wikipedia.org/wiki/Type_MIME