Requête
Aussi appelée sampler
Une requête HTTP est la plus petite unité de travail que vous pouvez définir pour qu'un test l'exécute. Généralement, lors des tests d'ArcGIS Enterprise, il peut s'agir d'une URL pour une ressource comme un service de carte, un service de fonctionnalités ou une résolution d'itinéraire, mais cela peut aussi être un appel pour un objet statique comme un fichier *.css ou *.js.
Le protocole peut être HTTP (texte brut) ou HTTPS (sécurisé) et la méthode peut être l'une des nombreuses, bien que GET POST et HEAD soient généralement les plus courantes.
Une requête dynamique de service de carte ressemblerait à la forme suivante :
https://yourwebadaptor.domain.com/server/rest/services/NaturalEarth/MapServer/export?bbox=-130.9656801129776%2C18.608785315857112%2C-57.52504741730332%2C52.34557596043248&bboxSR=4326&imageSR=4326&size=1920%2C882&dpi=96&format=png32&transparent=true&layers=show%3A15%2C16%2C17%2C19%2C20%2C21%2C22%2C23%2C24%2C25%2C26%2C27%2C28%2C29%2C30%2C31%2C32%2C33%2C34%2C35&f=image
La même URL en tant que requête HTTP Apache JMeter :
À quoi ressemble une requête statique :
https://yourwebadaptor.domain.com/portal/home/10.9.0/js/jsapi/dojo/dojo.js
Apache JMeter fait également la distinction entre une requête et un sampler, bien qu'ils définissent tous deux une action à exécuter. Un sampler, ce serait l'exécution d'un processus au niveau du système d'exploitation qui effectue un type d'action comme exécuter un outil de géotraitement pour créer une géodatabase fichier ou créer une nouvelle version SDE dans une géodatabase d'entreprise. Chaque test doit comporter au moins une requête ou un sampler.
Un autre type de sampler est un web socket. Bien qu'il soit similaire à une requête HTTP en ce qu'il effectue un appel via le "web" et peut être sécurisé, il utilise un protocole différent pour communiquer avec le serveur distant ainsi que des paramètres différents pour spécifier les options de paramètre.
Transaction
Une transaction est un regroupement logique d'une ou plusieurs requêtes http. Les requêtes peuvent être dynamiques et/ou statiques. Ensemble, ces requêtes constituent généralement une opération utilisateur, par exemple :
- Le chargement de l'application web
- Une action de navigation comme un panoramique ou un zoom
- Une fonction de recherche
- Création d'une nouvelle version SDE dans une GeoDatabase Enterprise
Il n'est pas techniquement obligatoire d'utiliser des transactions dans un test, mais cela peut grandement améliorer l'analyse car les opérations individuelles (par exemple les transactions) pourraient alors être isolées pour montrer leurs comportements respectifs en termes de performance tout au long de l'exécution. Cela peut être très instructif.
Comprendre que seules les requêtes pour l'échelle de carte 1:72 224 ont eu des problèmes de performance est très utile du point de vue de l'optimisation car vous sauriez exactement quelles zones du document ou projet cartographique devraient être
ajustées... les transactions peuvent vous aider à accomplir cela.
Transaction Apache JMeter contenant trois requêtes d'une opération :
Test
Aussi appelé plan de test ou projet de test
Le terme "test" est assez générique et est souvent utilisé à la fois comme nom (j'ai créé un test pour appeler la ressource) et comme verbe (je vais tester le service). Les transactions et les requêtes sont généralement définies dans un test. Le test aura des options supplémentaires à configurer telles que : combien de temps le test va durer, où vont les résultats, si des métriques sur les serveurs distants doivent être collectées.
Différents frameworks utilisent une terminologie légèrement différente pour décrire un test. Dans le cas d'Apache JMeter, un test ou projet de test s'appelle un Plan de Test et est désigné par une extension de fichier *.jmx.
Charge par paliers
Aussi appelée charge
La charge par paliers est une caractéristique qui définit combien de temps et combien de threads de test simultanés appliquer pendant le test via une pression progressive régulière (par exemple similaire à un escalier). Configurer le test pour une charge par paliers est utile pour comprendre comment un service de carte fonctionne ou évolue ou comment les ressources déployées se comportent
à mesure que de plus en plus de requêtes lui sont envoyées. La pression définie peut aussi diminuer (vers la fin du test) mais ce n'est pas obligatoire.
Groupe de Threads Apache JMeter (bzm - Concurrency) spécifiant et visualisant une charge par paliers spécifique :
Charge constante
Une charge constante définit également combien de temps et combien de threads de test appliquer mais est généralement réglée pour un taux stable sur de longues périodes. Au lieu de se concentrer sur la performance et la scalabilité, cette configuration sert typiquement à comprendre la durabilité et la stabilité.
Groupe de Threads Apache JMeter (bzm - Concurrency) spécifiant et visualisant une charge constante spécifique :
Threads de test
Aussi appelés threads
Ce mécanisme est responsable d'appliquer la charge en prenant le travail défini à effectuer dans le test tel que les transactions et/ou requêtes et en les exécutant répétitivement.
Les threads de test se comportent généralement en série où chaque thread commence par lire la première requête définie dans le test, l'envoie au serveur puis attend sa réponse. La requête suivante dans le test ne sera pas émise tant qu'une réponse ne revient pas du serveur ou qu'un délai d'attente n'a pas expiré. Une fois qu'une de ces conditions est remplie, il passe à la requête suivante. La plupart des tests sont configurés pour que chaque thread répète ce processus continuellement pendant toute la durée du run.
Différentes technologies désignent souvent les threads de test comme des utilisateurs virtuels mais cela peut prêter à confusion. Les threads d'un test ne sont que le moyen (pression) vers une fin (débit délivré).
En d'autres termes, l'exécution d'un test configuré avec une charge par paliers atteignant 100 threads ne signifie pas que l'environnement supporte 100 utilisateurs virtuels simultanés. Dans ce cas, déterminer les utilisateurs serait calculé à partir du débit du test ; transactions/sec, par exemple.
Groupe de Threads Apache JMeter (bzm - Concurrency) définissant la charge par paliers via des threads (de test) :
Utilisateurs
Aussi appelés utilisateurs virtuels
Le nombre d'utilisateurs supportés est l'un des éléments les plus demandés à déterminer lors d'un test de charge et prend généralement la forme suivante :
- Combien d'utilisateurs ce service ou application spécifique peut-il supporter ?
- Un service ou application particulier pourra-t-il supporter au moins X utilisateurs ?
Le calcul des utilisateurs est étroitement lié au temps de réflexion ainsi qu'aux artefacts mesurés du test tels que le débit et le temps de réponse.
L'utilisation de la Little Law avec ces entrées peut fournir une estimation théorique du nombre d'utilisateurs qu'un environnement peut supporter.<\/P>
Temps de réflexion<\/STRONG>
Également connu sous le nom de rythme de workflow<\/STRONG><\/EM><\/H5>Le temps de réflexion est une durée (définie en secondes ou millisecondes) qui est ajoutée dans un test pour simuler les délais du comportement humain qui se produiraient lorsqu'une personne interagit naturellement avec le service de carte ou l'application web.
Les délais de temps de réflexion peuvent être ajoutés aux transactions (par exemple une opération) ou aux requêtes, voire au test lui-même (ce qui est alors appelé rythme de workflow). La manière dont ils sont ajoutés peut varier en fonction du cadre de test utilisé.
Dans le cas d'Apache JMeter, plusieurs minuteries différentes sont disponibles et peuvent être ajoutées au test pour simuler divers types de délais.<\/P>Indicateurs clés de performance (KPIs)<\/STRONG><\/H5>Les KPIs sont des métriques de test qui aident à l'analyse d'un test de charge. Certains des plus populaires sont associés à la mesure du temps de réponse et du débit du test. Cependant, ils s'étendent également à des éléments qui comptent le nombre de requêtes échouées, calculent la longueur moyenne du contenu (par requête) ou collectent des informations sur l'utilisation du matériel (comme le CPU, la mémoire, le réseau et le disque).
Bien que la capacité à capturer l'utilisation du matériel nécessite souvent une configuration supplémentaire du test et des autorisations dans l'environnement, cette information est l'un des artefacts les plus importants capturés lors d'un test de charge.<\/P>Note : L'utilisation capturée du matériel est l'un des artefacts les plus importants capturés lors d'un test de charge.<\/FONT><\/STRONG><\/P>Temps de réponse<\/STRONG><\/H5>Le temps de réponse est une métrique courante utilisée pour mesurer la performance d'une requête, transaction ou test. En termes simples, il fournit une compréhension de la rapidité avec laquelle une opération se comporte.
La valeur est généralement présentée en secondes ou millisecondes. Une performance plus rapide signifie des temps de réponse plus bas, ce qui se traduit par une expérience utilisateur plus favorable. Le temps de réponse peut être tracé sur la durée du test pour comprendre comment la performance a évolué ou listé avec le débit pour un point particulier du test (par exemple là où le débit a atteint son pic).<\/P>Note : Les temps de réponse sont l'un des artefacts les plus importants capturés lors d'un test de charge.<\/STRONG><\/FONT><\/P>Idéalement, la performance de l'élément testé prendra la courbe suivante où les temps de réponse augmenteront plus rapidement (autour du point de débit maximal). Dans l'exemple suivant, le temps moyen de réponse par requête au débit maximal était d'environ 0,4 seconde.<\/P>
<\/span><\/P>Débit<\/STRONG> :<\/H5>Le débit est une métrique courante utilisée pour mesurer l'évolutivité d'un service cartographique, d'une application web ou d'une infrastructure matérielle. Essentiellement, il fournit une compréhension du taux auquel une opération peut être effectuée sur une durée donnée.
La valeur peut généralement être capturée en requêtes/sec, transactions/sec (par exemple opérations/sec) ou tests/sec, bien qu'elle soit souvent exprimée sur la durée d'une heure (le taux en secondes multiplié par 3600).
Une évolutivité plus élevée signifie un débit plus important ce qui se traduit par un support pour plus d'utilisateurs.
Certaines analyses de test se concentreront sur le débit moyen de toutes les transactions pour un test, tandis que d'autres examineront le débit moyen pour chaque opération individuelle.<\/P>Note : Le débit est l'un des artefacts les plus importants capturés lors d'un test de charge.<\/STRONG><\/FONT><\/P>Idéalement, le débit de l'élément testé ressemblera à la courbe suivante où il atteint un pic puis se stabilise. <\/SPAN>Lorsque le débit atteint un pic et\/_ou se stabilise, cela suggère que le test a rencontré une forme d'engorgement. Dans l'exemple suivant, le débit moyen des requêtes au pic était d'environ 24 requêtes/seconde (ou 86 400 requêtes/heure).<\/P>
<\/span><\/P>Engorgement<\/STRONG><\/H5>Un engorgement est une condition dans un déploiement où l'un des composants ou niveaux limite le taux auquel il peut répondre aux requêtes entrantes. Un engorgement peut prendre la forme suivante :<\/P>Exemples matérielsTous les cœurs CPU d'ArcGIS Server sont entièrement utilisés<\/LI>La mémoire disponible est épuisée<\/LI>L'entrée-sortie disque du serveur base de données est entièrement utilisée<\/LI>La carte réseau est saturéeEn raison du trafic envoyé ou reçu <\/LI><\/UL><\/LI><\/UL><\/LI>Exemples logicielsLa base de données a été configurée pour n'autoriser que 25 connexions simultanées malgré des ressources matérielles suffisantes disponibles<\/LI>Le débit pour consommer un service cartographique plafonne mais l'utilisation CPU d'ArcGIS Server ne dépasse pas 25 %<\/LI><\/UL><\/LI><\/UL>Un engorgement existera toujours dans un déploiement et déterminer quel composant sera limité en premier fait partie de l'analyse. Il faudra souvent un test de charge pour révéler où se produira le premier engorgement car il peut n'être observé que sous une forte pression. Bien que les ressources et paramètres serveur soient généralement au centre de l'analyse des engorgements, les ressources client du test (CPU, mémoire, réseau, disque et dans certains cas la licence testing) peuvent aussi être un facteur. Atteindre un engorgement n'est pas nécessairement un problème, cela indique simplement où se trouve la première faiblesse ou limitation dans le système. Parfois, un engorgement est considéré comme une « bonne chose », par exemple lors d'un grand processus ArcGIS caching, il est souhaitable que le CPU devienne le premier engorgement car il effectue le travail pour créer les tuiles cartographiques. Si le CPU ne peut atteindre que 50 % à cause d'un autre engorgement (par exemple I/O disque), cela prendra deux fois plus longtemps pour terminer la tâche par rapport à une utilisation CPU à 100 %.<\/P>Note : Un engorgement existe toujours dans un déploiement<\/STRONG><\/FONT><\/P>Type de test<\/STRONG>
Également connu sous les noms performance test, load test, stress test, endurance test, benchmark test<\/STRONG><\/EM><\/H5>De nombreuses organisations utilisent souvent différentes catégories pour classifier les tests réalisés.<\/P>Un performance test est typiquement utilisé pour dépanner des problèmes avec un service ou une application lorsqu'il fonctionne lentement ou produit des temps de réponse plus longs que prévu. Ils ne nécessitent pas forcément une charge progressive et peuvent être exécutés facilement comme un utilisateur unique interagissant directement depuis un navigateur web avec le point final concerné.<\/P>Un load test peut souvent décrire un step load test avec pour objectif d'atteindre un certain débit et temps de réponse. Par exemple, X transactions/sec<\/EM> avec un temps de réponse inférieur à Y secondes<\/EM> et sans échecs. Cela pourrait entraîner l'épuisement d'une ressource matérielle serveur mais ce n'est généralement pas l'objectif. Un load test peut aussi être appelé scalability test.<\/P>Un stress test est similaire mais vise fréquemment à atteindre une pression qui est un multiple de celle visée par le load test. En d'autres termes, si le load test essayait d'atteindre X transactions/sec<\/EM>, le stress test pourrait essayer d'atteindre X * 5 transactions/sec<\/EM> sans rencontrer un nombre significatif d'échecs.<\/P>Un endurance test a la particularité d'essayer d'endommager<\/_EM> les composants du système. Sa charge appliquée peut être un multiple celle du stress test où l'objectif est d'observer des erreurs significatives et observer le débit et temps de réponse lorsqu'elles surviennent. Un endurance test peut aussi être appelé durability test où la charge appliquée est constante pendant très longtemps et où les schémas d'utilisation et récupération matérielle sont observés.<\/P>Plan de test<\/STRONG><\/H5>Au sens général, un plan de test est document, tableau ou liste qui définit les tests spécifiques qui seront exécutés ainsi que leurs objectifs respectifs. Ces objectifs sont la raison et le but de chaque test. L'analyse des résultats (manuellement ou à partir des rapports de test générés) devrait vous aider à déterminer si les objectifs de chaque test ont été atteints.<\/P>Framework de Test <\/STRONG><\/H5>Le framework de test est l'outil ou la technologie utilisée sous forme de bibliothèques, d'APIs ainsi qu'une interface utilisateur graphique (GUI) pour assembler les requêtes, et le test ainsi que définir la charge à appliquer.
Il existe de nombreux excellents frameworks de test et Apache JMeter n'en est qu'un<\/EM>. Bien qu'ils aient tous un but similaire, beaucoup d'entre eux adoptent des approches différentes concernant le vocabulaire de certains composants et la manière dont ils créent un test et appliquent la charge. Certains placent la définition des requêtes et transactions dans leurs propres fichiers avec la configuration de la charge par étapes dans un autre.
Avec Apache JMeter, tous les objets du test sont définis dans le Plan de Test et sont logiquement séparés dans l'arborescence.<\/P>Quelques exemples de frameworks de test de charge :<\/P>Apache JMeter<\/A> <\/LI>LoadRunner<\/A> <\/LI>Silk Performer<\/A> <\/LI><\/UL>Quelques exemples de frameworks de test de performance :<\/P>
wget<\/A>- Un outil en ligne de commande pour récupérer une ou plusieurs URLs<\/LI>
- Peut fournir un niveau élevé de détail sur chaque requête et réponse<\/LI><\/UL><\/LI>
curl<\/A>
- Un outil en ligne de commande pour récupérer une ou plusieurs URLs<\/LI>
- Peut fournir un niveau élevé de détail sur chaque requête et réponse<\/LI><\/UL><\/LI>
Fiddler<\/A>- Débogueur HTTP basé sur GUI qui peut être utilisé seul ou avec un navigateur web<\/LI>
- Peut fournir un niveau élevé de détail sur chaque requête et réponse<\/LI><\/UL><\/LI><\/UL>
Architecture du Framework de Test<\/STRONG><\/H5>Lors des tests d'ArcGIS Enterprise, la majeure partie de l'attention architecturale se concentre autour de l'évolutivité des niveaux de déploiement : Load Balancer, Web Adaptor, Portal for ArcGIS, ArcGIS DataStore, ArcGIS Server, Enterprise Geodatabase et Network Storage. Alors qu'une machine de test 8 Core peut généralement envoyer une quantité raisonnable de requêtes qui peuvent satisfaire le test typique, parfois plusieurs machines sont nécessaires si la charge à appliquer nécessite une puissance sérieuse.<\/P>Selon le framework de test impliqué, plusieurs composants du test peuvent être séparés sur différentes machines pour améliorer l'évolutivité du test client<\/EM>.<\/P>Les composants communs à étendre sont :<\/P>Contrôleur de TestComme son nom l'indique, le rôle principal du contrôleur est d'arrêter et démarrer le test ainsi que coordonner la collecte des métriques du test depuis un ou plusieurs Agents de Test<\/LI>Dans le cas d'Apache JMeter, le contrôleur est intégré directement dans la GUI mais fonctionne aussi lorsque le test est exécuté depuis la ligne de commandeD'autres frameworks peuvent avoir une interface web pour le Contrôleur de Test<\/LI><\/UL><\/LI>Typiquement, un seul Contrôleur de Test est nécessaire pour tout environnement donné, mais il peut fonctionner sur un matériel dédié séparé des Agents de Test<\/LI><\/UL><\/LI>Agent de TestLe travail principal de l'Agent de Test est d'envoyer les requêtes et recevoir les réponses du serveurCe composant effectue la majeure partie du travail et nécessiterait le plus de ressources CPU<\/LI><\/UL><\/LI>Pour les gros travaux, plusieurs machines Agent de Test pourraient être nécessaires<\/LI>Dans le cas d'Apache JMeter, par défaut, l'Agent de Test fonctionne sur la même machine que le Contrôleur de Test <\/LI><\/UL><\/LI>Dépôt du TestUne machine dédiée au stockage des résultats du test de charge Cela peut inclure des métriques comme le temps de réponse, le débit et l'utilisation matérielle<\/LI><\/UL><\/LI>Dans le cas d'Apache JMeter, les résultats sont stockés sur le contrôleur dans des fichiers texte (*.JTL)Il est possible d'envoyer les résultats vers une base de données, mais ce n'est pas le comportement par défaut<\/LI><\/UL><\/LI><\/UL><\/LI>Visualisation du TestUne machine utilisée pour visualiser les métriques du test et l'utilisation matérielle en temps réel<\/LI>Dans le cas d'Apache JMeter, la GUI n'est pas recommandée pour la visualisation des données lors d'un test en production mais la ligne de commande l'estSi les résultats sont envoyés à une base de données, un logiciel supplémentaire peut se connecter au Dépôt du Test pour visualiser l'information<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>Loi du Temps de Réponse Interactif<\/STRONG><\/H5>La Loi du Temps de Réponse Interactif est une formule qui définit la relation entre les facteurs clés de performance, à savoir les utilisateurs, le débit, le temps de réponse et le temps réflexif utilisateur. Le calcul peut être arrangé pour déterminer le paramètre d'intérêt tant que vous connaissez les trois autres. Par exemple, si le nombre d'utilisateurs utilisant le système est connu, quel est le temps moyen de réponse pour les requêtes, et le temps réflexif moyen utilisateur, nous pouvons alors dériver la demande estimée en débit sur le système. Cette loi est très utile lorsqu'on tente de convertir utilisateurs en débit et débit en utilisateurs ainsi que pour d'autres cas d'utilisation et elle est fondamentale dans des domaines liés aux tests tels que la planification capacitaire.<\/P>Étant donné la formule suivante :
N = X * (R + Z)<\/P>N = Nombre d'opérations ou utilisateurs concurrents
X = Débit par seconde dans le système
R = Temps de réponse, ou temps moyen qu'une opération passe dans le système
Z = Temps réflexif<\/P>Pour plus d'informations sur la Loi du Temps de Réponse Interactif voir :<\/P>http:\/\downloads.esri.com\/_Support\/_downloads\/_other_\/_ArcGIS%20Enterprise%20deployment%20guide_Scene%20layer%20benchmark%20testing.pdf<\/A>
https://homepages.inf.ed.ac.uk/jeh/biss2013/Note2.pdf
<\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/>
Apache JMeter
publié sous
Apache
Licence 2.0.
Apache, Apache JMeter, JMeter, la plume Apache et le logo Apache JMeter sont des marques déposées par la Fondation Apache Software.
