Dans cet article, nous allons nous essayer à l'ingénierie inverse, si l'on peut dire. Nous allons jeter un coup d'œil, avec nos mains sales, sous le capot de chacun des serveurs web, les exploitant d'une manière que personne n'aurait jamais imaginée.
Ce test est une mesure d'un cheval sphérique dans un vide, ce ne sont que des données qu'on a obtenues, et nous ne savons maintenant pas quoi en faire.
Méthodologie
Le système d'exploitation utilisé pour Nginx et Apache est Ubuntu 18.04 LTS, et pour IIS, Windows Server Core 2019. Tous les systèmes d'exploitation ont reçu les dernières mises à jour à la date du 04.12.2019 avant les tests.
Les tests ont été effectués exclusivement en HTTP. Sur chaque serveur web, une seule page était exécutée, un modèle gratuit pour Jekyll de Codrops. . Sur chacun des serveurs web, la compression gzip était désactivée.
Le test de bande passante a été réalisé avec Httpd-tools avec les arguments :
ab -n 50000 -c 500 http://192.168.76.204:80/Les serveurs ont été limités à 10, 5 et 1 pour cent du cœur sur 8, 4 et un cœur. Comme banc d'essai, un ordinateur avec un i9 9900K@5400MHz a été utilisé, ce qui signifie que le serveur ayant une limitation de 10 % obtient environ 540MHz par cœur.
Le test TTFB a été effectué lors du premier chargement du serveur et mesuré avec DevTools. Après obtention du résultat, le serveur a été éteint et retourné à la point de contrôle précédent pour exclure l'apparition de tout type de cache.
Le testeur et le serveur web étaient sur le même hôte et sur le même commutateur virtuel.
Pour évaluer immédiatement la sous-système de disque, nous avons les résultats des benchmarks ATTO et CrystalDiskMark, afin d'avoir une idée des goulets d'étranglement.
Les données ont été recueillies à partir d'une machine virtuelle :
Résultats :
TTFB :
Le TTFB moyen de IIS est le plus bas, à 0,5 ms, contre 1,4 ms pour Apache et 4 ms pour Nginx.
Débit :
Examinons d'abord dans quelle mesure chacun des serveurs se scale bien en fonction du nombre de cœurs.
Le graphique montre le nombre de requêtes efectuées par le testeur au serveur web et la latence. On peut voir sur le graphique que NGINX a répondu à 98 % des requêtes, délivrant le site en 20 ms ou moins. IIS et Apache ont pris respectivement 76 ms et 14 ms pour traiter les 5 % restants des requêtes.
Le graphique montre le temps moyen de traitement d'une seule requête pendant le test de charge.
Comme on peut le constater sur les graphiques, IIS a perdu face à Apache et Nginx, ralentissant considérablement sous une forte charge.
IIS a clairement préféré 4 cœurs à 8, montrant des latences plus faibles avec 4 cœurs, mais n'a pas non plus beaucoup apprécié un seul cœur.
NGINX se scale parfaitement sur les 8 cœurs, tandis qu'Apache semble s'en sortir mieux avec un scénario monocœur.
Scalabilité :
Nginx :
Examinons maintenant la scalabilité en fonction de la fréquence et du nombre de cœurs.
Lors des tests avec une limite de 1 % sur 4 et 1 cœur, Nginx n'a pas réussi, rompant la connexion avec le testeur après avoir dépassé 2000 requêtes.
Apache :
Tout comme Nginx, Apache a abandonné après 2500 requêtes et a rompu la connexion. Apache n'a pas réussi le test sur 8, 4 et 1 cœur avec une limite de 1 %, et en plus, il n'a pas réussi le test avec une limite de 5 % sur un seul cœur, ce qui est pire que Nginx.
IIS :
IIS a accumulé une énorme file d'attente de requêtes pendant les tests, mais a réussi à traiter chacune d'elles. Apparemment, il n'a pas de délais de traitement de requêtes par défaut.
Le graphique montre le temps nécessaire pour compléter le test. Des configurations de test totalement absurdes ont été écartées. D'après le graphique, on voit à quel point IIS est exigeant en matière de matériel, et à quel point NGINX est exceptionnel.
Scalabilité disque :
Nginx :
Examinons désormais la scalabilité en fonction de la fréquence, du nombre de cœurs et de la vitesse du disque.
Cette fois, Nginx n'a pas réussi 4 tests, au lieu de deux.
Apache :
Apache a échoué dans le même nombre de tests que lors de la fois précédente.
IIS :
IIS présente un graphique presque identique, comme s'il n'y avait pas de restrictions sur le disque. En général, les graphiques de tous les serveurs n'ont pas beaucoup changé, ce qui signifie que chacun d'eux a mis en cache la statique dans la mémoire vive et l'a renvoyée de là. Ici, nous voyons le principal goulet d'étranglement : le serveur web lui-même.
Il est encore trop tôt pour tirer des conclusions sur ces tests, nous n'avons pas encore testé HTTPS, la compression et HTTP/2 avec un certificat en direct de Let's Encrypt. Nous en parlerons dans le prochain article.
Source : habr.com
