Guide des tailles NGINX Plus : Comment nous avons testé

Plus tôt cette année, nous avons évalué les performances de NGINX Plus et créé un guide de dimensionnement pour son déploiement sur des serveurs bare metal. NGINX Open Source et NGINX Plus sont largement utilisés pour l'équilibrage de charge de couche 7 , également connu sous le nom d'équilibrage de charge d'application .

[ Éditeur – Nous mettons régulièrement à jour le guide des tailles pour refléter les changements dans les capacités de NGINX Plus, ainsi que dans les coûts et les performances du matériel. Le lien ci-dessus renvoie toujours au dernier guide.

Pour plus d'informations sur les performances de NGINX et NGINX Plus en tant que serveur Web, voir Test des performances des serveurs Web NGINX et NGINX Plus .]

Le guide des dimensions décrit les performances que vous pouvez espérer obtenir avec NGINX Plus exécuté sur différentes tailles de serveur, ainsi que les coûts estimés du matériel. Vous pouvez utiliser le guide de dimensionnement pour spécifier de manière appropriée les déploiements NGINX Plus et pour éviter autant que possible le surprovisionnement (qui vous coûte de l'argent immédiatement) ou le sous-provisionnement (qui peut entraîner des problèmes de performances et vous coûter de l'argent à long terme).

Nous avons reçu beaucoup d’intérêt pour le guide des tailles, ainsi que des questions sur la méthodologie que nous avons utilisée, de la part de clients et d’autres personnes intéressées à reproduire nos résultats. Cet article de blog fournit un aperçu des tests que nous avons effectués pour obtenir les résultats présentés dans le guide des tailles. Il couvre la topologie que nous avons utilisée, les tests que nous avons effectués et comment nous avons trouvé les prix indiqués dans le guide des dimensions.

Note : Bien que nous ayons développé le guide de dimensionnement spécifiquement pour NGINX Plus, nous avons utilisé NGINX Open Source pour les tests afin que chacun puisse reproduire nos tests sans abonnement NGINX Plus. Les tests n'utilisent aucune des fonctionnalités améliorées de NGINX Plus, donc les résultats pour NGINX Open Source et NGINX Plus sont les mêmes. La version 1.9.7 de NGINX Open Source correspond à peu près à NGINX Plus Release 7.

Cependant, pour mieux distinguer le proxy inverse du serveur Web back-end dans la topologie de test, nous faisons référence à NGINX Plus pour le premier et à NGINX (Open Source) pour le second.

Topologie

Tous les tests ont été effectués à l’aide de trois machines distinctes connectées ensemble par des liaisons doubles 40 GbE dans un réseau de couche 2 simple et plat.

Pour générer du trafic depuis la machine cliente, nous avons utilisé wrk , un outil de test de performances similaire à ab (ApacheBench). Comme le montre le diagramme, tout le trafic a été dirigé vers le proxy inverse NGINX Plus, qui a transmis les connexions au backend du serveur Web open source NGINX.

Matériel utilisé

Nous avons utilisé le matériel suivant pour les tests.

Logiciels utilisés

Nous avons utilisé le logiciel suivant pour les tests :

• La version 4.0.0 de wrk exécutée sur la machine cliente a généré le trafic proxy NGINX. Nous l'avons installé selon ces instructions .
• La version 1.9.7 de NGINX Open Source fonctionnait sur les machines Reverse Proxy et Web Server . Nous l'avons installé à partir du référentiel officiel sur nginx.org selon ces instructions .
• Ubuntu Linux 14.04.1 fonctionnait sur les trois machines.

Méthodologie de test

Nous avons testé les performances du serveur proxy inverse NGINX Plus avec différents nombres de CPU. Un processus de travail NGINX Plus consomme un seul processeur. Par conséquent, pour mesurer les performances de différents nombres de processeurs, nous avons fait varier le nombre de processus de travail , en répétant les tests avec deux processus de travail , quatre, huit, etc. Pour un aperçu de l'architecture NGINX, veuillez consulter notre blog .

Note : Pour définir manuellement le nombre de processus de travail , utilisez la directive worker_processes . La valeur par défaut est auto , ce qui indique à NGINX Plus de détecter le nombre de processeurs et d'exécuter un processus de travail par processeur.

Indicateurs de performance

Nous avons mesuré les paramètres suivants :

• Requêtes par seconde (RPS) – Mesure la capacité à traiter les requêtes HTTP. Dans nos tests, chaque client envoie des requêtes pour un fichier de 1 Ko via une connexion keepalive. Le proxy inverse traite chaque demande et la transmet au serveur Web via une autre connexion keepalive.
• Transactions SSL/TLS par seconde (TPS) – Mesure la capacité à traiter de nouvelles connexions SSL/TLS. Dans nos tests, chaque client envoie une série de requêtes HTTPS, chacune sur une nouvelle connexion. Le proxy inverse analyse les requêtes et les transmet au serveur Web via une connexion keepalive établie. Le serveur Web renvoie une réponse de 0 octet pour chaque demande.
• Débit – Mesure le débit que NGINX Plus peut supporter lors de la diffusion de fichiers de 1 Mo via HTTP.

Exécution de tests

Pour générer tout le trafic client, nous avons utilisé wrk avec les options suivantes :

• L'option -c spécifie le nombre de connexions TCP à créer. Pour nos tests, nous avons défini ce nombre sur 50 connexions.
• L'option -d spécifie la durée pendant laquelle générer du trafic. Nous avons effectué nos tests pendant 3 minutes chacun.
• L'option -t spécifie le nombre de threads à créer. Nous avons spécifié un seul thread.

Pour exercer pleinement chaque CPU, nous avons utilisé tasket , qui peut épingler un seul processus wrk à un CPU. Cette méthode donne des résultats plus cohérents que l’augmentation du nombre de threads de travail .

Requêtes par seconde

Pour mesurer les requêtes par seconde (RPS), nous avons exécuté le script suivant :

pour i dans `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; faire tasket -c $i wrk -t 1 -c 50 -d 180s http:// adresse IP du serveur proxy inverse /1kb.bin & terminé

Ce test a généré une copie de wrk par CPU, 36 au total pour notre machine cliente. Chaque copie a créé 50 connexions TCP et a effectué des demandes continues pour un fichier de 1 Ko pendant 3 minutes (180 secondes).

Transactions SSL/TLS par seconde

Pour mesurer les transactions SSL/TLS par seconde (TPS), nous avons exécuté le script suivant :

pour i dans `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; faire tasket -c $i wrk -t 1 -c 50 -d 180s -H 'Connexion : fermer' https:// Adresse IP du serveur proxy inverse /0kb.bin & terminé

Ce test utilise les mêmes valeurs pour -c , -d et -t que le test précédent, mais diffère de deux manières notables car l'accent est mis sur le traitement des connexions SSL/TLS :

• Le client ouvre et ferme une connexion pour chaque requête (l'option -H définit l'en-tête HTTP Connection: close ).
• Le fichier demandé fait 0 (zéro) octet au lieu de 1 Ko.

Débit

Pour mesurer le débit, nous avons exécuté le script suivant :

pour i dans `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; faire tasket -c $i wrk -t 1 -c 50 -d 180s http:// adresse IP du serveur proxy inverse /1mb.bin & terminé

La seule différence par rapport au premier test est la taille plus grande du fichier de 1 Mo. Nous avons constaté que l’utilisation d’une taille de fichier encore plus grande (10 Mo) n’augmentait pas le débit global.

Plusieurs cartes réseau

Lors de nos tests, nous avons utilisé plusieurs cartes réseau. Le script légèrement modifié suivant a assuré que le trafic était réparti uniformément entre les deux cartes :

pour i dans `seq 0 $((($(getconf _NPROCESSORS_ONLN) - 1)/2))`; do n=`echo $(($i+ nombre-de-CPU/2 ))`; tasket -c $i ./wrk -t 1 -c 50 -d 180s http:// adresse-IP-du-serveur-proxy-inverse-1 /1kb.bin & tasket -c $n ./wrk -t 1 -c 50 -d 180s http:// adresse-IP-du-serveur-proxy-inverse-2 /1kb.bin & terminé

Tarifs

L’étape finale, une fois que nous avions les chiffres de performance avec différents nombres de cœurs, consistait à déterminer le coût des serveurs avec les spécifications correspondantes. Nous avons utilisé les prix des serveurs Dell PowerEdge avec des spécifications similaires à celles du matériel Intel que nous avons utilisé dans nos tests. L'annexe ci-dessous contient une liste complète des matériaux pour chaque serveur, ainsi que la configuration NGINX complète pour le proxy inverse et le serveur Web .

Appendice

Configurations matérielles Dell

Les prix dans le guide des tailles concernent les configurations matérielles Dell suivantes.

Note : Les modèles de serveurs avec les spécifications et les prix indiqués étaient disponibles au moment où nous avons effectué nos tests, mais sont susceptibles d'être modifiés à l'avenir.

Configuration du proxy inverse NGINX Plus

La configuration suivante a été utilisée sur le proxy inverse NGINX Plus. Notez les deux ensembles de directives keepalive_timeout et keepalive_requests :

• Pour les tests SSL/TLS TPS, nous définissons les valeurs des deux directives afin que les connexions restent ouvertes pour une seule requête, car l'objectif de ce test est de voir combien de connexions SSL/TLS par seconde NGINX Plus peut traiter. La mise en cache des sessions SSL/TLS a également été désactivée.
• Pour les tests RPS, les directives ont été réglées pour maintenir les connexions actives le plus longtemps possible.

La configuration est une configuration de serveur proxy inverse assez standard par ailleurs, avec NGINX Plus servant de proxy à un serveur Web à l'aide de la directive proxy_pass .

utilisateur nginx ; processus_travailleurs auto ; worker_rlimit_nofile 10240 ; pid /var/run/nginx.pid ; événements { connexions_travailleurs 10240 ; accept_mutex désactivé ; multi_accept désactivé ; } http { journal_accès désactivé ; inclure /etc/nginx/mime.types ; type_par_défaut application/octet-stream ; format_journal principal '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" ' '"$ssl_protocol" '; sendfile activé ; # tests RPS keepalive_timeout 300s ; keepalive_requests 1000000 ; # Tests TPS SSL/TLS #keepalive_timeout 0 ; #keepalive_requests 1 ; serveur Web en amont { serveur Adresse IP du serveur Web ; } serveur { écouter 80 ; écouter 443 ssl backlog=102400 reuseport ; certificat_ssl /etc/nginx/ssl/rsa-cert.crt ; clé_certificat_ssl /etc/nginx/ssl/rsa-key.key ; ssl_session_tickets désactivé ; ssl_session_cache désactivé ; racine /var/www/html ; emplacement / { proxy_pass http://serveur_web ; } } } }

Configuration du serveur Web NGINX

La configuration ci-dessous a été utilisée sur le serveur Web NGINX. Il sert des fichiers statiques depuis /var/www/html/ , comme configuré par la directive root . Les fichiers statiques ont été générés à l'aide de dd ; cet exemple crée un fichier de 1 Ko de zéros :

dd si=/dev/zero de=1 ko.bin bs=1 ko nombre=1

La configuration:

utilisateur nginx ;
processus_travailleurs auto ;
worker_rlimit_nofile 10240 ;
pid /var/run/nginx.pid ;

événements {
connexions_travailleurs 10240 ;
accept_mutex désactivé ;
multi_accept désactivé ;
}

http {
access_log désactivé ;
inclure /etc/nginx/mime.types ;
default_type application/octet-stream ;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" "$ssl_cipher" '
'"$ssl_protocol" ' ;

sendfile activé ;

keepalive_timeout 300s ;
keepalive_requests 1000000 ;

serveur {
écoute 80 ;
racine /var/www/html ;
}
}

Pour essayer NGINX Plus vous-même, démarrez un essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .