Guide de dimensionnement de NGINX Plus : notre méthodologie de test

Faisal MemonIngénieur logiciel

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 la répartition de charge de couche 7, également appelée répartition de charge applicative.

[Éditeur – Nous mettons régulièrement à jour le guide de dimensionnement afin de tenir compte de l’évolution des fonctionnalités de NGINX Plus, ainsi que des coûts et des performances du matériel. Le lien ci-dessus renvoie toujours vers la dernière version du guide.

Pour plus d’informations sur les performances de NGINX et de NGINX Plus en tant que serveur web, consultez Test des performances des serveurs web NGINX et NGINX Plus.]

Le guide de dimensionnement présente les performances que vous pouvez espérer obtenir avec NGINX Plus sur des serveurs de différentes capacités, ainsi que les coûts matériels estimés. Vous pouvez l’utiliser pour dimensionner correctement les déploiements NGINX Plus et éviter autant que possible le surdimensionnement – qui entraîne des dépenses immédiates – ou le sous-dimensionnement – qui peut provoquer des problèmes de performances et vous coûter de l’argent à long terme.

Le guide de dimensionnement a suscité beaucoup d’intérêt, ainsi que des questions sur la méthodologie employée, de la part de clients et d’autres personnes souhaitant reproduire nos résultats. Cet article de blog présente un aperçu des tests que nous avons effectués pour obtenir les résultats figurant dans le guide de dimensionnement. Il décrit la topologie utilisée, les tests réalisés et la manière dont nous avons déterminé les prix indiqués dans le guide.

Remarque : bien que nous ayons élaboré le guide de dimensionnement spécifiquement pour NGINX Plus, nous avons utilisé NGINX Open Source pour les tests afin que chacun puisse les reproduire sans abonnement à NGINX Plus. Les tests ne font appel à aucune des fonctionnalités avancées de NGINX Plus ; les résultats sont donc identiques pour NGINX Open Source et NGINX Plus. NGINX Open Source version 1.9.7 correspond approximativement à NGINX Plus Release 7.

Cependant, afin de mieux distinguer le proxy inverse du serveur web backend dans la topologie de test, nous désignons le premier par NGINX Plus et le second par NGINX (Open Source).

Topologie

Tous les tests ont été réalisés à l’aide de trois machines distinctes interconnectées par deux liaisons 40 GbE au sein d’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 des performances similaire à ab (ApacheBench). Comme le montre le schéma, tout le trafic était dirigé vers le proxy inverse NGINX Plus, qui transmettait les connexions au serveur web NGINX Open Source en backend.

Matériel utilisé

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

Machine Processeur Réseau MémoireClient 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz, 36 cœurs physiques (ou 72 avec HT) 2x Intel XL710 40GbE QSFP+ (rév. 01) 16 GoProxy inverse 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz, 36 cœurs physiques (ou 72 avec HT) 4x Intel XL710 40GbE QSFP+ (rév. 01) 16 GoServeur web 2x Intel(R) Xeon(R) CPU E5‑2699 v3 @ 2.30GHz, 36 cœurs physiques (ou 72 avec HT) 2x Intel XL710 40GbE QSFP+ (rév. 01) 16 Go

Logiciels utilisés

Nous avons utilisé les logiciels suivants pour effectuer les tests :

• La version 4.0.0 de wrk exécutée sur la machine cliente a généré le trafic transmis par le proxy NGINX. Nous l’avons installée en suivant ces instructions.
• La version 1.9.7 de NGINX Open Source était exécutée sur les machines proxy inverse et serveur Web. Nous l’avons installée depuis le dépôt officiel de nginx.org en suivant ces instructions.
• Ubuntu Linux 14.04.1 était installé sur les trois machines.

Méthodologie de test

Nous avons testé les performances du serveur proxy inverse NGINX Plus avec différents nombres de processeurs. Un processus worker NGINX Plus utilise un seul processeur. Pour mesurer les performances avec différents nombres de processeurs, nous avons donc fait varier le nombre de processus worker et répété les tests avec deux processus worker, puis quatre, huit, et ainsi de suite. Pour une présentation de l’architecture de NGINX, consultez notre blog.

