FAQ OpenResty | Structure réseau pour les tests, fonctionnalités liées à SSL, DSL, outil `ab`

La série d'articles sur OpenResty a été mise à jour jusqu'à présent, et nous avons terminé la partie concernant les tests. Félicitations pour ne pas avoir pris de retard, pour avoir appris et pratiqué activement les opérations, et pour avoir laissé vos réflexions avec enthousiasme.

Beaucoup des questions soulevées dans les commentaires sont précieuses, et certaines des plus typiques et intéressantes ont été spécialement extraites pour constituer la FAQ d'aujourd'hui.

Examinons ces cinq questions aujourd'hui.

Question 1 : Comment construire la structure réseau pour les tests ?

Q : Le client exécutant wrk doit-il être placé sur une machine du réseau externe ou sur une machine du même LAN que le serveur ? Lequel de ces deux choix est le plus significatif pour les tests de performance ?

R : Pour tester les services web, choisir le bon outil de test n'est qu'un bon début, et la manière de construire la structure réseau pour les tests est également une partie essentielle de la suite.

En général, nous voulons tester les limites de performance du service seul, en excluant toutes les interférences réseau. Pour cela, nous pouvons adopter deux méthodes pour construire le réseau et effectuer le test de charge.

La première méthode consiste à déployer wrk et les applications serveur sur la même machine avec de bonnes performances. Par exemple, nous pouvons activer huit workers dans NGINX et répartir les ressources CPU restantes entre wrk, de sorte qu'il n'y ait que de la communication réseau locale, minimisant ainsi l'impact du réseau.

La deuxième méthode consiste à construire un LAN avec un routeur dédié et à connecter la machine où se trouve wrk à la machine où se trouve le serveur.

Il n'est pas recommandé de tester directement dans un réseau existant, car la plupart des réseaux ont des commutateurs et des pare-feu, qui peuvent limiter les tests de charge avec de grands volumes de trafic et entraîner des résultats de test inexacts.

De plus, je voudrais ajouter quelques mots sur les outils de test de performance. Premièrement, les outils de test de performance peuvent avoir des problèmes de Coordinated Omission, auxquels vous devez prêter une attention particulière lors de l'analyse des données de latence de l'outil.

Coordinated Omission signifie que lors des tests de performance, il ne suffit pas de compter le temps entre l'envoi et la réception d'une réponse, ce qui n'est que le temps de service, donc les statistiques manqueront beaucoup de problèmes potentiels. Par conséquent, nous devons également inclure le temps d'attente de la demande de test, ce qui globalement est le temps de réponse qui intéresse les utilisateurs. Bien sûr, si votre programme côté serveur peut être bloquant, vous devez simplement prendre en compte ce problème. Sinon, vous pouvez l'ignorer.

Question 2 : test::nginx peut-il tester les fonctionnalités liées à SSL ?

Q : Est-il impossible de tester les fonctionnalités liées à SSL avec test::nginx ?

R : Ce n'est pas le cas. test::nginx peut tester les fonctionnalités liées à SSL ; vous pouvez vous référer à ssl.t. Ce fichier de test de cas teste l'ensemble du processus du certificat SSL. Tout d'abord, comme vous pouvez le voir, le test de cas utilise du code Lua pour lire les clés publiques et privées du certificat local ; ensuite, il configure le certificat via l'API HTTP ; enfin, il utilise cosocket pour effectuer la poignée de main SSL et l'accès pour vérifier si le certificat est valide.

En fait, non seulement SSL, mais aussi les fonctionnalités incluses dans OpenResty peuvent être surchargées en utilisant test::nginx.

Lorsque vous n'êtes pas sûr qu'une fonctionnalité particulière peut être implémentée avec test::nginx, vous pouvez d'abord rechercher les cas de test de lua-nginx-module et d'autres projets open source d'OpenResty, et vous pouvez généralement trouver des exemples correspondants. Après tout, test::nginx est très jouable et variable, et certaines combinaisons et astuces inattendues attendent d'être découvertes.

Question 3 : Qu'est-ce que DSL exactement ?

Q : Que sont exactement DSL et test::nginx ?

R : DSL signifie Domain Specific Language. Le but de DSL est différent des langages de développement courants. Il ne s'agit pas de répondre aux besoins d'un domaine général, mais à ceux d'un domaine spécifique. Le DSL le plus célèbre est SQL, le langage de requête structuré utilisé dans le domaine des bases de données.

Quant à test::nginx, c'est un DSL créé pour répondre aux besoins de test de NGINX et OpenResty. En fait, les auteurs d'OpenResty ont inventé de nombreuses idées de DSL et ont apporté de nombreuses nouvelles tentatives et solutions à la communauté OpenResty. Cependant, comme mentionné dans l'article précédent, DSL est une épée à double tranchant, et le critère principal pour mesurer la valeur de DSL est de savoir s'il peut apporter une amélioration de la productivité aux utilisateurs finaux.

Question 4 : Problème d'installation de test::nginx

Q : Après avoir exécuté git clone, dois-je exécuter la commande suivante pour installer test::nginx ?

cd test-nginx
perl Makefile.PL
make
sudo make install

R : En fait, ce n'est pas le cas. Ici, vous pouvez vous référer à certains projets open source.

Étape 1 : installez-le via le gestionnaire de paquets

sudo cpanm --notest Test::Nginx >build.log 2>&1 || (cat build.log && exit 1)

Étape 2 : git clone la dernière version de test::nginx

git clone https://github.com/openresty/test-nginx.git test-nginx

Étape 3 : incluez le répertoire test-nginx lorsque vous utilisez la commande prove

prove -Itest-nginx/lib -r t

Comme je l'ai mentionné précédemment, les meilleurs guides pour installer OpenResty et les projets environnants se trouvent dans CI, et non dans la documentation. Cela peut être différent des autres projets, principalement parce qu'OpenResty maintient son propre fork ou des versions spécifiques de certains des projets environnants et parce qu'OpenResty est également fortement dépendant de CI. Par conséquent, vous devez utiliser et tester OpenResty de la même manière qu'il est construit dans CI pour garantir la cohérence avec la version officielle.

Question 5 : L'outil de test ab est-il bon ou pas ?

Q : Comment se fait-il que Yichun Zhang mentionne fréquemment ab comme le meilleur outil de test dans Google Groups ?

R : Comme je l'ai mentionné dans l'article, ab n'est pas un bon outil de test de performance en ce qui concerne les fonctionnalités de l'outil seul, car il ne peut pas générer suffisamment de pression de demande. Cependant, la performance des programmes côté serveur est puissante aujourd'hui. Nous utilisons ab au lieu de wrk dans test::nginx car en mode TEST_NGINX_BENCHMARK, test::nginx utilise soit ab soit weighttp, selon la version du protocole HTTP, comme outil pour les tests de performance.

De plus, j'espère que vous noterez que la technologie Internet évolue très rapidement, et chacun de nous doit mettre à jour ses connaissances et compétences en temps opportun. Par exemple, à mon avis, ce choix de test::nginx doit maintenant être mis à jour, et Yichun Zhang ne connaissait peut-être pas l'existence de wrk à l'époque. Bien sûr, il y aura peut-être de meilleurs outils de test de performance que wrk avec le temps, et nous devrions naturellement avoir un esprit positif et ouvert pour apprendre et choisir.

Aujourd'hui, j'ai principalement répondu aux questions mentionnées ci-dessus. J'espère qu'à travers la communication et les questions-réponses, je peux vous aider à transformer ce que vous apprenez en ce que vous obtenez. Vous êtes également invités à partager cet article afin que nous puissions communiquer et progresser ensemble.