Comment tester la charge d'un site web ou d'une API hébergé localement
Pourquoi vous avez besoin d'une URL publique
Nos générateurs de charge sont hébergés dans le cloud, donc votre service, site web, API ou service web doit être publiquement accessible pour que nos agents de test de charge puissent atteindre votre point de terminaison.
Si vous hébergez votre service, site web, API ou service web localement, il existe quelques outils que vous pouvez utiliser pour exposer un site web hébergé localement sur Internet.
Les générateurs de charge s'exécutent dans des centres de données cloud, pas sur votre machine, ils ne peuvent donc jamais résoudre http://localhost, une plage d'IP privée comme 192.168.x.x ou 10.x.x.x, ni un port qui n'est lié que sur votre ordinateur portable. Voir https://loadfocus.com/docs/fr-fr/knowledge-base/using-valid-url-endpoints pour la liste complète de ce qui compte comme une cible accessible.
Outils pour exposer un serveur local sur Internet
Voici des services qui vous permettent d'exposer certains ports de votre machine locale afin que le monde extérieur puisse s'y connecter :
Les services ci-dessus vous permettent de partager facilement un service web sur votre machine de développement locale sans avoir à modifier les paramètres DNS et de pare-feu.
Comment fonctionnent les outils de tunnel
Les deux outils suivent le même principe de base : un petit client sur votre machine ouvre une connexion sortante vers le serveur relais du fournisseur de tunnel (les connexions sortantes sont rarement bloquées par les pare-feux ou le NAT). Le fournisseur attribue une URL publique et redirige les requêtes entrantes sur cette URL à travers le tunnel jusqu'au port que vous avez exposé localement. Aucun changement DNS, redirection de port ou règle de pare-feu n'est nécessaire, ce qui en fait le moyen le plus rapide de rendre une application locale accessible pour un test rapide.
À prendre en compte avant de tester la charge à travers un tunnel
- Limites du niveau gratuit : la plupart des offres de tunnel gratuites plafonnent la bande passante ou le nombre de connexions simultanées. Sous une charge réelle, avec des centaines ou des milliers d'utilisateurs virtuels, vous pouvez atteindre le plafond du tunnel lui-même avant celui de votre application, et les chiffres obtenus décrivent alors le tunnel, pas votre application.
- Latence supplémentaire : chaque requête effectue désormais un saut supplémentaire à travers le serveur relais du fournisseur de tunnel. Les temps de réponse seront plus élevés que ce que le même code afficherait une fois déployé derrière votre infrastructure habituelle, donc traitez les chiffres absolus avec prudence.
- Stabilité pendant le test : si le processus de tunnel plante, ou si la machine qui l'exécute se met en veille ou perd le réseau, toutes les requêtes en cours échouent d'un coup. Pour tout ce qui dépasse un test de fumée rapide, exécutez le tunnel depuis une machine toujours allumée plutôt que depuis un ordinateur portable.
- Exposition : un tunnel rend votre environnement local accessible à quiconque possède, ou devine, l'URL générée, tant que le tunnel reste ouvert. Gardez la fenêtre d'exposition courte, utilisez les options d'authentification du fournisseur si disponibles, et évitez de tunneliser un environnement contenant de vraies données de production.
Quand un tunnel est le bon outil
Un tunnel convient bien à une vérification rapide de bon sens : confirmer qu'un point de terminaison gère un nombre modeste de requêtes simultanées avant sa mise en production, ou reproduire un problème constaté dans un test cloud sur une build locale. Pour une planification de capacité sérieuse ou des chiffres de référence, déployez sur un environnement de staging qui reproduit l'infrastructure de production d'aussi près que possible. Le saut du tunnel ajoute du bruit qui rend les temps de réponse absolus peu fiables, bien que les comparaisons relatives, tester la même configuration tunnelée avant et après un changement de code, puissent encore vous apprendre quelque chose d'utile.