Remarque : pour définir manuellement le nombre de processus worker, utilisez la directive worker_processes. La valeur par défaut est auto. Elle indique à NGINX Plus de détecter le nombre de processeurs et d’exécuter un processus worker par processeur.

Indicateurs de performance

Nous avons mesuré les indicateurs suivants :

• Requêtes par seconde (RPS) – Mesure la capacité à traiter les requêtes HTTP. Lors de nos tests, chaque client envoie des requêtes pour un fichier de 1 Ko via une connexion persistante. Le proxy inverse traite chaque requête et la transmet au serveur web via une autre connexion persistante.
• Transactions SSL/TLS par seconde (TPS) – Mesure la capacité à traiter de nouvelles connexions SSL/TLS. Lors de 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 persistante établie. Le serveur web renvoie une réponse de 0 octet pour chaque requête.
• Débit – Mesure le débit que NGINX Plus peut maintenir lors de la diffusion de fichiers de 1 Mo via HTTP.

Exécution des tests

Pour générer l’ensemble du trafic client, nous avons utilisé wrk avec les options suivantes :

• L’option « -c » indique le nombre de connexions TCP à créer. Pour nos tests, nous l’avons fixé à 50 connexions.
• L’option -d indique la durée pendant laquelle le trafic doit être généré. Chacun de nos tests a duré 3 minutes.
• L’option -t indique le nombre de threads à créer. Nous avons spécifié un seul thread.

Pour solliciter pleinement chaque processeur, nous avons utilisé taskset, qui permet d’affecter un seul processus wrk à un processeur. Cette méthode produit des résultats plus cohérents que l’augmentation du nombre de threads wrk.

Requêtes par seconde

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

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1kb.bin &
done

Ce test a lancé une instance de wrk par processeur, soit 36 au total sur notre machine cliente. Chaque instance a établi 50 connexions TCP et les a utilisées pour envoyer en continu des requêtes portant sur un fichier de 1 Ko pendant 3 minutes (180 secondes).

Transactions SSL/TLS par seconde

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

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s -H 'Connection: close' https://Reverse-Proxy-Server-IP-address/0kb.bin &
done

Ce test utilise les mêmes valeurs pour -c, -d et -t que le test précédent, mais il s’en distingue de deux manières notables, car il porte principalement 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é a une taille de 0 (zéro) octet au lieu de 1 Ko.

Débit

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

for i in `seq 0 $(($(getconf _NPROCESSORS_ONLN) - 1))`; do    taskset -c $i wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address/1mb.bin &
done

