Créer un test de charge dans Apache JMeter contre un service de carte mis en cache (Avancé)

AaronLopez

Pourquoi tester <\/SPAN>un service de carte en cache?<\/SPAN><\/H1>Les services de carte en cache sont une méthode populaire et recommandée pour fournir une présentation performante de données statiques. Le type de service en cache est une technologie éprouvée, mais il peut encore être nécessaire de le tester sous charge afin d'observer sa scalabilité directement sur une architecture de déploiement spécifique. Bien que les services de carte en cache offrent de bonnes performances, servir des milliers de <\/SPAN>requêtes simultanées de tuiles peut être gourmand en ressources matérielles du serveur.<\/SPAN><\/P>Note : En raison du rythme rapide de livraison et de consommation des ressources, le test de charge des services de carte en cache peut également être intensif sur l'utilisation matérielle du poste client de test.<\/STRONG><\/FONT><\/P>Défis du test des services de carte en cache<\/SPAN><\/H1>Comparé au test de charge de la fonction d'exportation de carte, un test approprié<\/EM> d'un service de carte en cache introduit plusieurs défis car la composition des requêtes change à chaque écran de carte. Puisque le schéma sous-jacent du cache utilise un design en grille, les étendues cartographiques de certains panoramiques ou zooms peuvent récupérer plus ou moins d'images de tuiles que d'autres. Prendre en compte ce comportement réel du service en cache rend la logique du test plus complexe que si l'on testait la fonction d'exportation de carte.<\/SPAN><\/P>La logique du test doit également être dynamique et couvrir une zone d'intérêt décente. Convertir un fichier HAR des requêtes capturées des tuiles du cache en un test peut être rapide et facile, mais ne montre pas une scalabilité réaliste du service. Cela est dû au petit échantillon des requêtes de tuiles utilisées encore et encore.<\/SPAN><\/P>De manière générale, les requêtes pour des tuiles individuelles du cache sont rapides...très<\/EM> rapides. En raison de ce comportement, la logique du test doit aussi bien fonctionner, évoluer avec le service et avoir <\/SPAN>un minimum d'overhead sur le client de test.<\/SPAN><\/P>Comment tester un <\/SPAN>service de carte en cache?<\/SPAN><\/H1>Les étapes dans cet article devraient fonctionner avec n'importe quel service de carte en cache existant sur votre déploiement local ArcGIS Enterprise. Cependant, si aucun n'est disponible, il est recommandé d'examiner le jeu de données Natural Earth pour cette tâche.<\/SPAN><\/P>Le jeu de données Natural Earth<\/H2>Bien que les étapes devraient fonctionner avec n'importe quelles données, le parcours du processus dans cet article pourrait être plus efficace s'il peut être suivi directement. Dans ce cas, il est idéal de se tourner vers les jeux de données Natural Earth<\/A>, qui fournissent un bon niveau de détail cartographique (à plus petites échelles) couvrant le monde entier.<\/SPAN><\/P>

Téléchargez ici le jeu Natural Earth<\/A><\/STRONG> 

• Le téléchargement<\/SPAN> ci-dessus est un sous-ensemble du plus grand <\/LI>

Natural_Earth_quick_start.zip<\/A> et inclut un MXD modifié pour ArcMap 10.8.1 et un projet ArcGIS Pro 2.8

• L'un ou l'autre peut être utilisé pour publier et créer un service de carte en cache dans ArcGIS Enterprise<\/SPAN><\/LI><\/UL><\/LI><\/UL><\/LI>Le sous-ensemble Natural Earth devrait ressembler à ce qui suit lorsqu'il est ouvert dans ArcGIS Pro (ou ArcMap)<\/SPAN><\/LI><\/UL><\/span><\/SPAN><\/P>Cet article ne couvrira pas<\/EM> <\strong>les détails sur la création, la configuration ou la publication d'un service de carte en cache dans ArcGIS Enterprise. 
  Pour ces informations, voir :

