Bataille de serveurs WEB. Partie 1 – HTTP déconnecté :

Dans cet article, nous allons nous essayer à l’ingénierie inverse, pourrait-on dire. Nous mettrons nos mains sales sous le capot de chaque serveur Web, en les exploitant d'une manière que personne n'exploiterait jamais.

Ce test est une mesure d'un cheval sphérique dans le vide, rien de plus que les données qui ont été obtenues, et maintenant nous ne savons plus quoi en faire.

Méthodologie

Le système d'exploitation pour Nginx et Apache est Ubuntu 18.04 LTS, pour IIS Windows Server Core 2019. Avant les tests, tous les systèmes d'exploitation ont reçu les dernières mises à jour en date du 04.12.2019 décembre XNUMX.

Les tests ont été effectués exclusivement via HTTP. Chaque serveur Web exécutait la même page, un modèle Jekyll gratuit de Codrops. Lien. La compression gzip était désactivée sur chaque serveur Web.

Le test de débit a été réalisé avec Httpd-tools avec les arguments :

ab -n 50000 -c 500 http://192.168.76.204:80/

Les serveurs étaient limités à 10, 5 et 1 pour cent du cœur sur 8, 4 et un cœur. Le banc de test était un ordinateur avec 9900 5400 K à 10 540 MHz, ce qui signifie que le serveur recevant une limite de XNUMX % reçoit environ XNUMX MHz par cœur.

Le test TTFB a été effectué lors du premier démarrage du serveur et mesuré à l'aide de DevTools ; après avoir reçu le résultat, le serveur a été éteint et ramené au point de contrôle précédent pour éliminer 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 le sous-système disque, les résultats des benchmarks ATTO et CrystalDIskMark afin d'avoir une idée des ​​goulots d'étranglement.

Données extraites de la machine virtuelle :

Résultats:

TTFB :

Le TTFB moyen pour IIS est le plus petit, 0,5 ms, contre 1,4 ms pour Apache et 4 ms pour Nginx.

Débit:

Tout d’abord, examinons dans quelle mesure chaque serveur évolue en fonction du nombre de cœurs.

Le graphique montre le nombre d'appels du testeur au serveur Web et la latence. Le graphique montre que NGINX a traité 98 % de toutes les requêtes, livrant le site en 20 ms ou moins. IIS, comme Apache, a réalisé les derniers 5 % de tous les appels en 76 ms et 14 ms, respectivement.

Le graphique montre le temps de traitement moyen d'une demande lors d'un test de résistance.

Comme vous pouvez le voir sur les graphiques, IIS a époustouflé Apache et Nginx, ralentissant considérablement sous une charge élevée. 

IIS préférait clairement 4 cœurs à XNUMX, affichant des latences plus faibles sur XNUMX, mais ne favorisait pas non plus fortement un seul cœur.

NGINX s'adapte bien aux 8 cœurs et pour Apache, le scénario monocœur semble être le meilleur choix.

Évolutivité :

Nginx :

Examinons maintenant l'évolutivité en termes de fréquence et de nombre de cœurs. 

Nginx n'a pas réussi les tests avec une limite de 1% pour 4 et 1 cœurs ; lorsqu'il a dépassé 2000 requêtes, il a mis fin à la connexion avec le testeur.

Apache:

Apache, comme Nginx, après avoir traité 2500 requêtes, a abandonné et fermé la connexion. Apache a échoué au test sur 8, 4 et 1 cœurs avec une limite de 1%, mais en plus il a également échoué au test avec une limite de 5% sur un cœur, ce qui est pire que Nginx

IIS :

Pendant les tests, IIS a accumulé une gigantesque file d’attente de requêtes mais a traité chacune d’elles. Apparemment, aucun délai d'attente n'est défini pour le traitement des demandes.

Le graphique montre le temps qu'il a fallu pour terminer le test. Des configurations de test complètement absurdes ont été écartées. Le diagramme montre à quel point IIS est exigeant en matière de matériel et à quel point NGINX est merveilleux.

Évolutivité à partir du disque :

Nginx :

Examinons maintenant l'évolutivité en termes de fréquence, de nombre de cœurs et de vitesse de disque. 

Cette fois, Nginx a échoué à 4 tests au lieu de deux.

Apache:

Apache a échoué au même nombre de tests que la dernière fois.

IIS :

IIS affiche un graphique presque identique, comme s'il n'y avait aucune restriction de disque. En général, les graphiques de tous les serveurs n'ont pas beaucoup changé, ce qui signifie que chacun d'entre eux a mis en cache les données statiques dans la RAM et les a servies à partir de là. Nous voyons ici le principal goulot d'étranglement : le serveur Web lui-même.

Il est trop tôt pour tirer des conclusions basées sur ces tests ; nous n'avons pas encore testé HTTPS, la compression et HTTP/2 avec un certificat live de Let's Encrypt. Nous en parlerons dans le prochain article.

Source: habr.com