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; } } }

Použití dat z veřejné domény pro benchmark ArcGIS Enterprise Map Service (středně pokročilý)

AaronLopez

Výběr schopnosti ArcGIS Enterprise pro benchmarkování

Jako základní softwarový systém pro GIS, ArcGIS Enterprise vykonává mnoho úkolů jako mapování a vizualizace, analytiku. Z tohoto širokého spektra schopností a funkcí neexistuje jediný test, který by mohl reprezentovat všechny jeho schopnosti.

Nicméně, pokud by jedna funkce měla být použita jako benchmark pro testování nasazení ArcGIS Enterprise, silný argument lze podat pro funkci exportu mapové služby. Export mapy lze snadno a programově volat v Apache JMeter Test Plánu změnou prostorových rozsahů požadavků z CSV datových souborů přes několik měřítek mapy. To znamená pouze jeden požadavek pro každou transakci měřítka mapy, což pomáhá udržet test jednoduchý a snadno udržovatelný. V kombinaci s faktem, že exportní funkce je dostupná od verze 9.3, jde o osvědčenou a spolehlivou operaci pro benchmarkování.

Co je benchmark mapové služby?

Testovači GIS a správci jsou často pověřeni pochopením rozdílů v propustnosti mezi dvěma systémy nebo stejným systémem po nějaké formě úpravy prostředí. V takových scénářích je benchmark proces provedení zátěžového testu, který slouží jako standard, ke kterému lze porovnat více věcí navzájem.

Ve vztahu k GIS by tento zátěžový test byl Apache JMeter Test Plán provádějící krokový zátěžový test proti mapové službě ArcGIS Enterprise za účelem pochopení nejvyšší rychlosti propustnosti (transakcí/s nebo požadavků/s), které lze dosáhnout z nasazení vzhledem k určitému stavu nebo konfiguraci. Tato rychlost je také známá jako špičková propustnost. Při špičkové propustnosti je také kritické měřit výkon (doba odezvy transakce nebo požadavku).

Benchmark dataset

Jakýkoli dataset může být použit pro benchmark, pokud je udržován konstantní, kde nedochází ke změnám jako přidávání, aktualizace, mazání prvků a verzí. Tato konzistence pomáhá vytvořit spolehlivý "standard", protože jde o neměnný cíl. Testovací data mohou být soukromá (např. proprietární) nebo veřejně dostupná.

Co jsou data veřejné domény?

Obecně řečeno, data veřejné domény jsou jakékoli rastrové nebo vektorové datasety, které jsou zdarma ke stažení a použití. Existuje mnoho datasetů veřejné domény (a potenciálně různé licence, které je definují). Data použitá v tomto článku jsou Vyrobená s Natural Earth a poskytována prostřednictvím licence Creative Commons (CC0).

Proč používat data veřejné domény?

Jednou z charakteristik dobrého benchmarku je konstrukce testu tak, aby ostatní mohli zopakovat stejný test jako vy. Data veřejné domény jsou v tomto ohledu dobrou volbou, protože podporují standard testování a spolehlivou měřicí jednotku pro výkon a škálovatelnost.

SampleWorldCities vs Natural Earth

Zatímco zahrnutí SampleWorldCities do ArcGIS Serveru prostřednictvím jeho instalace pomáhá učinit dataset všudypřítomným a vhodným pro příklady testů a průvodců, jeho extrémně malá velikost jej nedělá ideálním pro benchmarkování mapové služby.

Na druhé straně datasety Natural Earth poskytují slušné detaily mapy (na menších měřítkách) pokrývající celý svět. Navíc to lze dosáhnout při snadno zvládnutelné velikosti na disku, což usnadňuje sdílení, stahování a použití.

Benchmark dataset Natural Earth

Stáhněte si zde benchmark dataset
- Data jsou podmnožinou Natural_Earth_quick_start.zip a obsahují upravený MXD pro projekty ArcMap 10.8.1 a ArcGIS Pro 2.8.
  - Lze použít kterýkoli k publikování mapové služby do ArcGIS Enterprise.
