nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Vytváření zátěžového testu v Apache JMeter proti Hosted Feature Layer Service (Středně pokročilý / Pokročilý)

AaronLopez

Proč testovat Hosted Feature Layer Service?

Předchozí články Komunity o testování výkonu s Apache JMeter se zaměřovaly na využívání Map Services prostřednictvím funkce exportu. Nicméně, Hosted (feature) layers jsou také populární funkcí ArcGIS Enterprise a jsou široce používány v nasazeních. Navíc dotazování těchto vrstev je založeno na "opakovaném" návrhu mřížky, který může pomoci poskytnout vyšší míru škálovatelnosti oproti jiným vizualizačním technologiím. Spojte to s vykreslováním dat na straně klienta a je to výhra pro všechny.<\/P>

Vzhledem k tomu, že hosted feature services jsou osvědčenou a oblíbenou technologií služeb, dává smysl chtít testovat dotazy na feature pod zatížením, aby bylo možné pozorovat jejich škálovatelnost z první ruky.<\/SPAN><\/P>Výzvy testování Hosted Feature Layer Service<\/SPAN><\/H1>Ve srovnání s testováním funkce export mapy je testování dotazů Hosted Feature Layer Service výzvou, protože požadavky jsou programově složitější. Navigační "pan" nebo "zoom" v webovém prohlížeči generuje několik různých dotazů, každý se svou vlastní geometrií. Pro opakování tohoto chování nebude sestavený load <\/SPAN>test mít jen jeden požadavek k odeslání, ale mnoho a proměnlivé množství. K tomu přidejte fakt, že každý dotazovací požadavek v transakci bude mít unikátní geometrii a měnící se maxAllowableOffset (v závislosti na měřítku mapy) a je to spousta pohyblivých částí, které je třeba sledovat.<\/SPAN><\/P>Jak testovat Hosted Feature Service?<\/SPAN><\/H1>Datová sada USGS Motor Vehicle Use Roads<\/SPAN><\/H2>Pochopení procesu v tomto článku je nejefektivnější, pokud lze kroky reprodukovat. Ale tato opakovatelnost vyžaduje přístup ke stejnému souboru dat. Prostorová velikost zdroje dat musí být také dostatečně velká, aby generovala slušná testovací data, ale ne příliš velká, aby bylo stahování nepohodlné.<\/SPAN><\/P>Zadejte do Motor Vehicle Use Map: Roads feature layer dataset na hub.arcgis.com. 179 tisíc polyline záznamů USGS Roads dat ve WGS 1984 Web Mercator (Auxiliary_Sphere) odpovídá asi 200MB po zipnutí. Je poskytováno pod Creative Commons (CC0) licencí.<\/SPAN><\/P>Zobrazení dat Roads z ArcGIS Pro:<\/SPAN><\/LI><\/UL><\/SPAN><\/P>Velké měřítko zobrazení s povoleným označováním:<\/LI><\/UL><\/SPAN><\/P>Tato data budou publikována z ArcGIS Pro do hosted feature service v ArcGIS Enterprise nebo načtena přímo přes Portal for ArcGIS.<\/SPAN><\/P>Pro vytvoření služby z těchto dat viz Publikování hosted feature layers v ArcGIS Enterprise<\/SPAN><\/LI><\/UL>Generování testovacích dat<\/SPAN><\/H2>Tento test bude vyžadovat dobrá testovací data pro použití v JMeter testu.<\/P>Pro řešení takového úkolu se důrazně doporučuje použít velmi vynikající Load Testing Tools.<\/P>Verze 1.2.2 přidává nové funkce jako nástroj "Generate Query Extents", který bude velkou pomocí při generování testovacích dat pro feature service.<\/SPAN><\/P>Tato data využívají návrh založený na mřížce, což je to, co chceme. S přístupem založeným na mřížce jsou za scénou vytvářeny obálky pro požadovanou oblast. Tyto obálky jsou pak převedeny na odpovídající 512x512 query extents. Počet dotazů (pro každou počáteční obálku) se bude lišit podle toho, kde dopadne na mřížku... toto napodobuje chování služby ve webovém prohlížeči.<\/SPAN><\/P>Zpřístupnění nástrojů z ArcGIS Pro<\/H3>Jakmile byl projekt load-testing-tools <\/SPAN>stažen do vašeho počítače, umístěte rozbalenou složku do adresáře, který je přístupný nebo zpřístupněný ArcGIS Pro. Pokud máte již nainstalovanou předchozí verzi Load Testing Tools, tato aktualizovaná verze může být nainstalována vedle ní (i když s jiným názvem složky) nebo kompletně nahradit existující složku.<\/P>Například:<\/P>Umístěte složku load-testing-tools do C:\Users\[uživatelské_jméno]\Documents\ArcGIS<\/LI>Použijte Přidat připojení složky z Katalogu v ArcGIS Pro k zobrazení obsahu tohoto adresáře:<\/LI><\/UL><\/P>Nástroj "Generate Query Extents" může pracovat s hosted feature service, lokální kopií dat nebo daty v enterprise geodatabázi.<\/SPAN><\/P>Poznámka: nástroj by měl generovat query extents z jakýchkoli dat, ale vyžaduje Projected Coordinate System WGS 1984 Web Mercator Auxiliary_Sphere (WKID: 3857).<\/STRONG>

