La bataille des serveurs WEB. Partie 2 – un scénario réaliste pour HTTPS :

Nous avons parlé de la méthode dans de la première partie l'article, ici nous testons HTTPS, mais dans des scénarios plus réalistes. Pour ce test, nous avons obtenu un certificat Let’s Encrypt, et activé la compression Brotli à 11.

Cette fois, nous allons essayer de reproduire un scénario de déploiement de serveur sur VDS ou en tant que machine virtuelle sur un hôte avec un processeur standard. Pour cela, nous avons imposé une limite de :

• 25% — ce qui équivaut à une fréquence d'environ 1350 MHz
• 35% -1890 MHz
• 41% — 2214 MHz
• 65% — 3510 MHz

Le nombre de connexions simultanées a été réduit de 500 à 1, 3, 5, 7 et 9,

Résultats :

Lattences :

Le TTFB a été spécifiquement extrait comme test séparé, car HTTPD Tools crée une sorte de nouvel utilisateur pour chaque requête distincte. Ce test est encore assez déconnecté de la réalité, car un utilisateur cliquera toujours sur quelques pages, et dans la réalité, le TTFP jouera le rôle principal.

La première, la toute première requête après le premier démarrage de la machine virtuelle IIS s'exécute en moyenne en 120 ms.

Toutes les requêtes suivantes montrent un TTFP de 1,5 ms. Apache et Nginx sont à la traîne dans ce domaine. L'auteur pense personnellement que ce test est le plus révélateur et choisirait un vainqueur uniquement sur cette base.
Le résultat n'est pas surprenant, car IIS met en cache le contenu statique déjà compressé et ne le recomprime pas à chaque fois qu'il est sollicité.

Temps consacré à un client

Pour évaluer la performance, un test avec 1 connexion simultanée est suffisant.
Par exemple, IIS a terminé le test de 5000 utilisateurs en 40 secondes, soit 123 requêtes par seconde.

Dans les graphiques ci-dessous, nous montrons le temps jusqu'à la transmission complète du contenu du site. C'est la proportion de requêtes effectuées dans un temps donné. Dans notre cas, 80% de toutes les requêtes ont été traitées en 8 ms sur IIS et en 4,5 ms sur Apache et Nginx, tandis que l'intervalle jusqu'à 8 millisecondes a traité 98% de toutes les requêtes sur Apache et Nginx.

Temps nécessaire pour traiter 5000 requêtes :

Temps nécessaire pour traiter 5000 requêtes :

Si vous avez une machine virtuelle avec un CPU de 3,5 GHz et 8 cœurs, choisissez ce que vous voulez. Tous les serveurs web sont très similaires dans ce test. Nous parlerons ci-dessous de quel serveur web choisir pour chaque hôte.

Quand il s'agit d'une situation un peu plus réaliste, tous les serveurs web sont au coude à coude.

Débit :

Graphique des latences en fonction du nombre de connexions simultanées. Plus la courbe est plate et basse, mieux c'est. Les 2 % les plus récents ont été écartés des graphiques car ils les rendraient illisibles.

Considérons maintenant le cas où le serveur est hébergé sur un hébergement virtuel. Prenons 4 cœurs à 2,2 GHz et un cœur à 1,8 GHz.

Comment se dimensionnent

Si vous avez déjà vu à quoi ressemblent les caractéristiques des triodes et pentodes électrovaccinants, ces graphiques vous seront familiers. C'est précisément ce que nous essayons de capturer : la saturation. Le point où, peu importe combien de cœurs vous ajoutez, l'augmentation des performances ne sera pas perceptible.

Auparavant, tout le défi consistait à traiter 98 % des requêtes avec le moindre délai possible pour maintenir une courbe aussi lisse que possible. Maintenant, grâce à une autre courbe, nous allons trouver le point de fonctionnement optimal pour chacun des serveurs.

Pour cela, nous allons utiliser l'indicateur des requêtes par seconde (RPR). Sur l'axe horizontal, la fréquence, sur l'axe vertical — le nombre de requêtes traitées par seconde, les lignes — le nombre de cœurs.

La corrélation dans la manière dont Nginx traite les requêtes une après l'autre est montrée. 8 cœurs se montrent meilleurs dans ce test.

Ce graphique montre bien combien Nginx fonctionne mieux (pas de beaucoup) sur un seul cœur. Si vous utilisez Nginx, il peut être judicieux de réduire le nombre de cœurs à un si vous n'hébergez que des fichiers statiques.

Bien que IIS ait le TTFB le plus bas selon DevTools dans Chrome, il parvient à perdre face à Nginx et Apache dans un test de stress sérieux de l'Apache Foundation.

La courbure des graphiques est reproduite à la perfection.

En résumé :

Oui, Apache fonctionne indéniablement moins bien sur 1 et 8 cœurs, alors qu'il obtient de meilleures performances sur 4 cœurs.

Oui, Nginx gère mieux les requêtes une après l'autre avec 8 cœurs, mais il fonctionne moins bien avec 1 et 4 cœurs quand il y a beaucoup de connexions.

Oui, IIS préfère 4 cœurs pour les charges multithread et 8 cœurs pour le monothread. En fin de compte, IIS s'est avéré légèrement plus rapide que les autres avec 8 cœurs sous une charge élevée, bien que tous les serveurs soient restés au même niveau.

Ce n'est pas une erreur de mesure, la marge d'erreur ici est de ±1 ms. pour les latences et de ±2-3 requêtes par seconde pour le RPR.

Les résultats lorsqu'il y a 8 cœurs qui se comportent moins bien ne sont pas surprenants ; de nombreux cœurs et SMT/Hyperthreading dégradent fortement les performances si nous avons un délai à respecter pour terminer l'ensemble du pipeline.

Source : habr.com