Podmnožina dat Natural Earth by měla vypadat podobně jako následující po otevření v ArcGIS Pro (nebo ArcMap)

Nasazovací architektura

Architektura je důležitým detailem benchmarku. Následující jsou všechny důležité komponenty architektury benchmarku, které mají vliv na test:

Existuje Web Adaptor?
Byla zapojena autentizace nebo byla služba zpřístupněna všem?
- Autentizace Portal for ArcGIS
- Tokenová autentizace ArcGIS Serveru
- Dostupné všem
Kolik strojů se podílelo na ArcGIS Site?
Detaily procesoru
- Model procesoru a architektura
- Počet CPU jader pro každý server (včetně pracovní stanice klienta testu)
- Fyzický, virtuální nebo cloudový
Detaily fyzické paměti
- Celkova velikost systémové paměti
Rychlost sítě
Verze ArcGIS Enterprise
Verze operačního systému

Poznámka: Doporučuje se zaznamenat detaily nasazovací architektury. Uložení těchto informací spolu s výsledky testu může pomoci dát správný kontext a význam analýze nebo závěrům.

Výsledky uvedené v tomto benchmarkovém testu byly provedeny na následující architektuře prostředí:

ArcGIS Server (10.9 Final)
- Dell PowerEdge R640
  - SPECint_rate_base2006
  - HyperThreading vypnutý
  - 128GB RAM
- Windows Server 2019
- Síť 10G
ArcGIS Web Adaptor (10.9 Final)
- Dell PowerEdge R440
  - SPECint_base2006
  - HyperThreading vypnutý
  - 64GB RAM
- Windows Server 2019
- Síť 10G