Tutoriel : Création d'un service de carte en cache<\/A>  
Note : Il est recommandé de se familiariser avec certains détails des métadonnées du service de carte en cache car l'effort du test sous charge nécessitera la connaissance d'informations telles que xorigin, yorigin, tileCols, tileRows, la référence spatiale ainsi que les échelles contenant des tuiles.
Génération des données de test<\span>


Avec un service de carte en cache disponible, l'étape suivante serait de générer des données de test sur une zone d'intérêt.




Comme pour d'autres articles JMeter sur Community, nous avons besoin de bonnes données pour tirer le meilleur parti des résultats. Et comme auparavant, le



Load Testing Tools



pour ArcGIS Pro facilite grandement cette tâche. Il existe même un outil spécifique pour créer des boîtes englobantes à utiliser avec les services cartographiques en cache.




Note : La version 1.3.0 des Load Testing Tools a ajouté l'outil "Generate Bounding Boxes (Precision)".




Téléchargez et décompressez le package puis rendez ce dossier accessible à votre projet ArcGIS Pro.



L'outil Generate Bounding Boxes (Precision)



Lancer l'outil Generate Bounding Boxes (Precision) devrait présenter une interface similaire à celle-ci :






Avant d'exécuter l'outil, ajustons les entrées pour cibler le processus de génération des données vers :

Des échelles cartographiques spécifiques (dans ce cas trois échelles différentes)

Les échelles 4622324.434309 et 1155581.108577 ont été conservées

L'échelle 2311162.217155 a été ajoutée

Le nombre d'enregistrements à générer a été ajusté pour refléter des échelles cartographiques plus grandes

À mesure que le numéro d'échelle diminue, nous voulons que l'outil génère plus de boîtes

Une zone d'intérêt spécifique (optionnelle)


Un polygone des États-Unis a été ajouté à une nouvelle carte

Cet élément a été défini comme Polygone Contraignant





Cliquez sur Exécuter

L'exécution de l'outil peut prendre quelques instants

Visualisation des données générées dans ArcGIS Pro


L'écran Contenu se remplira en ajoutant une nouvelle classe d'entités représentant visuellement les données générées

Toutes les échelles cartographiques générées ne seront pas immédiatement visibles




Visualisation des données générées dans un éditeur texte


En utilisant l'explorateur système, naviguez jusqu'au projet ArcGIS Pro utilisé pour générer les données et ouvrez l'un des fichiers csv avec votre éditeur texte préféré

Le contenu du fichier devrait ressembler à ceci :





Le test Apache JMeter sera configuré pour convertir chacune de ces boîtes englobantes en tuiles correspondantes du cache map

Plan de test du service de carte en cache 

• Téléchargez le plan de test Apache JMeter utilisé dans cet article ici : cache_tiles1.zip 
  
• L'ouverture du plan dans Apache JMeter devrait ressembler à ceci :
  • Ajustez les variables définies par l'utilisateur pour correspondre à votre environnement
    • Xorigin, Yorigin, TileCols, TileRows sont des propriétés du cache de carte créé que l'on peut trouver sur la page de point de terminaison REST du service
      • TileCols et TileRows se trouvent généralement sous Tile Info Height et Width

Composants du Plan de Test

Configuration du Jeu de Données CSV

