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

Verwendung von Public Domain-Daten zur Benchmarking eines ArcGIS Enterprise Map Service (Fortgeschritten)

AaronLopez

Auswahl einer Capability von ArcGIS Enterprise zum Benchmarking

Als grundlegendes Softwaresystem für GIS erfüllt ArcGIS Enterprise viele Aufgaben wie Kartenerstellung und Visualisierung, Analysen. Aus diesem breiten Spektrum an Fähigkeiten und Funktionen gibt es keinen einzelnen Test, der alle seine Möglichkeiten repräsentieren kann.

Wenn jedoch eine Funktion als Benchmark für das Testen einer ArcGIS Enterprise-Bereitstellung verwendet werden sollte, lässt sich ein überzeugendes Argument für die Exportfunktion des Kartendienstes machen. Der Export der Karte kann einfach und programmatisch in einem Apache JMeter Testplan aufgerufen werden, indem die räumlichen Ausdehnungen der Anfragen aus CSV-Datendateien über mehrere Kartenmaßstäbe variiert werden. Dies entspricht genau einer Anfrage pro Kartenmaßstabstransaktion, was dazu beiträgt, den Test nicht kompliziert und schwer wartbar zu machen. In Verbindung mit der Tatsache, dass die Exportfunktion seit Version 9.3 verfügbar ist, ergibt sich eine bewährte und zuverlässige Operation zum Benchmarking.

Was ist ein Benchmark eines Kartendienstes?

GIS-Tester und Administratoren sind oft damit beauftragt, die Unterschiede im Durchsatz zwischen zwei Systemen oder demselben System nach einer Form von Umweltänderung zu verstehen. In solchen Szenarien ist ein Benchmark der Prozess der Durchführung eines Lasttests, der als Standard dient, mit dem mehrere Dinge miteinander verglichen werden können.

Im Hinblick auf GIS wäre dieser Lasttest ein Apache JMeter Testplan, der einen Stufenlasttest gegen einen ArcGIS Enterprise-Kartendienst ausführt, um die höchste Durchsatzrate (Transaktionen/Sekunde oder Anfragen/Sekunde) zu verstehen, die aus der Bereitstellung bei einem bestimmten Zustand oder einer bestimmten Konfiguration erreicht werden kann. Diese Rate ist auch als Spitzen-Durchsatz bekannt. Beim Spitzen-Durchsatz ist es auch entscheidend, die Leistung (Transaktions- oder Antwortzeit der Anfrage) zu messen.<\/SPAN>

Benchmark-Datensatz

Jeder Datensatz kann für einen Benchmark verwendet werden, solange er konstant gehalten wird und keine Änderungen wie Hinzufügen, Aktualisieren, Löschen von Feature-Classes oder Versionen vorgenommen werden. Diese Konsistenz hilft dabei, einen verlässlichen "Standard" zu schaffen, da es sich um ein unbewegliches Ziel handelt. Die Testdaten können privat (z.B. proprietär) oder gemeinfrei sein.<\/SPAN>

<\/SPAN>

Was sind Public Domain Daten?

Im Allgemeinen sind Public Domain Daten Raster- oder Vektor-Datensätze, die kostenlos heruntergeladen und verwendet werden können. Es gibt viele Public Domain Datensätze (und möglicherweise unterschiedliche Lizenzen, die sie definieren). Die in diesem Artikel verwendeten Daten sind Made with Natural Earth und werden unter der Creative Commons (CC0)-Lizenz bereitgestellt.<\/P>

<\/H2>Warum Public Domain Daten verwenden?

Eines der Merkmale eines guten Benchmarks ist es, einen Test so zu konstruieren, dass andere denselben Test wiederholen können. Public Domain Daten sind in dieser Hinsicht eine gute Wahl, da sie einen Teststandard fördern und eine verlässliche Messlatte für Leistung und Skalierbarkeit bieten.<\/SPAN>

SampleWorldCities vs Natural Earth