KLIENT TESTU
- Apache JMeter 5.4.1
- Dell PowerEdge R640
- SPECint_rate_base2006
  - 6 virtuálních CPU
  - 16GB RAM </ LI ></ UL ></ LI >< LI >Windows Server 2019 </ LI >< LI >Síť 10G </ LI ></ UL ></ LI ></ UL >< H2 id = "toc-hId--525789242">< SPAN > Typ zdroje dat a umístění </ SPAN ></ H2 >< P >< SPAN > Použití buď souborové geodatabáze nebo enterprise geodatabáze k ukládání dat pro benchmarkový test je v pořádku. R </ SPAN >< SPAN > egardless of which is used, the detail of the data source is an important property of the environment which should be </ SPAN >< SPAN > noted.</ SPAN ></ P >< P >< SPAN >< FONT color = "#FF0000">< STRONG > Poznámka: Doporučuje se zaznamenat typ zdroje dat. Uložení těchto informací spolu s výsledky testu může pomoci dát správný kontext a význam analýze nebo závěrům. </ STRONG ></ FONT ></ SPAN ></ P >< P >< SPAN > Pokud jde o umístění, může být nutné použít vzdálenou souborovou geodatabázi místo lokální souborové geodatabáze pokud nasazení sestává z více serverů, které tvoří ArcGIS Enterprise Site. V obou případech, vzdáleném i lokálním, je umístění zdroje dat také důležitým detailem testovacího prostředí, který by měl být zaznamenán.<\/SPAN><\/P>
    Poznámka: Doporučuje se zaznamenat umístění zdroje dat. Uložení těchto informací spolu s výsledky testu může pomoci poskytnout správný kontext a význam analýzy nebo závěrů.<\/STRONG><\/FONT><\/P>Typ služby a počet instancí<\/FONT><\/H2>Pro nejpoužívanější ArcGIS mapové služby v rámci Site se doporučuje publikovat zdroj jako Dedicated instance místo Shared. Ačkoliv oba typy mohou škálovat tak, aby plně využily dostupný hardware, Dedicated service instance má za scénou zdroje vyhrazené pouze pro ni, což ji činí ideální volbou pro benchmark test.<\/FONT><\/P>Pro předvídatelný výkon se doporučuje nastavit Minimální a Maximální počet instancí pro typ Dedicate instance rovný počtu CPU jader stroje ArcGIS Server.<\/FONT><\/P>Poznámka: Doporučuje se zaznamenat typ služby a počet instancí. Uložení těchto informací spolu s výsledky testu může pomoci poskytnout správný kontext a význam analýzy nebo závěrů.<\/STRONG><\/FONT><\/P>Záleží na možnostech požadavků v Benchmark Testu?<\/H2>Rozhodně! Použití společného datasetu a funkce export mapy není dostatečné k vytvoření spolehlivého benchmarku. Exportní operace je velmi všestranná, ale díky této flexibilitě může být obrázek generován pomocí různých vstupních možností.<\/P>Zátěžový test, který konzistentně odesílá požadavky na mapovou službu, je důležitý pro stanovení spolehlivého benchmarku. Může test požadovat BMP formát obrázku místo PNG nebo požadovat data v jiné prostorové referenci než výchozí 4326? Ano, ale změna takových možností může ovlivnit výkon a škálovatelnost testu, proto se doporučuje ponechat nastavení Test Plan tak, jak jsou.<\/P>Plán benchmarkového testu Mapové služby <\/H1>Ke stažení Apache JMeter Test Plan použitého v tomto článku viz: <\/SPAN>naturalearth1.zip<\/A> <\/STRONG>
    - Tento Test Plan je z velké části založen na projektu SampleWorldCities z
    předchozího článku<\/A><\/LI><\/UL><\/LI><\/UL>
    Stažení a otevření Test Planu v Apache JMeter by mělo vypadat podobně jako následující:
    Upravte User Defined Variables tak, aby odpovídaly vašemu prostředí<\/LI><\/UL><\/LI><\/UL>
    <\/span><\/P> Kompozice požadavku (jeden pro každé z 5 testovaných měřítek mapy) by měla vypadat podobně jako následující:<\/LI><\/UL><\/span><\/P>
    Konfigurace Thread Group<\/H2>Thread Group definuje charakteristiky krokového zatížení testu a hraje důležitou roli. Pro export mapy má maximální počet vláken (Number of Threads) testu úzký vztah k maximálnímu počtu CPU jader stroje ArcGIS Server (a obdobně k maximálnímu počtu instancí služby). Konfigurace vláken testu tak, aby překročila počet jader, pomáhá zajistit dostatečný tlak k plnému využití CPU serveru. Odtud by měl být pozorován vrchol průtoku (peak throughput), což je primární cíl benchmark testu.<\/P>Poznámka: Ne všechny testované datasety mohou ukázat plné využití CPU dané služby na úrovni ArcGIS Server vrstvy. V takových případech je potřeba další řešení problémů k pochopení, kde existuje úzké místo omezující škálovatelnost daného pracovního postupu.<\/STRONG><\/FONT><\/P>Obecné pravidlo je nastavit maximální krokové zatížení o 25 % až 60 % vyšší než počet CPU jader serveruJak je vidět níže, Test Plan je nakonfigurován běžet po dobu 1 hodiny a dosáhnout maximálního krokového zatížení 40 současných vláken testuTento benchmark začíná na 1 vlákně testu a přidává další vlákno každých 90 sekund<\/LI>Tento benchmark byl navržen pro testování nasazení ArcGIS Server běžícího na 24 fyzických CPU jádrech <\/LI>Upravte podle potřeby, ne každý ArcGIS Server poběží na 24 fyzických jádrech a maximální hodnoty kroků mohou být pro vaše nasazení příliš vysoké<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL> Poznámka: Doporučuje se zaznamenat podrobnosti konfigurace krokového zatížení. Uložení těchto informací spolu s výsledky testu může pomoci poskytnout správný kontext a význam analýzy nebo závěrů.<\ /STRONG> Provádění benchmarkového testu < P > Benchmark by měl být spuštěn stejným způsobem jako typický JMeter Test Plan.<\ / P > < P > Viz skript runMe.bat zahrnutý v projektu naturalearth1.zip jako příklad spuštění testu doporučeného týmem Apache JMeter.<\ / P > < P > < FONT color = "#FF0000">< STRONG > Poznámka: Vždy se doporučuje koordinovat čas zahájení zátěžového testu a jeho trvání s příslušným personálem. To zajišťuje minimální dopad na uživatele a další kolegy, kteří také mohou potřebovat používat ArcGIS Enterprise Site. Navíc to pomáhá zabránit systémovému šumu z jiné aktivity a použití, které by mohly „znečistit“ výsledky testu.<\ / STRONG ><\ / FONT ><\ / P > < H1 id = "toc-hId--1235894408">Výsledky a analýza < P > Po dokončení zátěžového testu skript runME.bat instruuje Apache JMeter k automatickému vytvoření zprávy pro usnadnění analýzy výsledků.<\ / P > < P > Existují celé články a internetové zdroje věnované výhradně analýze komponent výsledků zátěžového testu. Abychom to udrželi jednoduché, zaměříme se na metriky propustnosti požadavků (requests/sec) a výkonu požadavků (sekundy) ze zprávy.<\ / P > < P > Níže uvedené diagramy ilustrují ideální trendy těchto dvou položek v průběhu času během testu.<\ / P > < H2 id = "toc-hId-1380701144">Ideální křivka propustnosti
    < P >< span class = "lia-inline-image-display-wrapper lia-image-align-center" image-alt = "theoretical_throughput_curve.png" style = "width: 984px;" >< img src = "https://us.v-cdn.net/6038851/uploads/images/17248iF22584F5C377D6E1/theoretical_throughput_curve.png" role = "button" title = "theoretical_throughput_curve.png" alt = "theoretical_throughput_curve.png" /><\ / span ><\ / P > < P > <\ / P > < P > Ideálně bude mít křivka propustnosti tvar oranžové čáry výše. Bod, kde křivka vrcholí a začíná se vyrovnávat, naznačuje, že systém dosáhl své nejvyšší úrovně propustnosti (kvůli hardwarovému nebo softwarovému úzkému místu). Tato oblast grafu, kde se křivka ohýbá, se nazývá koleno a hodnota maximální propustnosti je právě v tomto bodě.<\ / P > < P > Modrá čára představuje rostoucí krokové zatížení testu.<\ / P > < H2 id = "toc-hId--426753319">Ideální křivka výkonu < P >< span class = "lia-inline-image-display-wrapper lia-image-align-center" image-alt = "theoretical_performance_curve.png" style = "width: 983px;" >< img src = "https://us.v-cdn.net/6038851/uploads/images/17240i39DD4BF543301408/theoretical_performance_curve.png" role = "button" title = "theoretical_performance_curve.png" alt = "theoretical_performance_curve.png" /><\ / span ><\ / P > < P > Ideálně bude mít křivka doby odezvy tvar zelené čáry výše. Je brána ve stejném bodě testu jako maximální propustnost.<\ / P > < P > Modrá čára představuje rostoucí krokové zatížení testu.<\ / P > < H1 id = "toc-hId-1931676795">JMeter Report < P > Součástí projektu naturalearth1.zip je Apache JMeter report nazvaný naturalearth1_run1 ve složce reports.<\ / P > < UL >< LI > Otevření index.html odhalí několik grafů a tabulek pro usnadnění analýzy<\ / LI ><\ / UL > < H1 id = "toc-hId-124222332">< span class = "lia-inline-image-display-wrapper lia-image-align-center" image-alt = "report_folder.png" style = "width: 999px;" >< img src = "https://us.v-cdn.net/6038851/uploads/images/17247iF369998FE40007C4/report_folder.png" role = "button" title = "report_folder.png" alt = "report_folder.png" /><\ / span ><\ / H1 > < H2 id = "toc-hId--855987471"> <\ /SPAN>Skutečná křivka propustnosti < UL >< LI >Z reportu:<\ /SPAN> < UL class= "lia-list-style-type-circle">< LI >Pod Charts-->Throughput lze najít graf Hits Per Second, kde je vykreslena propustnost požadavků z testu<\ /SPAN>
    < UL class= "lia-list-style-type-square">< LI >Jelikož byl test sestaven tak, že každá transakce obsahuje pouze jeden požadavek, „hits za sekundu" je ekvivalentní jak transakcím/sec, tak požadavkům/sec
  - Systém dosáhl maximální propustnosti přibližně 80 transakcí/sec (nebo 80 požadavků/sec)

