Test de stress

Quels facteurs influencent les résultats des tests de stress ?

• La latence réseau entre la machine de test et le serveur (il est recommandé de faire les tests en intranet ou sur la même machine)
• La bande passante entre la machine de test et le serveur (il est recommandé de faire les tests en intranet ou sur la même machine)
• Si HTTP keep-alive est activé (il est conseillé de l'activer)
• Si le nombre de connexions simultanées est suffisant (pour les tests externes, il est préférable d'activer des connexions simultanées plus élevées)
• Si le nombre de processus côté serveur est raisonnable (il est conseillé que le nombre de processus pour le service helloworld soit le même que le nombre de cœurs CPU, et pour le service de base de données, il est recommandé d'avoir quatre fois le nombre de CPU ou plus)
• La performance intrinèque du service (par exemple, si une base de données externe est utilisée)

Qu'est-ce que HTTP keep-alive ?

Le mécanisme HTTP Keep-Alive est une technique utilisée pour envoyer plusieurs requêtes et réponses HTTP sur une seule connexion TCP, ce qui a un impact significatif sur les résultats des tests de performance. Si keep-alive est désactivé, le QPS peut diminuer considérablement.
Actuellement, tous les navigateurs ont keep-alive activé par défaut, ce qui signifie qu'après qu'un navigateur accède à une adresse http spécifique, la connexion reste temporairement ouverte, et lors de la prochaine requête, cette connexion est réutilisée pour améliorer la performance.
Il est conseillé d'activer keep-alive lors des tests de stress.
De plus, si keep-alive n'est pas activé pendant les tests, les ports locaux du client seront rapidement épuisés en état de timewait, ce qui se manifestera par des échecs de requêtes une fois que le nombre total de requêtes dépassera un certain seuil (environ 28 000).

Comment activer HTTP keep-alive lors des tests de stress ?

Si vous utilisez le programme ab pour faire des tests de stress, vous devez ajouter le paramètre -k, par exemple ab -n100000 -c200 -k http://127.0.0.1:8787/.
apipost doit renvoyer l'en-tête gzip pour activer keep-alive (bug d'apipost, voir ci-dessous).
Les autres programmes de test de stress activeront généralement keep-alive par défaut.

Pourquoi le QPS est-il très bas lors des tests de stress externes ?

Il est normal que le QPS soit très bas en raison de la grande latence extérieure. Par exemple, le QPS lors du test du site baidu peut n'être que de quelques dizaines.
Il est conseillé de faire des tests en intranet ou sur la même machine pour exclure l'impact de la latence réseau.
Si vous devez absolument faire des tests externes, vous pouvez augmenter le nombre de connexions simultanées pour augmenter le débit (en veillant à ce que la bande passante soit suffisante).

Pourquoi les performances diminuent-elles après le passage par un proxy nginx ?

Le fonctionnement de nginx nécessite des ressources système. De plus, la communication entre nginx et webman nécessite également des ressources.
Cependant, les ressources systèmes sont limitées, et webman ne peut pas accéder à toutes les ressources du système, il est donc normal que la performance globale du système diminue.
Pour minimiser autant que possible l'impact sur la performance causé par le proxy nginx, vous pouvez envisager de désactiver les logs nginx (access_log off;),
et d'activer keep-alive entre nginx et webman, voir proxy nginx.

De plus, https consomme plus de ressources par rapport à http, car https nécessite un échange SSL/TLS, un chiffrement et un déchiffrement des données, et la taille des paquets devient plus grande, ce qui utilise plus de bande passante, entraînant ainsi une diminution des performances.
Si les tests de stress utilisent des connexions courtes (sans activer HTTP keep-alive), chaque demande nécessitera une communication SSL/TLS supplémentaire, ce qui réduira considérablement les performances. Il est conseillé d'activer HTTP keep-alive lors de tests de stress https.

Comment savoir si le système a atteint sa limite de performance ?

En général, si le CPU atteint 100 %, cela indique que la performance du système a atteint sa limite. Si le CPU a encore des ressources libres, cela signifie que la limite n'est pas atteinte, et il est possible d'augmenter le nombre de connexions simultanées pour améliorer le QPS.
Si l'augmentation du nombre de connexions simultanées ne fait pas augmenter le QPS, cela peut indiquer que le nombre de processus webman est insuffisant, veuillez donc augmenter le nombre de processus webman. Si cela ne résout pas le problème, vérifiez si la bande passante est suffisante.

Pourquoi mes résultats de test montrent-ils que les performances de webman sont inférieures à celles du framework gin de go ?

Les tests de techempower montrent que webman surpasse gin d'environ deux fois dans tous les indicateurs, y compris texte brut, requêtes de base de données et mises à jour de base de données.
Si vos résultats diffèrent, cela pourrait être dû à l'utilisation d'ORM dans webman, ce qui aurait entraîné une perte de performance importante. Vous pouvez essayer de comparer webman + PDO natif et gin + SQL natif.

Quelle est la perte de performance de l'utilisation d'ORM dans webman ?

Voici un ensemble de données de tests de stress.

Environnement
Serveur Alibaba Cloud 4 cœurs 4 Go, base de données MySQL locale, recherche aléatoire d'une donnée parmi 100 000 enregistrements, tests effectués sur la machine locale.

Si vous utilisez PDO natif
Le QPS de webman est de 17 800

Si vous utilisez Db::table() de laravel
Le QPS de webman chute à 9 400

Si vous utilisez le Model de laravel
Le QPS de webman chute à 7 200

Les résultats de thinkORM sont similaires, sans grandes différences.

Conseil
Bien que l'utilisation d'ORM entraîne une baisse de performance, pour 99 % des cas d'utilisation, la performance dépasse largement les besoins. Si vous faites partie des 1 % restants, vous pouvez facilement résoudre le problème en augmentant le CPU ou le serveur.
Nous devrions trouver un équilibre entre plusieurs indicateurs tels que l'efficacité du développement, la maintenabilité et la performance, plutôt que de poursuivre aveuglément la performance.

Pourquoi le QPS lors des tests de stress avec apipost est-il si bas ?

Le module de test de stress d'apipost présente un bug, si le serveur ne renvoie pas d'en-tête gzip, il ne pourra pas maintenir keep-alive, entraînant ainsi une forte baisse de performance.
La solution consiste à compresser les données et à ajouter l'en-tête gzip lors de la réponse, par exemple :

<?php
namespace app\controller;
class IndexController
{
    public function index()
    {
        return response(gzencode('hello webman'))->withHeader('Content-Encoding', 'gzip');
    }
}

De plus, dans certaines situations, apipost ne peut pas générer la pression souhaitée, ce qui se traduit par un QPS d'environ 50 % inférieur à celui d'ab avec le même nombre de connexions simultanées.
Il est recommandé d'utiliser ab, wrk ou d'autres logiciels professionnels de tests de stress, plutôt qu'apipost.

Définir le nombre de processus approprié

Webman active par défaut un nombre de processus égal à cpu * 4. En réalité, pour les tests de stress d'un service helloworld sans I/O réseau, le nombre de processus doit être égal au nombre de cœurs CPU pour une performance optimale, car cela réduit le coût des changements de contexte.
Pour les services avec base de données, Redis ou autres I/O bloquants, le nombre de processus peut être réglé entre 3 et 8 fois le nombre de CPU, car il faut plus de processus pour améliorer la concurrence, et le coût des changements de contexte devient négligeable par rapport à l'I/O bloquant.

Plages de référence pour les tests de stress

Serveur Cloud 4 cœurs 4 Go 16 processus Test en local/intranet

Données de test de pression tierces techempower

Exemples de commandes de test de stress

ab

# 100000 requêtes 200 connexions simultanées avec keep-alive activé
ab -n100000 -c200 -k http://127.0.0.1:8787/

# 100000 requêtes 200 connexions simultanées sans keep-alive
ab -n100000 -c200 http://127.0.0.1:8787/

wrk

# 200 connexions simultanées pendant 10 secondes avec keep-alive activé (par défaut)
wrk -c 200 -d 10s http://example.com