Les éléments CSV Data Set Config dans JMeter sont utilisés pour référencer les nouvelles données de test générées depuis le système de fichiers. La version actuelle du Plan de Test est conçue pour utiliser 3 fichiers CSV différents (un pour chaque fichier de données d'échelle de carte).

Note : À part les Variables Définies par l'Utilisateur et le paramétrage du Nom de Fichier dans les éléments CSV Data Set Config, il ne devrait rien y avoir d'autre à éditer ou modifier dans le Plan de Test. La logique du test est listée ci-dessous juste pour expliquer comment les valeurs dans la Requête HTTP sont remplies.

Logique de la Liste des Niveaux de Détail

Pour éviter une logique de test JMeter plus complexe, 24 niveaux fixes de cache de carte sont placés à l'intérieur d'une classe dans un élément test JSR223 Sampler. Cette "alternative complexe" consisterait à connecter le point de terminaison du service au début du test et récupérer les métadonnées des tuiles du cache. Mettre la logique HTTP dans des JSR223 Samplers est techniquement faisable, mais ce n'est pas la voie que j'ai choisie.

• Il n'y a qu'un seul JSR223 Sampler à l'intérieur de la Transaction Levels Of Detail
• Cet élément est exécuté une seule fois, au début de chaque thread de test
  • L'élément contient 24 niveaux fixes de cache, avec le niveau 0 commençant à l'échelle 591657527.591555
    • Si votre schéma de cache commence à une échelle différente pour 0, alors le JSR223 Sampler devra être ajusté manuellement
• Ce JSR223 Sampler n'a pas besoin d'être édité pour exécuter le test
  • Cela suppose que le service de carte en cache a une Référence Spatiale de 102100 (3857)

Niveaux De Détail -- JSR223 Sampler (Logique Complète) :

 

 

 

 

 

// Classe FileServer
import org.apache.jmeter.services.FileServer

public class Lod{
   int level
   double resolution
   double scale
   double tolerance 
}

public class MyLodList1{
	public List<Lod> LodList = new ArrayList()	
	
	MyLodList1(){
		// Basé sur les Échelles Cartographiques ArcGIS Online
		// https://services.arcgisonline.com/arcgis/rest/services/World_Street_Map/MapServer
		//
		// Référence Spatiale : 102100 (3857)
		Lod lod = new Lod()

		lod = new Lod()
		lod.level = 0
		lod.resolution = 156543.03392800014 //11
		lod.scale = 591657527.591555
		lod.tolerance = 0.5
		this.LodList.add(lod)
		
		lod = new Lod()
		lod.level = 1
		lod.resolution = 78271.51696399994 //11
		lod.scale = 295828763.795777
		lod.tolerance = 0.5
		this.LodList.add(lod)
		
		lod = new Lod()
		lod.level = 2
		lod.resolution = 39135.75848200009 //11
		lod.scale = 147914381.897889
		lod.tolerance = 0.25
		this.LodList.add(lod)
		
		lod = new Lod()
		lod.level = 3
		lod.resolution = 19567.87924099992 //11
		lod.scale = 73957190.948944
		lod.tolerance = 0.5
		this.LodList.add(lod)
		
		lod = new Lod()
		lod.level = 4
		lod.resolution = 9783.93962049996 //11
		lod.scale = 36978595.474472
		lod.tolerance = 0.5
		this.LodList.add(lod)
		
		lod = new Lod()
		lod.level = 5
		lod.resolution = 4891.96981024998 //11
		lod.scale = 18489297.737236
		lod.tolerance = 0.5
	the.LodList.add(lod)
    
    lod = new Lod()
    lod.level = 6
    lod.resolution = 2445.98490512499 //11
    lod.scale = 9244648.868618
    lod.tolerance = 0.5
    this.LodList.add(lod)
    
    lod = new Lod()
    lod.level = 7
    lod.resolution = 1222.9924525624949 //13
    lod.scale = 4622324.434309
    lod.tolerance = 0.5
    this.LodList.add(lod)
    
    lod = new Lod()
    lod.level = 8
    lod.resolution = 611.49622628137968 //14
    lod.scale = 2311162.217155
    lod.tolerance = 0.5
    this.LodList.add(lod)

    lod = new Lod()
    lod.level = 9
    lod.resolution = 305.74811314055756 //14
    lod.scale = 1155581.108577
    lod.tolerance = 0.5
    this.LodList.add(lod)

    lod = new Lod()
    lod.level = 10
    lod.resolution = 152.87405657041106 //14
    lod.scale = 577790.554289
    lod.tolerance = 0.5
    this.LodList.add(lod)

    lod = new Lod()
    lod.level = 11
    lod.resolution = 76.437028285073239 //15
    lod.scale = 288895.277144
    lod.tolerance = 0.5
    this.LodList.add(lod)

    lod = new Lod()
    lod.level = 12
    lod.resolution = 38.21851414253662 //14
    lod.scale = 144447.638572
    lod.tolerance = 0.5
    this.LodList.add(lod)

    lod = new Lod()
    lod.level=13 
   	lod.resolution=19.10925707126831 //15 
lod.scale=72223.819286 
lod.tolerance=0.5 
th.is.LodList.add(lod) 
 
lod=new Lod() 
lod.level=14 
lod.resolution=9.5546285356341549 //16 
lod.scale=36111.909643 
lod.tolerance=0.5 
th.is.LodList.add(lod) 
 
lod=new Lod() 
lod.level=15 
lod.resolution=4.77731426794937 //14 
lod.scale=18055.954822 
lod.tolerance=0.05 
th.is.LodList.add(lod) 
 
lod=new Lod() 
lod.level=16 
lod.resolution=2.388657133974685 //15 
lod.scale=9027.977411 
lod.tolerance=0.025 
th.is.LodList.add(lod) 
 
l.od=new Lod() 
l.od.level=17 
l.od.resolution=1 .1943285668550503 //16 
l.od.scale=4513 .988705 
l.od.tolerance=0 .025 
th.is.L.odList.add(l.od) 		nl.od=new L.od() nl.od.level=18 nl.od.resolution=0 .5971642835598172 //16 nl.od.scale=2256 .994353 nl.od.tolerance=0 .005 nth.is.L.odList.add(l.od) nl.od=new L.od() nl.od.level=19 nl.od.resolution=0 .29858214164761665 //17 nl.od.scale=1128 .497176 nl.od.tolerance=0 .005 nth.is.L.odList.add(l.od) nl.od=new L.od() nl.od.level=20 nl.od.resolution=0 .14929107082380833 //17 nl.od.scale=564 .248588 nl.od.tolerance=0 .0025 nth.is.L.odList.add(l.od) nl.od=new L.od() nl.od.level=21 nl.od.resolution=0 .07464553541190416 //17 nl.od.scale=282 .124294 nl.od.tolerance=0 .0005 nth.is.L.odList.add(l.od) nl.od=new L.od() nl.od.level=22 nl.od.resolution=0 .03732276770595208 //17 nl.od.scale=141 .062147 nl.od.tolerance=0 .0005 nth.is.L.odList.add(l.od) nl.od=new L.od() nl.od.level=23 nl.od.resolution=0 .01866138385297604 //17 nl.od.scale=70 .5310735 nl.od.tolerance=0 .0005 nth.is.L odList.add(l od) } } MyL odList1 myl ods=new MyL odList1() List<L od>L odList=myl ods.L odList vars.putObject("L odList",L odList)

 

 

 

 

 

Logique GetMapTile

Les JSR223 Samplers à l'intérieur de la Transaction GetMapTile sont la logique responsable de prendre une boîte englobante et la transformer en tuiles correspondantes du cache. 

• Il y a un JSR223 Sampler pour chaque échelle de carte (par exemple un pour chaque CSV Data Set Config correspondant)
  • CSV Data Set Config A --> JSR223 Sampler A1
• Ceci est exécuté à chaque itération du thread de test
  • Ceci est exécuté fréquemment... chaque fois qu'une nouvelle boîte englobante est lue
• Ces JSR223 Samplers n'ont pas besoin d'être édités pour exécuter le test

Note : Les JSR223 Samplers utilisant Groovy s'exécutent généralement rapidement et ajoutent très peu de surcharge au test

 GetMapTile -- JSR223 Sampler A1 (Logique Complète) :

 

 

 

 

 

// Script pour traiter un fichier CSV (depuis Load Testing Tools) avec des lignes au format suivant :
// bbox,width,height,mapUnits,sr,scale
// Classe FileServer
import org.apache.jmeter.services.FileServer;
import org.apache.commons.math3.util.Precision;
//import java.math.BigDecimal;
// GetMapTile     
bbox_var = vars.get("bbox_A");
String[] bboxParts = bbox_var.split(',');
double xmin = Double.parseDouble(bboxParts[0]);
double ymin = Double.parseDouble(bboxParts[1]);
double xmax = Double.parseDouble(bboxParts[2]);
double ymax = Double.parseDouble(bboxParts[3]);
width_var = vars.get("width_A");
height_var = vars.get("height_A");
// Utiliser la résolution d'échelle cartographique (unités cartographiques par pixel) pour déterminer le niveau de tuile
double mapresolution = 0;
int resolutionprecision =10;
mapresolution=Precision.round((Math.abs(xmax - xmin)/Double.parseDouble(width_var)), resolutionprecision);
scale_var=vars.get("scale_A");
double  bbox_scale_double = Double.parseDouble(scale_var)

// Unités de la carte par pixel
double tileresolution = 0
double lod_resolution = 0
double scale = 0
int tilelevel = 0
LodList = vars.getObject("LodList") // En supposant que le service de carte mis en cache a une référence spatiale de 102100 (3857)
boolean firstIteration = true;
for(int i = 0; i < LodList.size; i++)
{
     lod_resolution = Precision.round(LodList[i].resolution, resolutionprecision)
	tileresolution = lod_resolution
	tilelevel = LodList[i].level
	scale = LodList[i].scale		
	
     if (mapresolution >= lod_resolution)
     {
     	break
	}
}

tileCols_var = vars.get("TileCols")
cols = Double.parseDouble(tileCols_var)
tileRows_var = vars.get("TileRows")
rows = Double.parseDouble(tileRows_var)
// Origine du cache (coin supérieur gauche)
xorigin_var = vars.get("Xorigin")
xorigin = Double.parseDouble(xorigin_var)
yorigin_var = vars.get("Yorigin")
yorigin = Double.parseDouble(yorigin_var)

// Obtenir la colonne de tuile minimale
double minxtile = (xmin - xorigin) / (cols * tileresolution)
// Obtenir la ligne de tuile minimale
// Depuis l'origine, maxy est y minimum
double minytile = (yorigin - ymax) / (rows * tileresolution)
// Obtenir la colonne de tuile maximale
double maxxtile = (xmax - xorigin) / (cols * tileresolution)
// Obtenir la ligne de tuile maximale
// Depuis l'origine, miny est y maximum
double maxytile = (yorigin - ymin) / (rows * tileresolution)

// Retourner la valeur entière pour min et max, ligne et colonne
int mintilecolumn = (int)Math.floor(minxtile)
int mintilerow = (int)Math.floor(minytile)
int maxtilecolumn = (int)Math.floor(maxxtile)
int maxtilerow = (int)Math.floor(maxytile)

Scheme_var = vars.get("Scheme")
WebServerName_var = vars.get("WebServerName")
ServerInstanceName_var = vars.get("ServerInstanceName")
ServiceName_var = vars.get("ServiceName")
ServiceType_var = vars.get("ServiceType")
def cacheRequest
def tilePaths = []
int count = 0
for (int row = mintilerow; row <= maxtilerow; row++)
{
	// pour chaque colonne dans la ligne, dans l'étendue de la carte
     for (int col = mintilecolumn; col <= maxtilecolumn; col++)
     {
          cacheRequest = ("/").concat(ServerInstanceName_var).concat("/rest/services/").concat(ServiceName_var).concat("/").concat(ServiceType_var)
          cacheRequest = cacheRequest.concat("/tile").concat("/").concat(tilelevel.toString()).concat("/").concat(row.toString()).concat("/").concat(col.toString())
          count++
          tilePaths.add(cacheRequest)
     }
}


def requestCount = count.toString()
vars.putObject("RequestCount_A",requestCount) 
vars.putObject("TilePaths_A",tilePaths)

 

 

 

 

 

Boucle des tuiles Cache et peuplement des chemins

Plusieurs composants sont nécessaires pour cette partie du Plan de Test. Avec la bounding box traduite en tuiles cache correspondantes et assemblée en une liste d'URLs, un troisième JSR223 est nécessaire pour placer chaque URL dans une variable à l'intérieur d'une boucle. La logique de boucle se déroule à l'intérieur de la transaction Cache Tiles.

• Il y a un JSR223 Sampler pour chaque échelle de carte
  • CSV Data Set Config A --> JSR223 Sampler A2
• Ces JSR223 Samplers n'ont pas besoin d'être modifiés pour exécuter le test
• Un Loop Controller est ajouté pour ne demander que le nombre réel de tuiles par bounding box puisque ce nombre peut changer selon l'étendue
  • Le nombre de tuiles correspondant à chaque bounding box varie selon l'étendue mais aussi selon la résolution de la carte (1920x1080)
    • Des résolutions d'écran plus élevées nécessitent plus de tuiles
  • Le Loop Controller contient les éléments suivants :
  • Compteur
  • JSR223 Sampler
  • Requête HTTP

Loop Controller

Compteur

JSR223 Sampler

Requête HTTP

Toute la logique du test ci-dessus existe uniquement pour ce composant du test. Pour chaque échelle de carte, il n'y a qu'une seule Requête HTTP ! Ce design simple favorise la lisibilité et la maintenabilité.

Note : Les Requêtes HTTP contiennent un élément Response Assertion pour valider les éléments retournés par le serveur. Si le type de contenu de la réponse est image/jpeg ou image/png, alors la requête réussira. Cependant, certains caches VectorTileServer peuvent retourner un fichier Protocolbuffer Binary Format (*.pbf). Dans ces cas, les Patterns to Test devraient être manuellement étendus aux suivants : image/jpeg || image/png || application/octet-stream || application/x-protobuf

Configuration du Thread Group

Le Plan de Test JMeter est actuellement configuré pour un test relativement court de 20 minutes. Les services cartographiques mis en cache fonctionnent bien, donc beaucoup de débit aura lieu à chaque étape (2 minutes par étape) et sur l'ensemble du test.

• Différents environnements peuvent nécessiter une configuration alternative de pression pour atteindre les résultats souhaités, ajustez selon les besoins

Validation du Plan de Test

Comme bonne pratique, il est toujours conseillé de valider les résultats reçus avant d'exécuter le test de charge réel.

• Utilisez le listener View Results Tree pour aider à la validation
  • Le Plan de Test inclut un View Results Tree Listener mais il est désactivé par défaut
    • Activez-le pour voir les résultats
• Démarrez le test depuis l'interface graphique

Transactions

• Sélectionnez une des transactions "Cache Tiles"
  • Les résultats devraient ressembler à ce qui suit :

• Dans cet exemple, toutes les transactions se sont terminées avec succès (par ex. la coche verte)
  • Cache Tiles (échelle de carte : 4622324.434309)
  • Cache Tiles (échelle de carte : 2311162.217155)
  • Cache Tiles (échelle de carte : 1155581.108577)
• Sélectionner une des transactions et l'élément résultat Sampler liste quelques informations clés
  • Jetez un coup d'œil rapide à la taille en octets
    • Dans l'exemple ci-dessus, la taille de la transaction était supérieure à 50KB ce qui suggère que des données correctes des tuiles (pour ce jeu de données) étaient retournées et que les réponses n'étaient pas toutes des images "vides"
  • Le nombre d'échantillons dans la transaction était 80
    • Puisqu'il y a un JSR223 Sampler avec chaque requête de tuile, cela a en fait résulté en 40 tuiles téléchargées
  • Le temps de chargement montre 62 ms, ce qui signifie qu'il a fallu seulement 0,062 secondes pour télécharger 40 images tuiles

Requêtes

• Détendez la transaction sélectionnée
  • Dans cet exemple, Cache Tiles (échelle de carte : 1155581.108577)
• Sélectionnez une des requêtes HTTPS
  • Les résultats devraient ressembler à ce qui suit :

<\/span><\/SPAN><\/P>Dans cet exemple, la requête select s'est terminée <\/SPAN>avec succès (par exemple, la coche verte)<\/SPAN><\/LI>Jetez un coup d'œil rapide au temps de chargement<\/SPAN>Dans cet exemple, la requête individuelle de tuile n'a pris que 2 ms (0,002 secondes) pour se télécharger<\/SPAN><\/LI><\/UL><\/LI>Cliquez sur l'onglet Données de réponse pour prévisualiser la tuile demandée :<\/SPAN><\/LI><\/UL><\/span><\/SPAN><\/P>Note : Une fois la validation visuelle et le débogage terminés, il est recommandé de désactiver l'élément View Results Tree avant d'exécuter le test de charge<\/STRONG><\/FONT><\/P>Exécution du test<\/H1>Le test de charge doit être exécuté de la même manière qu'un plan de test JMeter typique.<\/P>Voir le script runMe.bat inclus dans le projet cache_tiles1.zip  pour un exemple sur la façon d'exécuter un test comme recommandé par Apache JMeter. <\/P>Le script runMe.bat contient une variable jmeterbin<\/EM> qui devra être définie à la valeur appropriée pour votre environnement<\/LI><\/UL>Note : Il est <\/SPAN>toujours recommandé<\/U><\/EM> <\/SPAN>de coordonner l'heure de début et la durée du test de charge avec le personnel approprié de votre organisation. Cela garantit un impact minimal sur les utilisateurs et les autres collègues qui pourraient également avoir besoin d'utiliser votre site ArcGIS Enterprise sur site. De plus, cela aide à prévenir le bruit système<\/EM> provenant d'autres activités et utilisations qui pourraient "polluer" vos résultats de test.<\/STRONG><\/FONT><\/P>Note : Pour plusieurs raisons, il est fortement conseillé de <\/SPAN>ne jamais effectuer de test de charge sur ArcGIS Online<\/EM><\/U>.<\/STRONG><\/FONT><\/P>Rapport JMeter<\/H1>Le rapport JMeter auto-généré peut fournir des informations sur le débit du service cartographique mis en cache sous chargeCe rapport est généré automatiquement à partir des options en ligne de commande passées depuis le script runMe.bat<\/LI><\/UL><\/LI><\/UL>Courbe de débit<\/H2>Le rapport JMeter pour un test de charge d'un service cartographique mis en cache peut sembler lent et peu réactif lorsqu'il est consulté dans un navigateur webCela est dû à la nature par défaut de sa composition, qui tente d'afficher chaque requête unique dans certains graphiquesDans un test comme celui-ci, il y en aura beaucoup<\/LI>Dans la légende du graphique, sélectionnez tous les éléments JSR223 Sampler pour désactiver leur rendu (car ils peuvent fausser l'échelle)<\/LI><\/UL><\/LI><\/UL><\/LI>Dans ce cas, le débit maximal pour l'une quelconque des transactions à l'échelle cartographique donnée des tuiles mises en cache était d'environ 15 transactions par secondeÉtant donné que 3 échelles cartographiques ont été testées, le total des transactions par seconde atteint était de 45 transactions par secondeCela équivalait à environ 162 000 transactions de cache par heure <\/LI><\/UL><\/LI>Le pic de débit semble se produire à la marque 10:34<\/LI><\/UL><\/LI><\/UL>

Courbe de performance<\/H2>La performance du débit du cache était bonne à environ 120 ms ou 0,12 secondesCette observation a été prise là où les transactions maximales par seconde se sont produites à la marque 10:34<\/LI><\/UL>PPNote : "Débit maximal" est un point dans un test où aucun débit plus élevé ne peut être atteint. Cela ne signifie pas que c'est la quantité maximale de pression que le service supportera sans "tomber en panne". En général, si des utilisateurs supplémentaires demandent des tuiles mises en cache après que le système ait atteint le débit maximal (par exemple, vous augmentez la configuration de charge par étapes), le service remplira toujours leurs demandes mais ils devront simplement attendre plus longtemps pour que les réponses reviennent (en raison de la mise en file d'attente).<\strong>
Réflexions finales
Le plan de test Apache JMeter dans cet article représente une approche programmatique pour appliquer une charge à un service cartographique mis en cache ArcGIS. L'un des points forts de ce test est qu'il est facile à construire, configurer et maintenir.
Le rapport JMeter auto-généré fournit des graphiques et des résumés qui peuvent être utilisés pour analyser les performances et l'évolutivité du service cartographique mis en cache.

Téléchargez le plan de test Apache JMeter utilisé dans cet article ici : 
cache_tiles1.zip

Éléments supplémentaires dignes d'être mentionnés

Chaque service mis en cache est différent. Mais généralement, les performances et l'évolutivité d'un service mis en cache peuvent être affectées par divers facteurs :

• Architecture de déploiement
  • L'emplacement des données du cache par rapport aux gestionnaires de tuiles ArcGIS
  • Technologie et vitesse du disque de stockage des données du cache
• Bande passante réseau
  • Entre le stockage des données du cache et les gestionnaires de tuiles ArcGIS
  • Entre les gestionnaires de tuiles ArcGIS et les adaptateurs Web ArcGIS
  • Entre les adaptateurs Web ArcGIS et le client de test
• Vitesse du processeur et nombre de cœurs
  • La livraison des tuiles mises en cache est rapide mais sous forte charge, le processus global utilise les ressources CPU du gestionnaire de tuiles ArcGIS et du Web Adaptor ArcGIS (s'il existe dans le déploiement) technologie d'hébergement (par exemple, le service Internet Information Services de Microsoft)
• Données différentes peuvent avoir des performances différentes
  • Taille moyenne des tuiles (par exemple taille sur disque)
    • Les tailles plus petites contenant moins de données peuvent avoir des performances différentes que les tuiles plus grandes et plus détaillées
  • Echelles cartographiques testées
    • Même pour le même jeu de données, l'échelle cartographique 36111.909643 peut avoir des tuiles mises en cache "plus lourdes" que l'échelle 1155581.108577

Hypothèses et contraintes

• JDK 17 ou supérieur ne fonctionnera pas avec ce plan de test (JMeter 5.4.x)
  • L'exécution sur ces versions JDK générera l'erreur suivante : org.codehaus.groovy.GroovyBugError : BUG ! exception dans la phase 'analyse sémantique' dans l'unité source 'Script161.groovy' version majeure du fichier classe non prise en charge 61
  • Utiliser JDK 16 ou antérieur évite cette erreur
    • La raison est que JMeter 5.4.x ne supporte que JDK 16 (ou antérieur)
  • Si JDK 17 ou supérieur est requis pour votre environnement, vous devez utiliser JMeter 5.5 (qui supporte JDK 17)
• Caching On-Demand n'est pas activé
  • Peut fonctionner mais n'a pas été testé
• Caching Single Fused Map Cache est VRAI
• Le format de stockage du cache est COMPACT
• Le format d'image des tuiles est JPG ou PNG
  • A cause de la règle Response Assertion pour valider la réponse du serveur
• Le plan de test inclus devrait fonctionner avec un service mis en cache pour
  • Carte
  • Image
    • La variable ServiceType (sous Variables définies par l'utilisateur) devra être modifiée
    • Pas beaucoup testé
  • Vecteur
    • La variable ServiceType (sous Variables définies par l'utilisateur) devra être modifiée
    • Les images des tuiles VectorTile peuvent être au format Protocolbuffer Binary Format (*.pbf)
      • La règle Response Assertion devra être étendue pour inclure application/octet-stream ou application/x-protobuf
    • Les échantillonneurs JSR223 dans la transaction GetMapTile devront être ajustés pour ajouter ".pbf" à la fin de la variable cacheRequest
    • Pas beaucoup testé

P <\p>P <\p>P <\p>PApache JMeter<\a> publié sous licence Apache<\a> Licence 2.0.<\/A> Apache, Apache JMeter, JMeter, la plume Apache, et le logo Apache JMeter sont des marques déposées de la Apache Software Foundation.<\/SPAN><\/P>

AaronLopez

The Assumptions and Constraints section of the Article has been updated to include some environment details that might be helpful for certain conditions.