Skutečná křivka výkonu

Z reportu:
- Pod Grafy-->Časy odezvy lze najít graf Čas vs Vlákna, kde je vykreslen výkon požadavků z testu
  - Všechny položky kromě "/pvtserver/rest/services/NaturalEarth/MapServer/export" jsou vyfiltrovány (kliknutím na ně v legendě)
  - Jelikož byl test sestaven tak, že každá transakce obsahuje pouze jeden požadavek, požadavek "export" také reprezentuje průměrný výkon transakce
  - V bodě maximální propustnosti systém poskytuje výkon transakce přibližně 314 ms nebo 0,3 sekundy

Poznámka: Pro analýzu zatěžovacího testu obsahujícího transakce s více než jedním požadavkem bude třeba použít odlišný přístup

Porovnání výsledků

Po dokončení testu vašeho systému s poskytnutými daty a Testovacím plánem můžete výsledky porovnat s těmi uvedenými v tomto článku. To může poskytnout přibližnou měřítko pro srovnání dvou systémů.

Pro stažení Apache JMeter Testovacího plánu použitého v tomto článku viz: naturalearth1.zip
Pro stažení podmnožiny dat Natural Earth použitých v tomto článku viz: Natural_Earth_Test_Data

Apache JMeter uvolněný pod Apache Licencí 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

