Test de charge des milliers de connexions SLOW

Question

Je voudrais tester un service de téléchargement avec des centaines, sinon des milliers, de lente connexions HTTPS simultanément. Je voudrais avoir beaucoup, disons, des connexions de qualité 3G, chacun étranglé avec une bande passante faible et une latence élevée, chacun envoyant quelques mégaoctets de données au serveur, résultant en beaucoup de demandes simultanées, de longue durée être géré par le serveur.

Il existe de nombreux outils de génération de charge pouvant générer des milliers de requêtes simultanées. (Je suis actuellement en utilisant Locust, surtout pour que je puisse prendre avantage de ma bibliothèque cliente existante écrite en Python.) Ces outils exécutent généralement chaque requête simultanée aussi vite que possible sur le lien réseau partagé.

Il existe différentes façons d'ajuster la bande passante apparente et la latence des connexions TCP, tels que TC de Linux et emballages pratiques comme Comcast. Pour autant que je sache, TC et les autres contrôlent le lien partagé mais ils ne peuvent pas limiter les demandes individuelles. Si vous voulez limiter une seule requête, TC fonctionne bien. En théorie, avec de nombreux clients qui partagent le même lien réseau étranglé, chaque demande pourrait être exécutée en série, sous réserve de la bande passante limitée, plutôt que d'avoir beaucoup de demandes exécuter simultanément, quelques paquets à la fois. La première entraînerait beaucoup moins de demandes actives exécutant simultanément sur le serveur.

Je soupçonne que l'outil que je veux doit activement gérer chaque envoi de chaque client et de recevoir pour les étrangler équitablement. Existe-t-il un tel outil?

Answer 1

Vous pouvez jeter un oeil à Apache JMeter, il peut les connexions « accélérateur » au débit configurable via les propriétés suivantes:

httpclient.socket.http.cps=0 
httpclient.socket.https.cps=0 

Les propriétés peuvent être définies soit dans user.properties fichier ou transmis à JMeter via -J command-line argument

cps représente character per second afin que vous puissiez « ralentir » threads JMeter (utilisateurs virtuels) pour le débit donné, la formule de calcul est cps:

cps = (target bandwidth in kbps * 1024)/8 

Pour plus d'informations, consultez How to Simulate Different Network Speeds in Your JMeter Load Test.

Answer 2

Oui, ce sont des simulateurs de réseau. Un très primitif est sous la forme de WanEM. Cela ne va pas couvrir vos besoins de test. Vous aurez besoin de quelque chose qui s'apparente à Shunra Storm, un périphérique qui peut gérer les connexions individuelles et la déficience avec des modèles dérivés d'Ookla (pensez à speedtest.com) liés aux connexions 3,4,5g de la nature. Eh bien, peut-être devrais-je dire, "pourrait gérer", car ce produit a été absent depuis l'acquisition de HP par Shunra.

Il existe d'autres concurrents sur le marché des sociétés telles que Ixia, Agilent, PacketStorm, Spirent et autres. Aucun d'eux n'est bon marché, mais je vois votre besoin. Les connexions lentes et particulièrement sales aiment les téléphones portables, ont un impact disproportionné sur la pile et peuvent entraîner l'épuisement des ressources du serveur avec moins de connexions mobiles que celles du bureau. Sur une note de côté, assurez-vous d'inclure un modèle représentatif pour le temps de réflexion dans votre code de test. Si vous réduisez le modèle client-serveur avec un temps de réflexion nul ou extrêmement limité, il ne peut y avoir que de mauvaises choses. Cela va perturber la prévisibilité et la répétabilité de vos tests. Vous pouvez également vous retrouver avec des douzaines de fantômes d'ingénierie liés au chargement de votre code qui ne se produiront pas en production en raison des retards naturels et de la libération des ressources qui devraient se produire durant ces fenêtres d'activité entre les demandes des clients.