Il y a un petit moment maintenant, avec Léo nous avons revu l’architecture serveur de Korben.info l’un des choix que nous avons du faire concernait le serveur web. Un choix assez classique pour les experts du web et les devOps, mais surtout l’occasion de vous offrir le retour de Léo en matière de comparatif entre Apache ou Ninx.
En effet, beaucoup de benchmarks trouvables en ligne utilisent la configuration par défaut des serveurs. Mais ces configurations sont-elles comparables ? Comment d’y retrouver quand on est un développeur soucieux de son environnement technique ?
Depuis que Léo est tombé sur les dépôts GitHub de H5BP, un groupe de dev bénévoles qui font un super travail en proposant des bases de configuration les plus en adéquation possible avec les standards web, il est possible d’avoir une base solide de comparaison.
Grâce à ces configurations proposées, vous obtenez ainsi des réponses HTTP très homogènes et impeccables, quel que soit le logiciel utilisé comme serveur.
Et en particulier des configurations pour Apache httpd et Nginx, les deux principaux serveurs web. Et on obtient donc 3 configurations vraiment comparables, car parfaitement calibrées pour une utilisation à destination du web.
Léo s’est amusé à faire de tests de performance sur les trois configurations, pour se faire une idée, et vous partager les résultats.
Il a d’abord fais tourner un outil de test nommé k6 (open source, dédié aux tests de charge) pendant 20 secondes avec une montée en puissance. Pour cela, on écrit un petit script pour manipuler k6, qui utilise un moteur JavaScript.
import { check } from 'k6'
import * as http from 'k6/http'
export const options = {
stages: [
{ duration: '10s', target: 100 },
{ duration: '5s', target: 100 },
{ duration: '5s', target: 0 }
],
thresholds: {
checks: [{
threshold: 'rate>0.1',
abortOnFail: true
}]
},
hosts: {
'server.localhost': '127.0.0.1'
}
}
export default function () {
check(http.get('http://server.localhost/test.html'), {
'is status 200': (r) => r.status === 200
})
}
Chacune de ses configurations a donc reçu environ 50 000 requêtes, puis il a extrait la mesure de la durée de la requête.
Pour visualiser les résultats, il a choisi d’agréger les valeurs dans des diagrammes boîte à moustaches (oui c’est rigolo comme nom). Pour rappel, une boite à moustache est structurée de la manière suivante.
Comme outils pour construire ce type de diagramme, il utilise notamment un notebook Jupiter. Basé sur Python, c’est l’environnement idéal pour des manipulations statistiques sans prise de tête. Pour les curieux, le notebook est disponible dans un gist.
Comparatif des temps de réponse en millisecondes des trois configurations en boites à moustache sur axe logarithmique.Si les médianes (lignes rouges) ne sont pas très éloignées les unes des autres, l’utilisation d’un fichier .htaccess amène quand même beaucoup de ralentissement.
Un maximum à 95% plus élevé, un écart-type plus grand (illustrant des temps de réponse moins prévisibles). Les points au delà de la limite à 95% sont considérés comme aberrants, mais leur présence plus marquée avec le .htaccess renforce le sentiment d’instabilité.
Dès que le module d’interprétation des .htaccess est désactivé, httpd et nginx sont vraiment similaires en termes de performance.
Léger gain pour nginx, un poil plus étalé vers le bas, ce qui n’est pas sans illustrer son potentiel de cache. Ce test a permis, entre autres, la sélection du serveur en place sur Korben.info.
Ainsi, nous avons choisi nginx qui, avec ses fonctionnalités de cache avancées, à une efficacité redoutable lors des montées en charge.Bien sûr, sa configuration repose en grande partie sur le boilerplate H5BP.
En tant que mainteneur de ces configurations H5BP, Léo aussi mis en place des benchmarks automatiques sur chacun de dépôts à l’aide de h5bp/server-configs-test, pour suivre l’évolution de ces configurations et des logiciels au fil des années.
J’espère que cet article technique vous aura permis en tant que développeur d’y voir un peu plus clair sur Apache et Nginx et notamment sur la méthode que vous pouvez mettre en place pour justement comparer leurs performances et leur comportement avec votre applicatif de manière égalitaire.
Si vous avez des questions, rendez-vous sur le forum de Korben.
Aureliano
Merci. Très intéressant et beaucoup de pistes utiles pour approfondir.