Vyberte oblast zájmu<\/H3>Vyberte oblast zájmu z mapy, ve které chcete generovat testovací data. V tomto příkladu jsou data Roads zobrazena ze severozápadu Spojených států (blízko státních hranic Idaho a Montana). Vybrané měřítko mapy je 1:1 000 000.<\/P>Spusťte nástroj Generate Query Extents<\/SPAN>

Spuštění nástroje Generate Query Extents by mělo zobrazit vstupy podobné následujícím:<\/SPAN>

Upravte vstupy pro nástroj Generate Query Extents<\/SPAN>

- Několik menších a větších úrovní měřítka bylo odstraněno
- Zbývající úrovně měřítka jsou 12, 13 a 14, které odpovídají měřítkům mapy 144448, 72224 a 36112
- Počet záznamů pro tyto měřítka byl zvýšen
- Úroveň měřítka 14 může být vynechána v závislosti na verzi Load Testing Tools (pokud chybí, přidejte ji ručně)
- Výstupní umístění souboru by mělo být něco jako:
C:\Users\username\Documents\ArcGIS\Projects\Catalog2\query_extents.csv
- Klikněte na Spustit pro provedení nástroje
Poznámka: Doba generování testovacích dat závisí na několika faktorech jako počet různých úrovní měřítka, počet záznamů (na každou úroveň) a aktuální měřítko mapy projektu.

Poznámka: Generování testovacích dat pomocí jiných datasetů může vyžadovat použití různých úrovní měřítka podle úrovně detailu a hustoty prvků.

Ověření vygenerovaných testovacích dat

Je dobrým zvykem vizuálně ověřit vygenerovaná testovací data. To umožňuje testerovi vědět, co bude load test prostorově požadovat od feature service.

Až nástroj úspěšně dokončí generování 3 primární sady dat, které jsou zajímavé:<\/P>

