Nous avons parlé de la technique dans la
première partie de l' article, dans laquelle nous testons HTTPS, mais dans des scénarios plus réalistes. Pour les tests, le certificat Let's Encrypt a été reçu, la compression Brotli par 11 a été activée.
Cette fois, nous allons essayer de reproduire le scénario de déploiement du serveur sur VDS ou en tant que machine virtuelle sur un hôte avec un processeur typique. Pour ce faire, définissez la limite sur:
- 25% - ce qui en termes de fréquence ~ 1350 MHz
- 35% -1890 MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Le nombre de connexions uniques est passé de 500 à 1, 3, 5, 7 et 9,
Résultats:
Retards:
TTFB a été spécialement conçu comme test séparé, car les outils HTTPD créent un nouvel utilisateur pour chaque demande individuelle. Ce test est encore assez éloigné de la réalité, car l'utilisateur clique sur quelques pages de toute façon, et en réalité TTFP jouera le rôle principal.
La première, généralement la toute première requête, après le premier démarrage de la machine virtuelle, IIS traite en moyenne 120 ms.
Toutes les demandes suivantes affichent un TTFP de 1,5 ms. Apache et Nginx sont à la traîne. Personnellement, l'auteur considère ce test comme le plus révélateur et choisirait un gagnant uniquement sur celui-ci.
Le résultat n'est pas surprenant, car IIS met en cache le contenu statique déjà compressé et ne le pince pas à chaque accès.
Temps passé sur un client
Pour évaluer les performances, un test avec 1 connexion unique est suffisant.
Par exemple, IIS a terminé les tests avec une longueur de 5 000 utilisateurs en 40 secondes, soit 123 requêtes par seconde.
Les graphiques ci-dessous indiquent le temps nécessaire au transfert complet du contenu du site. Il s'agit du pourcentage de demandes traitées à un moment précis. Dans notre cas, 80% de toutes les demandes ont été traitées en 8 ms sur IIS et en 4,5 ms sur Apache et Nginx, et 98% de toutes les demandes sur Apache et Nginx ont été exécutées dans un intervalle de 8 millisecondes.
Le temps nécessaire pour traiter 5000 demandes:
Le temps nécessaire pour traiter 5000 demandes:
Si vous avez une machine virtuelle avec un processeur 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 du serveur Web à choisir pour chaque hôte.
Lorsqu'il s'agit d'une situation un peu plus réelle, tous les serveurs Web se font face.
Débit:
Calendrier des retards sur le nombre de connexions simultanées. Plus lisse et plus bas, c'est mieux. Les 2% restants ont été supprimés des graphiques car ils les rendraient illisibles.
Considérez maintenant l'option où le serveur est hébergé sur un hébergement partagé. Prenez 4 cœurs à 2,2 GHz et un cœur à 1,8 GHz.
Comment évoluer
Si vous avez déjà vu à quoi ressemblent les caractéristiques I - V des triodes électro-vide, des pentodes, etc., ces graphiques vous seront familiers. C'est ce que nous essayons de saisir - la satiété. La limite est, lorsque vous ne lancez pas combien de cœurs, la croissance de la productivité ne sera pas perceptible.
Auparavant, tout le défi consistait à traiter 98% des demandes avec le moins de retard sur toutes les demandes, pour garder la courbe aussi uniforme que possible. Maintenant, en utilisant la construction d'une autre courbe, nous trouvons le point de fonctionnement optimal pour chacun des serveurs.
Pour ce faire, prenez la métrique Demandes par seconde (RPR). Fréquence horizontale, verticale - le nombre de demandes traitées par seconde, lignes - le nombre de cœurs.
Une corrélation est montrée de la façon dont Nginx gère les demandes une par une. 8 cœurs dans de tels tests se montrent mieux.
Ce graphique montre clairement combien mieux (pas beaucoup) Nginx fonctionne sur un seul cœur. Si vous avez Nginx, vous devriez envisager de réduire le nombre de cœurs à un si vous hébergez uniquement des statiques.
IIS, bien qu'il ait le TTFB le plus bas selon DevTools dans Chrome, parvient à perdre à la fois Nginx et Apache dans une lutte sérieuse contre le test de stress de la Fondation Apache.
La courbure complète des graphiques est reproduite par train.
Une sorte de conclusion:
Oui, Apache fonctionne moins bien sur les noyaux 1 et 8, et sur 4 ça marche un peu mieux.
Oui, Nginx sur 8 cœurs gère mieux les demandes les unes après les autres, sur 1 et 4 cœurs, et fonctionne moins bien quand il y a beaucoup de connexions.
Oui, IIS préfère 4 cœurs pour une charge multithread et préfère 8 cœurs pour un seul thread. Au final, IIS était un peu plus rapide que tous sur 8 cœurs sous forte charge, bien que tous les serveurs aient été vidés.
Ce n'est pas une erreur de mesure, l'erreur ici n'est pas supérieure à + -1 ms. dans les retards et pas plus de + - 2-3 demandes par seconde pour RPR.
Les résultats, lorsque 8 cœurs sont pires, ne sont pas du tout surprenants, de nombreux cœurs et SMT / Hyperthreading dégradent gravement les performances si nous avons le délai pour lequel nous devons terminer l'ensemble du pipeline.
Nous proposons un tarif UltraLite
Windows VDS mis à jour pour 99 roubles avec Windows Server 2019 Core installé.
