Nous avons parlé de la méthodologie dans article, dans celui-ci, nous testons HTTPS, mais dans des scénarios plus réalistes. Pour les tests, nous avons obtenu un certificat Let's Encrypt et activé la compression Brotli à 11.
Cette fois nous allons tenter de reproduire le scénario de déploiement d'un serveur sur un VDS ou en machine virtuelle sur un hôte avec un processeur standard. A cet effet, une limite a été fixée à :
- 25% - Ce qui équivaut à une fréquence de ~ 1350 MHz
- 35% -1890MHz
- 41% - 2214 MHz
- 65% - 3510 MHz
Le nombre de connexions uniques a été réduit de 500 à 1, 3, 5, 7 et 9,
Résultats:
Retards :
TTFB a été spécifiquement inclus en tant que test distinct, car HTTPD Tools crée un nouvel utilisateur pour chaque requête individuelle. Ce test est encore assez détaché de la réalité, car l'utilisateur cliquera toujours sur quelques pages, 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 prend en moyenne 120 ms.
Toutes les requêtes ultérieures affichent un TTFP de 1.5 ms. Apache et Nginx sont à la traîne à cet égard. Personnellement, l'auteur considère ce test comme le plus révélateur et choisirait le gagnant uniquement sur cette base.
Le résultat n'est pas surprenant puisque IIS met en cache le contenu statique déjà compressé et ne le compresse pas à chaque accès.
Temps passé par client
Pour évaluer les performances, un test avec 1 seule connexion suffit.
Par exemple, IIS a effectué un test auprès de 5000 40 utilisateurs en 123 secondes, soit XNUMX requêtes par seconde.
Les graphiques ci-dessous montrent le temps nécessaire pour que le contenu du site soit complètement transféré. Il s'agit de la proportion de demandes complété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, et 8 % de toutes les requêtes sur Apache et Nginx ont été traitées dans un intervalle allant jusqu'à 98 millisecondes.
Délai pendant lequel 5000 demandes ont été traitées :
Délai pendant lequel 5000 demandes ont été traitées :
Si vous disposez d'une machine virtuelle avec un processeur de 3.5 GHz et 8 cœurs, choisissez ce que vous voulez. Tous les serveurs Web sont très similaires lors de ces tests. Nous parlerons ci-dessous du serveur Web à choisir pour chaque hôte.
Dans une situation un peu plus réaliste, tous les serveurs Web s’affrontent.
Débit:
Graphique des retards en fonction du 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érons maintenant l'option 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 évoluer
Si vous avez déjà vu à quoi ressemblent les caractéristiques courant-tension des triodes à vide, des pentodes, etc., ces graphiques vous seront familiers. C'est ce que nous essayons d'attraper : la saturation. La limite est celle où, quel que soit le nombre de cœurs que vous lancez, l'augmentation des performances ne sera pas perceptible.
Auparavant, tout le défi consistait à traiter 98 % des requêtes avec la latence la plus faible pour toutes les requêtes, en gardant la courbe aussi plate que possible. Maintenant, en construisant une autre courbe, on va trouver le point de fonctionnement optimal pour chacun des serveurs.
Pour ce faire, prenons l’indicateur Requêtes par seconde (RPR). L'horizontale est la fréquence, la verticale est le nombre de requêtes traitées par seconde, les lignes sont le nombre de cœurs.
Affiche une corrélation entre la façon dont Nginx traite les requêtes les unes après les autres. 8 cœurs fonctionnent mieux dans ce test.
Ce graphique montre clairement à quel point Nginx fonctionne mieux (pas beaucoup) sur un seul cœur. Si vous disposez de Nginx, vous devriez envisager de réduire le nombre de cœurs à un si vous n’hébergez que des cœurs statiques.
IIS, bien qu'il ait le TTFB le plus bas selon DevTools dans Chrome, parvient à perdre face à Nginx et Apache dans une bataille sérieuse avec le test de résistance de la Fondation Apache.
Toute la courbure des graphiques est reproduite à toute épreuve.
Une sorte de conclusion :
Oui, Apache fonctionne moins bien sur 1 et 8 cœurs, mais fonctionne un peu mieux sur 4.
Oui, Nginx sur 8 cœurs traite mieux les requêtes les unes après les autres, sur 1 et 4 cœurs, et fonctionne moins bien lorsqu'il y a de nombreuses connexions.
Oui, IIS préfère 4 cœurs pour les charges de travail multithread et préfère 8 cœurs pour les charges de travail monothread. En fin de compte, IIS était légèrement plus rapide que tout le monde sur 8 cœurs sous charge élevée, même si tous les serveurs étaient à égalité.
Ce n'est pas une erreur de mesure, l'erreur ici n'est pas supérieure à +-1 ms. en retards et pas plus de +- 2-3 requêtes par seconde pour RPR.
Les résultats où 8 cœurs fonctionnent moins bien ne sont pas du tout surprenants, de nombreux cœurs et SMT/Hyperthreading dégradent considérablement les performances si nous disposons d'un délai dans lequel nous devons terminer l'intégralité du pipeline.
Source: habr.com