Während die Einbeziehung von SampleWorldCities durch die Installation von ArcGIS Server den Datensatz allgegenwärtig macht und gut für Testbeispiele und Schritt-für-Schritt-Anleitungen geeignet ist, macht seine extrem kleine Größe ihn nicht ideal für das Benchmarking eines Kartendienstes.<\/P>

Die Natural Earth Datensätze hingegen bieten einige anständige Kartendetails (bei kleineren Maßstäben), die die ganze Welt abdecken. Außerdem kann dies mit einem leicht handhabbaren Speicherplatzbedarf erreicht werden, was es praktischer macht, sie zu teilen, herunterzuladen und zu verwenden.<\/P>

Der Benchmark Natural Earth Datensatz

Laden Sie den Benchmark-Datensatz hier herunter
- Die Daten sind ein Teil des Natural_Earth_quick_start.zip und enthalten ein modifiziertes MXD für ArcMap 10.8.1 und ein ArcGIS Pro 2.8 Projekt.
 - Beide können verwendet werden, um einen Kartendienst in ArcGIS Enterprise zu veröffentlichen.<\/SPAN>
Der Natural Earth Teil-Datensatz sollte beim Öffnen in ArcGIS Pro (oder ArcMap) ähnlich aussehen wie folgt<\/SPAN>

Existiert ein Web Adaptor?
Wurde eine Authentifizierung verwendet oder wurde der Dienst für alle verfügbar gemacht?
- Portal for ArcGIS Authentifizierung
- ArcGIS Server Token Authentifizierung
- Für alle verfügbar
Wie viele Maschinen waren Teil des ArcGIS Site?
Prozessordetails
- Prozessormodell und Architektur
- Anzahl der CPU-Kerne für jeden Server (einschließlich des Testclient-Arbeitsplatzes)
- Physisch, virtuell oder Cloud
Details zum physischen Speicher
- Gesamtsystemspeichergröße
Netzwerkgeschwindigkeit
ArcGIS Enterprise Version
Betriebssystemversion

ArcGIS Server (10.9 Final)
- Dell PowerEdge R640
  - SPECint_rate_base2006
  - HyperThreading deaktiviert
  - 128GB RAM