Architecture & Security

Komentáře

AaronLopez

Actual Performance Curve chart adjusted to show the response time point that corresponds more accurately to the maximum throughput.

ChiefKeefSosa300

hello sir @AaronLopez

i had a problem running this test.

i published the natural earth map as service, name it as NaturalEarth_MIL1.

change the parameter accordingly in jmeter

the result tree showed me this

any help regarding this?

AaronLopez

Hi @ChiefKeefSosa300 (tq),

Would you be able to delete one of the "image/png Validation" elements and try playing the test again?

These validations items are looking to see if the content returned from ArcGIS Server looks like a png image (this is the default image format this test requests). If it does not match a png signature, it fails the request. Failing a request whose response is not expected is a common strategy when you want to know if your test encounters an error.

Aaron

ChiefKeefSosa300

hi sir @AaronLopez,

per your suggestion i disabled the image/png validation and results go green again.

i just wanna ask about this statement:

"A load test that is sending in the requests to the map service consistently is an important for establishing a reliable benchmark. Can the test request a BMP image format instead of a PNG or ask for data to be in a different spatial reference other than the default of 4326? Yes, but changing such options may impact the performance and scalability of the test so it is recommended to leave this Test Plan settings as is."

does this mean my test failed wholly? or my arcgis server doesnt meet the benchmark requirement?

please enlighten me good sir.

thanks again.

AaronLopez

Hi @ChiefKeefSosa300 (tq),

These are really thoughtful questions, thank for asking them!

The statements about changing the output format to BMP or utilizing another the spatial reference are mentioned with respect to the that specific test. But they need more context...

I favor PNGs over BMPs as the former (Portable Network Graphics) is generally much faster to generate than the latter (Bitmap Image). For example, an export map request that creates a PNG is about 87KB. Using a BMP for the same area, the resulting image is around 15MB. The drastic difference in size would impact scalability (as more network bandwidth is required per request). That said, if your application or workflow requires BMP, then that is the way to go and your benchmark should reflect that. There is nothing wrong with using BMP as an image format for a vector data benchmark, but you should get more throughput by using PNG.

As for the spatial reference, this test used bounding boxes in a geographic coordinate system of "WGS 1984" (WKID 4326) because that is what the data (and published service) was originally in. Of course, there are many different spatial references. The goal when possible, is to try to avoid projecting-on-the-fly. In other words, if the data (and service) are in "WGS 1984" and you ask for "NAD27" (using the appropriate NAD27 bounding box), ArcGIS Server should appropriately fulfil the request. However, while very convenient, this transformation between coordinate systems comes at a performance cost. If you use this test and data as a benchmark, "WGS 1984" (WKID 4326) are an optimal choice. But, if you are wanting to build a benchmark test against your data that is in another coordinate system, I would use bounding boxes in that coordinate system to ensure you can get the best performance.