Třídy prvků ohraničujícího rámečku
- Obsahuje náhodně generované oblasti zájmu<\/LI>
- Jedna třída prvků pro každou požadovanou úroveň měřítka<\/LI><\/UL><\/LI>
- Třídy prvků rozsahu dotazu
  - Obsahuje mřížku dlaždic (512x512), na které bude založen každý dotaz prvku<\/LI>
  - Jedna třída prvků pro každou požadovanou úroveň měřítka<\/LI><\/UL><\/LI>
  - CSV soubory rozsahu dotazu
    - Obsahuje generovaná testovací data<\/LI>
    - Každý řádek se skládá z dynamických komponent požadavku služby prvků<\/LI>
    - Jeden soubor pro každou požadovanou úroveň měřítka<\/LI><\/UL><\/LI><\/UL>
      <\/span><\/P>Z panelu Katalog načtěte třídu prvků bbox_36112 do aktuální mapy v ArcGIS ProTento výstup je velmi podobný datům z nástroje Generate Bounding Boxes<\/LI><\/UL><\/LI>V tomto příkladu jsou náhodně generované rámečky růžovéTyto oblasti představují rozlišení obrazovky uživatele, který žádá o data ze služby prvků<\/LI><\/UL><\/LI><\/UL><\/span><\/P>Nyní z panelu Katalog načtěte třídu prvků query_extents_36112 do aktuální mapy, ale za (pod) data bbox_36112<\/LI>V tomto příkladu jsou dlaždice mřížky dotazu zelenéTyto dlaždice odpovídají oblasti na mapě, o kterou bboxes žádají data<\/LI><\/UL><\/LI><\/UL><\/span><\/P>Přiblížení mapy může přinést lepší pochopení vztahu mezi těmito dvěma sadami dat<\/LI>Jak je vidět na mapě níže, některé bboxes jsou mírně posunuté vůči sobě, ale stále sdílejí společnou dlaždici dotazu z mřížky pod nimi<\/LI>Souřadnice těchto dlaždic dotazu (např. z třídy prvků query_extent) jsou to, co půjde do CSV souborů a nakonec do JMeter load testu<\/LI><\/UL><\/span><\/P>Přiblížení bboxes odhaluje detaily jejich příslušné kompozice dotazuNapříklad některé bboxes mohou vyžadovat 12 "základních" dlaždic k vyplnění, jiné 15 nebo 20<\/LI>Jak je vidět na mapě níže, bbox zvýrazněný černě vyžaduje 12 specifických dlaždic dotazu obarvených červeně<\/LI><\/UL><\/LI><\/UL><\/span><\/P> Poznámka: Návrh mřížky dlaždic služby prvků je jednou z jejích klíčových silných stránek, protože umožňuje opakovatelnost. Tuto opakovatelnost lze využít s cachingem v nasazení pro lepší škálovatelnost. To není možné s export map.<\/STRONG><\FONT>
    Závěrečné myšlenky
    Existují i jiné způsoby, jak testovat dotazy na hosted feature layer service, například pomocí zachyceného provozu z webového prohlížeče při interakci s endpointem nebo aplikací. To by vytvořilo seznam URL služeb, které by mohly být přeloženy do testu. Nicméně programatický přístup, jako je ten uvedený v tomto článku, nabízí strategii pro testování široké prostorové oblasti služby pokrývající mnohem více rozsahů, než je prakticky možné provést pomocí zachyceného provozu.
    Programatický přístup je také snazší na údržbu, protože velikost Test Plan je mnohem menší. Pro představu, JMeter test obsažený v tomto článku obsahoval pouze 3 HTTP Requests (jeden pro každé mapové měřítko).
    - Pro stažení Apache JMeter Test Plan použitého v tomto článku viz: roads_hfs1.zip
    - Pro stažení subsetu dat Natural Earth použitých v tomto článku viz: Motor Vehicle Use Map: Roads (Feature Layer)
    Apache JMeter uvolněný pod Apache License 2.0. Apache, Apache JMeter, JMeter, pírko Apache a logo Apache JMeter jsou ochranné známky Apache Software Foundation.

Najděte více příspěvků označených jako

Configuration & Integration

Strategy & Planning

Geodata Engineering

Komentáře

AaronLopez

Hi @StevenBeothy

I think that test plan is valid and a good programmatic way to get a performance profile from each of the layers

However, there are a few items worth mentioning:

My roads_hfs test requested * for the outFields
- This is fine but can be considered aggressive, especially if the tables are "wide" (e.g., 50 or more attributes)
- In that case, I would consider maybe asking for a few specific attributes (e.g., OBJECTID plus one or two others)
- But, that assumes the requested attributes exist in all the layers
  - This is why using * is so easy
My roads_hfs test was build around using hosted feature service queries (e.g., where resultType=tile)
- I am a huge fan of the feature tiles and their data structure lends itself to efficient querying (repeatable extents for better caching, more predictable quantization tolerances for each of the layers)
- A resultType of say standard would be similar but the test logic would be different (and in my opinion, more complex)
  - Additionally, requests with resultType=standard can ask for varying numbers of records being returned (through the use of the resultRecordCount and resultOffset parameters)
    - This adds variance and test complexity...which again is why I like testing with resultType=tile