La seule différence par rapport au premier test réside dans la taille plus importante du fichier, qui est de 1 Mo. Nous avons constaté que l’utilisation d’un fichier encore plus volumineux (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 suivant, légèrement modifié, a permis de répartir uniformément le trafic entre les deux cartes :

for i in `seq 0 $((($(getconf _NPROCESSORS_ONLN) - 1)/2))`; do    n=`echo $(($i+number-of-CPUs/2))`;
    taskset -c $i ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-1/1kb.bin &
    taskset -c $n ./wrk -t 1 -c 50 -d 180s http://Reverse-Proxy-Server-IP-address-2/1kb.bin &
done

Tarifs

La dernière étape, une fois les performances mesurées avec différents nombres de cœurs, consistait à déterminer le coût des serveurs présentant les caractéristiques correspondantes. Nous avons utilisé les prix de serveurs Dell PowerEdge dont les caractéristiques étaient similaires à celles du matériel Intel utilisé lors de nos tests. L’annexe ci-dessous contient la nomenclature complète de chaque serveur, ainsi que la configuration NGINX complète pour le proxy inverse et le serveur Web.

Annexe

Configurations matérielles Dell

Les prix indiqués dans le guide de dimensionnement correspondent aux configurations matérielles Dell suivantes.

Remarque: les modèles de serveurs présentant les caractéristiques et les prix indiqués étaient disponibles au moment où nous avons effectué nos tests, mais sont susceptibles de changer à l’avenir.

Modèle de serveur Caractéristiques PrixDell PowerEdge R230 Processeur : Intel Core i3-6100 double cœur à 3,7 GHz, 2 cœurs/4 threads
RAM : 4 Go
Disque dur : 500 Go
Carte réseau : Intel X710 2 × 10 GbE 1 200 $Processeur : Intel® Xeon® E3‑1220 v5 à 3,0 GHz, 4 cœurs/8 threads
RAM : 4 Go
Disque dur : 500 Go
Carte réseau : Intel XL710 2 × 40 GbE 1 400 $Dell PowerEdge R430 Processeur : Intel® Xeon® E5‑2630 v3 à 2,4 GHz, 8 cœurs/16 threads
RAM : 4 Go
Disque dur : 500 Go
Carte réseau : Intel XL710 2 × 40 GbE 2 200 $Processeur : 2 × Intel® Xeon® E5‑2630 v3 à 2,4 GHz, 8 cœurs/16 threads
RAM : 8 Go
Disque dur : 500 Go
Carte réseau : Intel XL710 2 × 40 GbE 3 000 $Dell PowerEdge R630 Processeur : 2 × Intel® Xeon® E5‑2697A v4 à 2,6 GHz, 16 cœurs/32 threads
RAM : 8 Go
Disque dur : 500 Go
Carte réseau : Intel XL710 2 × 40 GbE 8 000 $Processeur : 2 × Intel® Xeon® E5‑2699 v3 à 2,3 GHz, 18 cœurs/36 threads
RAM : 8 Go
Disque dur : 500 Go
Carte réseau : Intel XL710 2 × 40 GbE 11 000 $

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 de TPS SSL/TLS, nous avons défini les valeurs des deux directives de sorte que les connexions ne restent ouvertes que le temps d’une seule requête, l’objectif de ce test étant de déterminer 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é ajustées afin de maintenir les connexions actives aussi longtemps que possible.

Pour le reste, la configuration est assez classique pour un serveur proxy inverse, NGINX Plus transmettant les requêtes à un serveur web à l’aide de la directive « proxy_pass ».

user                 nginx;worker_processes     auto;
worker_rlimit_nofile 10240;
pid                  /var/run/nginx.pid;

events {
    worker_connections 10240;
    accept_mutex       off;
    multi_accept       off;
}

http {
    access_log    off;
    include       /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 on;

    # RPS tests
    keepalive_timeout  300s;     
    keepalive_requests 1000000;

    # SSL/TLS TPS tests
    #keepalive_timeout  0;  
    #keepalive_requests 1; 
  
    upstream webserver {
        server Web-Server-IP-address;
    }

    server {
        listen 80;
        listen 443 ssl backlog=102400 reuseport;

        ssl_certificate     /etc/nginx/ssl/rsa-cert.crt;
        ssl_certificate_key /etc/nginx/ssl/rsa-key.key;
        ssl_session_tickets off;
        ssl_session_cache   off;

        root /var/www/html;
            location / {
                proxy_pass http://webserver;
            }
        }
    }
}

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 défini 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 rempli de zéros :

dd if=/dev/zero of=1kb.bin bs=1KB count=1

La configuration :

user                 nginx;
worker_processes     auto;
worker_rlimit_nofile 10240;
pid                  /var/run/nginx.pid;

events {
    worker_connections 10240;
    accept_mutex       off;
    multi_accept       off;
}

http {
    access_log   off;
    include      /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 on;

    keepalive_timeout  300s;     
    keepalive_requests 1000000;

    server {
        listen 80;
        root /var/www/html;
    }
}

Pour essayer NGINX Plus, commencez dès aujourd’hui un essai gratuit de 30 jours ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Faisal MemonIngénieur logiciel

Autres articles de Faisal Memon