- Windows Server 2019
- 10G Netzwerk
ArcGIS Web Adaptor (10.9 Final)
- Dell PowerEdge R440
 - SPECint_base2006 </ LI >< LI >HyperThreading deaktiviert </ LI >< LI >64GB RAM </ LI ></ UL ></ LI >< LI >Windows Server 2019 </ LI >< LI >10G Netzwerk </ LI ></ UL ></ LI ></ UL >< UL >< LI >Test Client </ LI >< UL >< LI >Apache JMeter 5.4.1 </ LI >< LI >Dell PowerEdge R640 </ LI >< A href = "https://www.spec.org/cpu2006/results/res2017q3/cpu2006-20170807-48048.html " target = "_self " rel = "nofollow noopener noreferrer ">SPECint_rate_base2006 </ A > < UL >< LI >6 virtuelle CPUs </ LI >< LI >16GB RAM </ LI ></ UL ></ LI >< LI >Windows Server 2019 </ LI >< LI >10G Netzwerk </ LI ></ UL ></ LI ></ UL >< H2 id = "toc-hId--525789242 " >Datentyp und Standort der Datenquelle</ H2 >Die Verwendung entweder einer File-Geodatabase oder einer Enterprise-Geodatabase zur Speicherung von Daten für den Benchmark-Test ist in Ordnung. Unabhängig davon, welche verwendet wird, sind die Details der Datenquelle eine wichtige Eigenschaft der Umgebung, die notiert werden sollte.Hinweis: Es wird empfohlen, den Typ der Datenquelle zu notieren. Das Speichern dieser Informationen zusammen mit den Testergebnissen kann helfen, dem Analyseergebnis oder den Schlussfolgerungen den richtigen Kontext und Bedeutung zu geben. Was den Standort betrifft, könnte es notwendig sein, eine Remote-Datei-Geodatabase anstatt einer lokalen Datei-Geodatabase zu verwenden wenn die Bereitstellung aus mehreren Servern besteht, die zusammen die ArcGIS Enterprise Site bilden. In beiden Fällen, remote oder lokal, ist der Speicherort der Datenquelle ebenfalls ein wichtiges Detail der Testumgebung, das notiert werden sollte.<\/SPAN><\/P>Hinweis: Es wird empfohlen, den Speicherort der Datenquelle zu notieren. Das Speichern dieser Information zusammen mit den Testergebnissen kann helfen, dem Analyse- oder den Schlussfolgerungen den richtigen Kontext und die richtige Bedeutung zu geben.<\/STRONG><\/FONT><\/P>Diensttyp und Anzahl der Instanzen<\/FONT><\/H2>Für die am weitesten verbreiteten ArcGIS-Kartendienste in einer Site wird empfohlen, die Ressource als Dedicated-Instanz statt Shared zu veröffentlichen. Obwohl beide Typen skalieren können, um die verfügbare Hardware vollständig zu nutzen, verfügt eine Dedicated-Service-Instanz über Ressourcen im Hintergrund, die ihr gewidmet sind und sie somit zur idealen Wahl für einen Benchmark-Test machen.<\/FONT><\/P>Für vorhersehbare Leistung wird empfohlen, die minimale und maximale Anzahl von Instanzen für den Dedicate-Instanztyp auf die Anzahl der CPU-Kerne der ArcGIS Server-Maschine einzustellen.<\/FONT><\/P>Hinweis: Es wird empfohlen, den Diensttyp und die Anzahl der Instanzen zu notieren. Das Speichern dieser Information zusammen mit den Testergebnissen kann helfen, dem Analyse- oder den Schlussfolgerungen den richtigen Kontext und die richtige Bedeutung zu geben.<\/STRONG><\/FONT><\/P>Sind die Anforderungsoptionen in einem Benchmark-Test wichtig?<\/H2>Absolut! Die Verwendung eines gemeinsamen Datensatzes und der Exportkartenfunktion reicht nicht aus, um einen verlässlichen Benchmark zu erstellen. Der Exportvorgang ist äußerst vielseitig, aber durch diese Flexibilität kann ein Bild durch verschiedene Eingabeoptionen erzeugt werden.<\/P>Ein Lasttest, der kontinuierlich Anfragen an den Kartendienst sendet, ist wichtig für die Erstellung eines zuverlässigen Benchmarks. Kann der Test eine BMP-Bildformat-Anfrage anstelle von PNG stellen oder Daten in einer anderen räumlichen Referenz als der Standard 4326 anfordern? Ja, aber das Ändern solcher Optionen kann die Leistung und Skalierbarkeit des Tests beeinflussen, daher wird empfohlen, diese Testplan-Einstellungen unverändert zu lassen.<\/P>Der Map Service Benchmark Testplan <\/H1>Um den Apache JMeter Testplan zu diesem Artikel herunterzuladen, siehe: <\/SPAN>naturalearth1.zip<\/A> <\/STRONG>
 Dieser Testplan basiert größtenteils auf dem SampleWorldCities-Testprojekt aus
 einem früheren Artikel<\/A><\/LI><\/UL><\/LI><\/UL>
 Das Herunterladen und Öffnen des Testplans in Apache JMeter sollte ähnlich wie folgt aussehen:
 Passen Sie die benutzerdefinierten Variablen an Ihre Umgebung an<\/LI><\/UL><\/LI><\/UL>
 <\/span><\/P> Die Anforderungszusammensetzung (eine für jede der 5 getesteten Kartenmaßstäbe) sollte ähnlich wie folgt aussehen:<\/LI><\/UL><\/span><\/P>
 Die Thread Group Konfiguration<\/H2>Die Thread Group definiert die schrittweise Lastcharakteristik des Tests und spielt eine wichtige Rolle. Für einen Export Map hat die maximale Anzahl von Threads für den Test eine enge Beziehung zur maximalen Anzahl der CPU-Kerne des ArcGIS Servers (und ähnlich zur maximalen Anzahl von Service-Instanzen). Die Konfiguration der Testthreads über die Anzahl der Kerne hinaus hilft sicherzustellen, dass genügend Druck ausgeübt wird, um die CPU-Ressourcen des Servers vollständig zu nutzen. Ab dort sollte ein Spitzen-Durchsatz beobachtet werden, was ein primäres Ziel eines Benchmark-Tests ist.<\/P>Hinweis: Nicht alle getesteten Datensätze zeigen möglicherweise eine vollständige Auslastung der CPU des ArcGIS Server-Tiers durch den jeweiligen Dienst. In solchen Fällen sind zusätzliche Fehlerbehebungen erforderlich, um zu verstehen, wo der Engpass liegt, der die Skalierbarkeit des jeweiligen Workflows begrenzt.<\/STRONG><\/FONT><\/P>Als Faustregel gilt: Konfigurieren Sie die maximale schrittweise Last 25 % bis 60 % höher als die Anzahl der Server-CPU-KerneWie unten gezeigt ist der Testplan so konfiguriert, dass er 1 Stunde läuft und eine maximale schrittweise Last von 40 gleichzeitigen Testthreads erreichtDies würde den Benchmark bei 1 Testthread starten und alle 90 Sekunden einen weiteren Thread hinzufügen<\/LI>Dieser Benchmark wurde entwickelt, um eine ArcGIS Server-Bereitstellung mit 24 physischen CPU-Kernen zu testen <\/LI>Passen Sie entsprechend an; nicht jeder ArcGIS Server läuft auf 24 physischen Kernen und die maximalen Schrittwerte könnten für Ihre Bereitstellung zu hoch sein<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL><\/span><\/P>Hinweis: Es wird empfohlen, Details zur Schrittbelastungskonfiguration zu notieren. Das Speichern dieser Informationen zusammen mit den Testergebnissen kann helfen, dem Analyse- oder den Schlussfolgerungen den richtigen Kontext und die richtige Bedeutung zu geben.<\/STRONG><\/FONT><\/P>Benchmark-Testausführung<\/H1>Der Benchmark sollte auf dieselbe Weise wie ein typischer JMeter-Testplan ausgeführt werden.<\/P>Siehe das runMe.bat-Skript im naturalearth1.zip-Projekt als Beispiel dafür, wie ein vom Apache JMeter-Team empfohlener Test ausgeführt wird.<\/P>Hinweis: Es wird stets empfohlen, Startzeitpunkt und Dauer des Lasttests mit dem zuständigen Personal abzustimmen. Dies gewährleistet minimale Auswirkungen auf Benutzer und andere Kollegen, die möglicherweise ebenfalls die ArcGIS Enterprise Site nutzen müssen. Außerdem hilft dies dabei, Systemrauschen<\EM> durch andere Aktivitäten und Nutzung zu vermeiden, das die Testergebnisse "verunreinigen" könnte.<\STRONG>
 - Das System erreichte einen maximalen Durchsatz von etwa 80 transactions/sec (oder 80 requests/sec)

Aus dem Bericht:
- Unter Charts-->Response Times findet man das Diagramm Time Vs Threads, in dem die Anforderungsleistung aus dem Test dargestellt wird
  - Alle Elemente außer "/pvtserver/rest/services/NaturalEarth/MapServer/export" sind ausgefiltert (durch Klicken auf sie in der Legende)
  - Da der Test so aufgebaut wurde, dass jede Transaktion nur eine Anfrage enthält, repräsentiert die "export request" auch die durchschnittliche Transaktionsleistung
  - Zum Zeitpunkt des maximalen Durchsatzes liefert das System eine Transaktionsleistung von etwa 314 ms oder 0,3 Sekunden

Um den in diesem Artikel verwendeten Apache JMeter Testplan herunterzuladen, siehe: naturalearth1.zip
Um den in diesem Artikel verwendeten Natural Earth-Datenausschnitt herunterzuladen, siehe: Natural_Earth_Test_Data

Finde mehr Beiträge mit dem Tag

Configuration & Integration

Strategy & Planning

Architecture & Security

Kommentare

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

Nehmen Sie an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registrieren Sie ein kostenloses Konto.

Schnellzugriffe

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