To reiterate, I think your approach is good and resultType=tile style tests are a great way to consume a feature service.
I bring up these other items to give my opinion and perspective on what your test is doing and how its asking for the data...as well as the potential test logic impacts when asking for feature data when the resultType is not tile.

Hope that helps.

StevenB1

Hi @AaronLopez
Thank you for all your great work with these JMeter blog posts!
I wanted to ask your thoughts on this Feature Service sample, I noticed this test plan queries the first layer id of '0' for each request.

If a Feature Service has multiple layers (eg. 11) is it feasible to change the test plan like I did below? I supply a variable for the user to enter the number of layers in their Feature Service and then include a nested loop in your 'LoopController' to pass the query parameters for each layer id?

I understand this will make the load test much heavier than the original but if it aligns with the how the users interact with the Feature Services if they're viewing all of the data and not just a single layer, would you consider this a valid test plan?

AaronLopez

Hi @SimonGIS,
A good find!
The more recent versions of this Test Plan (roads_hfs2.zip and roads_hfs3.zip) should have that issue corrected.

Thanks.
Aaron

SimonJackson

Great script, thanks for the effort on all of these.

My enviro has both server and portal instance named arcgis:

I noticed in the HTTP requests, it has the name server baked in as opposed to the variable name.

All good, just pointing it out if you ever do an update to your JMeter project or someone else has same issue.

AaronLopez

Hi @JoshBillings,
That combination of JMeter and JDK looks good.
It unclear exactly what issue Groovy is having an problem with.
That said, I tried adjusting the declaration logic to help avoid any ambiguity. I just uploaded a new version of the test: roads_hfs3.zip. Please give this one a try.

This new test ran fine with using OpenJDK17.0.2, OpenJDK20.0.2, OpenJDK11.0.2 and OpenLogic8u382. But if you still encounter issues, try downgrading the JDK (e.g., to 11 or even 8).

Hope that helps.
Aaron

JoshBillings

@AaronLopez I am using JMeter version 5.6.2 and OpenJDK version 17.0.2

Thanks,

Josh

AaronLopez

Hi @JoshBillings,

The operation logic is fairly simple in that it just performs some JMeter variable retrieval and a little Groovy arithmetic. Can you confirm what version of JMeter and JavaSDK you are using?

Thanks.
Aaron

JoshBillings

Hey @AaronLopez, thanks for this write up! I am currently trying to complete this test plan but am getting an error with the Operation Generator (see image).

Any chance you'd know what's causing this?

AaronLopez

The roads hosted feature service Apache JMeter Test Plan has been recently updated:
roads_hfs2.zip

Updates include improved Linux support as well as a correction to the name of the ArcGIS Server instance which was not reflected through the User Defined Variable. The HTTP Request Names have been shortened for easier readability.

AaronLopez

Hi @DeanHowell1,
Here is an Article you may find interesting for testing cached service:
Creating a Load Test in Apache JMeter Against a Cached Map Service (Advanced)
This Article focuses on testing a map service but the same Test Plan should work against a cached image service.

Hope this helps.
Aaron

AaronLopez

Hi @DeanHowell1,
Are you referring to the testing of a single fused image cache?
If so, a possible solution would be to take generated bounding boxes of interest and convert them on-the-fly to the appropriate set of tiles. This conversion process would be based on the GetLayerTile logic (there might be some older resources out on the interest which still list these steps in coding languages).

Of course, the newer developer APIs from Esri do this for you with a simple function call, but in Apache JMeter's case, this logic would need to be added to the test (e.g. using something like Groovy).

I would recommend this strategy over converting a HAR file into a load test. Although technically valid, with the HAR file approach the requests are quickly cached and the load tests then typically shows high network utilization. But using the first approach (conversion of extents to underlying tiles), the requests are more realistic as the test can spatially cover a lot more area.

This topic was also recently discussed as a potential Community Article in the future. If one is put together I will definitely send you the link.
Thanks again for the feedback.
Aaron.

DeanHowell1

Thanks again @AaronLopez , now another puzzle for you 🙂 How do you test a tile layer or base map? We have a state wide coverage of imagery that has been published as a tile service but I can figure out how to test as neither query or export are available capabilities.

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Nový zde? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.