So to conclude, does using BMP or another coordinate system fail the test, not at all. Performance would be impacted, but you still have a good "measuring stick". As long as the test parameters are known and kept constant between runs over time, you'll have a reliable benchmark regardless of the options used.

Hope this helps.
Aaron

ChiefKeefSosa300

Hi @AaronLopez , thanks for lengthy explanation regarding the test. However,

Im using your test plan to test my arcgis portal but using different map service, the result of the graph is like this (100 users for 5 minutes), is this acceptable result? seems weird and different from yours.

Hits per sec

time vs threads

AaronLopez

Hi @ChiefKeefSosa300,
It depends. You stated you tested a different map service. Does that mean different data than natural
earth?
If yes, each dataset will have its own profile for performance and scalability because the geometry density and complexity can vary. Your data may have more (or less) layers and each layer may have more (or less) attributes.
If no, and you also tested natural earth, then there is a greater chance of seeing a similar profile for performance/scalability, but there are still other variables which can impact response time and throughput like the system architecture (number of machines) and hardware (number of CPUs, CPU speed and memory).

Hope this helps.
Aaron

ChiefKeefSosa300

Hi sir @AaronLopez,

I think i made wrong kind of test because i use the same datasets (project folder) for natural earth but the service name and webserver name is different.

I checked the csv file for each datasets and the home column said "eistsrv05.esri.com_443__Natural_Earth_quick_start_for_ArcMap" so yeah i guess the test result is invalid. But can it be done like this? Use the same datasets for natural earth but different map service? if not how can one acquire its own datasets. Thank you

ChiefKeefSosa300

Hi @AaronLopez ,

i overlooked ur writing about benchmark datasets "Any dataset can be used for a benchmark as long as it is kept constant where changes like feature class additions, updates, deletes and versions are not being made. This consistency helps create a dependable "standard" since it is a non-moving target. The test data can be private (e.g. proprietary) or public domain based."

So I guess my results are real and ok.

Thanks btw

EduardBeneke

Hi @AaronLopez

These tutorials are great. I am looking at utilising them to produce an end-to-end full test suite (including GP, admin tasks, building caches etc).

One of the pain-points we are currently experiencing is with the publishing of a large service, rather than the consumption of the service. Is there a way to publish this dataset using JMeter, then do some performance tests on it, and then delete it? We only see the performance issues through Pro, so need to be able to reproduce that exact process.

AaronLopez

Hi @EduardBeneke,

Yes, you could probably construct a JMeter test to perform the publishing of a large service.
This effort would most likely involve an SD file (a service definition that was previously created from ArcGIS Pro) and some asynchronous JMeter test logic.

However, the publishing of a service is generally considered an administrative function.
While the functionality of publishing a service to work as intended is very important, whether it is slow or fast is not as high a priority (just as long as it still works).

That said, here are some reasons that come to mind that might cause service publishing to have slow performance:

When publishing the service, "copy all data" is selected under the Data and Layer Type section
- While there are very good reasons to do this, one of the considerations is that ArcGIS Pro will need to upload all the data listed in the Contents pane in the project to ArcGIS Enterprise...for large datasets this can take quite awhile
The network between ArcGIS Pro and ArcGIS Enterprise has measurably latency
- If you are publishing from your local machine into the cloud or into a deployment that is physically far away, then performance (of many different operations) could be impacted
  - In this case, try publishing from an ArcGIS Pro that is on the local network of ArcGIS Enterprise
  - Alternatively, if the data resides in an Enterprise Geodatabase, consider publishing with the Reference registered data (Map Image and/or Feature) option
  - As another alternative, consider using the "Save As Offline Service Definition" when attempting to share/publish the service
    - This will create an SD file (which might be large and take some time to create), but you take that hit once. Then when you want to republish, you can do it right from manager over the web.
The PublishingTools.GPServer service is busy publishing other services
- By default, up to 3 instance can run at a time
- I list this as a possibility, but it would probably be unlikely

Hope that helps

Aaron

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.