Anfrage
Auch bekannt als Sampler
Eine HTTP Anfrage ist die "kleinste" Arbeitseinheit, die Sie definieren können, um einen Test durchzuführen. Allgemein kann es beim Testen von ArcGIS Enterprise eine URL für eine Ressource wie einen Kartenservice, Feature-Service oder Routenlösung sein, aber es kann auch ein Aufruf für ein statisches Objekt wie eine *.css- oder *.js-Datei sein.
Das Protokoll kann HTTP (Klartext) oder HTTPS (gesichert) sein und die Methode kann eine von vielen sein, obwohl GET, POST und HEAD typischerweise am häufigsten sind.
Eine dynamische Kartenservice-Anfrage würde der folgenden Form ähneln:
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
Die gleiche URL als Apache JMeter HTTP-Anfrage:
Wie eine statische Anfrage aussehen würde:
https://yourwebadaptor.domain.com/portal/home/10.9.0/js/jsapi/dojo/dojo.js
Apache JMeter unterscheidet auch zwischen einer Anfrage und einem Sampler, obwohl beide eine auszuführende Aktion definieren. Ein Sampler wäre die Ausführung eines Prozesses auf Betriebssystemebene, der eine Art Aktion ausführt, wie z.B. das Ausführen eines Geoverarbeitungswerkzeugs zur Erstellung einer File-Geodatabase oder zur Erstellung einer neuen SDE-Version in einer Enterprise-Geodatabase. Jeder Test muss mindestens eine Anfrage oder einen Sampler haben.
Ein weiterer Typ von Sampler ist ein Websocket. Obwohl er einer HTTP-Anfrage ähnelt, da er einen Aufruf über das "Web" macht und gesichert sein kann, verwendet er ein anderes Protokoll zur Kommunikation mit dem entfernten Server sowie andere Parameter zur Spezifizierung von Parameteroptionen.
Transaktion
Eine Transaktion ist eine logische Gruppierung von einer oder mehreren http-Anfragen. Die Anfragen können dynamisch und/oder statisch sein. Zusammen bilden diese Anfragen typischerweise eine Benutzeroperation, zum Beispiel:
- Das Laden der Web-App
- Eine Navigationsaktion wie Schwenken oder Zoomen
- Eine Suchfunktion
- Erstellung einer neuen SDE-Version innerhalb einer Enterprise GeoDatabase
Es ist keine technische Voraussetzung, Transaktionen in einem Test zu verwenden, aber dies kann die Analyse erheblich verbessern, da einzelne Operationen (z.B. Transaktionen) isoliert werden könnten, um deren jeweiliges Leistungsverhalten während des Laufs zu zeigen. Dies kann sehr informativ sein.
Zu verstehen, dass nur Anfragen für den Kartenmaßstab 1:72.224 Leistungsprobleme hatten, ist aus Sicht der Optimierung sehr nützlich, da Sie genau wüssten, welche Bereiche des Kartendokuments oder Projekts
angepasst werden müssten... Transaktionen können Ihnen dabei helfen.
Apache JMeter Transaktion mit drei Anfragen aus einer Operation:
Test
Auch bekannt als Testplan oder Testprojekt
Der Begriff "Test" ist eher allgemein und wird oft sowohl als Substantiv (Ich habe einen Test erstellt, um die Ressource aufzurufen) als auch als Verb (Ich werde den Service testen) verwendet. Transaktionen und Anfragen werden normalerweise in einem Test definiert. Der Test hat zusätzliche Optionen zur Konfiguration wie: wie lange der Test läuft, wohin die Ergebnisse gehen sollen, ob Metriken auf den Remote-Servern gesammelt werden sollen.
Verschiedene Frameworks verwenden leicht unterschiedliche Terminologien zur Beschreibung eines Tests. Im Fall von Apache JMeter wird ein Test oder Testprojekt als Testplan bezeichnet und mit der Dateiendung *.jmx versehen.
Step Load
Auch bekannt als Load
Der Step Load ist ein Merkmal, das definiert, wie lange und wie viele gleichzeitige Testthreads während des Tests durch gleichmäßigen, ansteigenden Druck (z.B. ähnlich einer Treppe) angewendet werden sollen. Die Konfiguration des Tests für einen Step Load ist hilfreich, um zu verstehen, wie ein Kartenservice funktioniert oder skaliert oder wie Bereitstellungsressourcen sich verhalten,
wenn immer mehr Anfragen darauf geworfen werden. Der definierte Druck kann auch abnehmen (gegen Ende des Tests), muss aber nicht.
Apache JMeter Thread Group (bzm - Concurrency), die einen spezifischen Step Load angibt und visualisiert:
Konstanter Load
Ein konstanter Load definiert ebenfalls, wie lange und wie viele Testthreads angewendet werden sollen, wird aber normalerweise für eine konstante Rate über längere Zeiträume eingestellt. Statt sich auf Leistung und Skalierbarkeit zu konzentrieren, dient diese Konfiguration typischerweise dazu, Haltbarkeit und Stabilität zu verstehen.
Apache JMeter Thread Group (bzm - Concurrency), die einen spezifischen konstanten Load angibt und visualisiert:
Test Threads
Auch bekannt als Threads
Dies ist der Mechanismus, der für das Anwenden der Last verantwortlich ist, indem er die definierte Arbeit im Test übernimmt, wie z.B. die Transaktionen und/oder Anfragen, und sie wiederholt ausführt.
Testthreads verhalten sich typischerweise seriell, wobei jeder Thread damit beginnt, die erste im Test definierte Anfrage zu lesen, diese an den Server sendet und dann auf dessen Antwort wartet. Die nächste Anfrage im Test wird erst ausgeführt, wenn eine Antwort vom Server zurückkommt oder ein Timeout abgelaufen ist. Sobald eine dieser Bedingungen erfüllt ist, geht es zur nächsten Anfrage weiter. Die meisten Tests sind so konfiguriert, dass jeder Testthread diesen Prozess während der gesamten Laufzeit kontinuierlich wiederholt.
Verschiedene Technologien bezeichnen Testthreads oft als virtuelle Benutzer, was jedoch irreführend sein kann. Die Testthreads eines Tests sind nur das Mittel (Druck) zum Zweck (gelieferter Durchsatz).
Mit anderen Worten bedeutet die Ausführung eines Tests mit einem Step Load von bis zu 100 Testthreads nicht zwangsläufig, dass die Umgebung 100 gleichzeitige virtuelle Benutzer unterstützt. In diesem Fall würde man die Benutzer anhand des Durchsatzes des Tests berechnen; z.B. Transaktionen/Sekunde.
Apache JMeter Thread Group (bzm - Concurrency), die den Step Load über (Test-)Threads definiert:
Benutzer
Auch bekannt als virtuelle Benutzer
Die Anzahl der unterstützten Benutzer ist eines der meistgefragten Elemente bei einem Lasttest und nimmt üblicherweise folgende Form an:
- Wie viele Benutzer unterstützt dieser spezifische Service oder diese Anwendung?
- Wird ein bestimmter Service oder eine Anwendung mindestens X Benutzer unterstützen?
Die Berechnung der Benutzer hängt eng mit der Denkzeit sowie gemessenen Testergebnissen wie Durchsatz zusammen und Antwortzeit.
Die Verwendung von Little Law mit diesen Eingaben kann eine theoretische Schätzung der Anzahl der Benutzer liefern, die eine Umgebung unterstützen kann.<\/P>
Think Time<\/STRONG>
Auch bekannt als workflow pacing<\/STRONG><\/EM><\/H5>Think Time ist eine Dauer (definiert als Sekunden oder Millisekunden), die in einen Test eingefügt wird, um die Verzögerungen menschlichen Verhaltens zu simulieren, die auftreten würden, wenn eine Person natürlich mit dem map service oder der Webanwendung interagiert.
Think Time-Verzögerungen können zu Transaktionen (z. B. einer Operation) oder Anfragen oder sogar zum Test selbst hinzugefügt werden (was dann als workflow pacing bezeichnet wird). Wie sie hinzugefügt werden, kann je nach verwendetem Testframework variieren.
Im Fall von Apache JMeter stehen mehrere verschiedene Timer zur Verfügung, die dem Test hinzugefügt werden können, um verschiedene Arten von Verzögerungen zu simulieren.<\/P>Key Performance indicators (KPIs)<\/STRONG><\/H5>KPIs sind Testmetriken, die bei der Analyse eines Load Tests helfen. Einige der beliebtesten sind mit der Messung der Antwortzeit und des Durchsatzes des Tests verbunden. Sie erstrecken sich jedoch auch auf Elemente, die die Anzahl fehlgeschlagener Anfragen zählen, die durchschnittliche Inhaltslänge (pro Anfrage) erfassen oder Informationen zur Hardwareauslastung sammeln (wie CPU, Speicher, Netzwerk und Festplatte).
Obwohl das Erfassen der Hardwareauslastung oft zusätzliche Testkonfigurationen und Berechtigungen innerhalb der Umgebung erfordert, sind diese Informationen eines der wichtigsten Artefakte, die aus einem Load Test erfasst werden.<\/P>Hinweis: Die erfasste Hardwareauslastung ist eines der wichtigsten Artefakte, die aus einem Load Test erfasst werden.<\/FONT><\/STRONG><\/P>Response Time<\/STRONG><\/H5>Response Time ist eine gängige Metrik zur Messung der Leistung einer Anfrage, Transaktion oder eines Tests. Einfach ausgedrückt gibt sie Aufschluss darüber, wie schnell eine Operation ausgeführt wird.
Der Wert wird typischerweise in Sekunden oder Millisekunden angegeben. Schnellere Leistung bedeutet niedrigere Response Times, was zu einer günstigeren Benutzererfahrung führt. Die Response Time kann über die Dauer des Tests geplottet werden, um zu verstehen, wie sich die Leistung skaliert hat oder zusammen mit dem Durchsatz für einen bestimmten Punkt im Test aufgelistet werden (z. B. wo der Durchsatz seinen Höhepunkt erreichte).<\/P>Hinweis: Response Times sind eines der wichtigsten Artefakte, die aus einem Load Test erfasst werden.<\/STRONG><\/FONT><\/P>Idealerweise nimmt die Leistung des getesteten Elements die folgende Kurve an, bei der die Response Times schneller ansteigen (um den Punkt des maximalen Durchsatzes herum). Im folgenden Beispiel betrug die durchschnittliche Anforderungsantwortzeit bei maximalem Durchsatz etwa 0,4 Sekunden.<\/P>
<\/span><\/P>Throughput<\/STRONG>:<\/H5>Throughput ist eine gängige Metrik zur Messung der Skalierbarkeit eines map service, einer Webanwendung oder einer Hardwareinfrastruktur. Im Wesentlichen gibt sie Aufschluss über die Rate, mit der eine Operation über einen Zeitraum durchgeführt werden kann.
Der Wert kann üblicherweise als requests\/sec, transactions\/sec (z. B. operations\/sec) oder tests\/sec erfasst werden, wird jedoch oft über die Dauer einer Stunde ausgedrückt (die Rate in Sekunden multipliziert mit 3600).
Höhere Skalierbarkeit bedeutet mehr Throughput, was sich in der Unterstützung von mehr Benutzern niederschlägt.
Einige Testanalysen konzentrieren sich auf den durchschnittlichen Throughput aller Transaktionen für einen Test, während andere den durchschnittlichen Throughput für jede einzelne Operation untersuchen.<\/P>Hinweis: Throughput ist eines der wichtigsten Artefakte, die aus einem Load Test erfasst werden.<\/STRONG><\/FONT><\/P>Idealerweise ähnelt der Throughput des getesteten Elements der folgenden Kurve, bei der er einen Höhepunkt erreicht und dann ein Plateau bildet. <\/SPAN>Wenn Throughput seinen Höhepunkt erreicht und\/_oder ein Plateau bildet, deutet dies darauf hin, dass der Test auf eine Art Engpass gestoßen ist. Im folgenden Beispiel betrug der durchschnittliche Anforderungsdurchsatz beim Höhepunkt etwa 24 requests pro Sekunde (oder 86.400 requests pro Stunde).<\/P>
<\/span><\/P>Bottleneck<\/STRONG><\/H5>Ein Bottleneck ist ein Zustand einer Bereitstellung, bei dem eine ihrer Komponenten oder Ebenen die Rate begrenzt, mit der sie auf eingehende Anfragen reagieren kann. Ein Bottleneck kann folgende Formen annehmen:<\/P>Hardware-BeispieleAlle CPU-Kerne von ArcGIS Server sind vollständig ausgelastet<\/LI>Verfügbarer Speicher ist erschöpft<\/LI>Speicherfestplatten-I\/_O des Datenbankservers ist vollständig ausgelastet<\/LI>Netzwerkkarte ist gesättigtAufgrund von Send- oder Empfangsverkehr <\/LI><\/UL><\/LI><\/UL><\/LI>Software-BeispieleDie Datenbank wurde so konfiguriert, dass nur 25 aktuelle Verbindungen erlaubt sind, obwohl ausreichend Hardware-Ressourcen verfügbar sind<\/LI>Der Durchsatz beim Konsumieren eines map service bildet ein Plateau, aber die CPU-Auslastung von ArcGIS Server steigt nicht über 25 %<\/LI><\/UL><\/LI><\/UL>Ein Bottleneck existiert immer in einer Bereitstellung und zu bestimmen, welche Komponente zuerst einschränkt, ist Teil der Analyse. Es wird oft ein Load Test benötigt, um aufzudecken, wo das erste Bottleneck auftreten wird, da es möglicherweise nur unter hoher Belastung beobachtet werden kann. Während Serverressourcen und Einstellungen typischerweise im Fokus der Bottleneck-Analyse stehen, können auch Ressourcen des Testclients (CPU, Speicher, Netzwerk, Festplatte und in einigen Fällen die testing license) ein Faktor sein. Das Erreichen eines Bottlenecks ist nicht unbedingt ein Problem; es zeigt lediglich auf, wo die erste Schwäche oder Einschränkung im System liegt. Manchmal wird ein Bottleneck als "gute Sache" betrachtet; beispielsweise bei einem großen ArcGIS Caching-Prozess ist es wünschenswert, dass die CPU das erste Bottleneck wird, weil sie die Arbeit zur Erstellung der Map Tiles erledigt. Wenn die CPU aufgrund eines anderen Bottlenecks (z.B. Festplatten-I\/_O) nur 50 % erreichen kann, dauert es doppelt so lange bis zum Abschluss des Jobs im Vergleich zu einer CPU-Auslastung von 100 %.<\/P>Hinweis: Ein Bottleneck existiert immer in einer Bereitstellung<\/STRONG><\/FONT><\/P>Test Type
Auch bekannt als performance test, load test, stress test, endurance test, benchmark test<\/STRONG><\/EM><\/H5>Viele Organisationen verwenden oft unterschiedliche Kategorien zur Klassifizierung der durchgeführten Tests.<\/P>Ein performance test wird typischerweise verwendet, um Probleme mit einem Service oder einer Anwendung zu beheben, wenn diese langsam reagiert oder längere als erwartete Antwortzeiten produziert. Sie müssen keinen step load beinhalten und können bequem als einzelner Benutzer direkt über einen Webbrowser mit dem interessierenden Endpunkt ausgeführt werden.<\/P>Ein load test kann oft verwendet werden, um einen step load test zu beschreiben mit dem Ziel bestimmte Durchsatz- und Antwortzeitziele zu erreichen. Zum Beispiel X transactions per sec<\/EM> mit einer response time unter Y Sekunden<\/EM> und ohne Fehler. Dies könnte zur Erschöpfung einer Serverhardware-Ressource führen, ist aber normalerweise nicht das Ziel. Ein load test kann auch als scalability test bezeichnet werden.<\/P>Ein stress test ist ein ähnlicher Test konzentriert sich jedoch häufig darauf einen Druck zu erreichen welcher ein Vielfaches des Ziels eines load tests darstellt. Mit anderen Worten: Wenn der load test versuchte X transactions per sec<\/EM> zu erreichen versucht der stress test vielleicht X * 5 transactions per sec<\/EM> ohne signifikante Fehler zu verursachen.<\/P>Ein endurance test hat den Unterschied zu versuchen, Komponenten des Systems zu brechen. Die angewandte Last kann ein Vielfaches des stress tests sein wobei das Ziel darin besteht, signifikante Fehler zu erzeugen und den Durchsatz sowie die Antwortzeit bei deren Auftreten zu beobachten. Ein endurance test kann auch als durability test bezeichnet werden wobei die angewandte Last über eine sehr lange Dauer konstant bleibt und Muster bei Hardwareauslastung und -freigabe beobachtet werden.<\/P>Test Plan<\/STRONG><\/H5>Im allgemeinen Sinne ist ein Testplan ein Dokument oder eine Tabelle oder Liste, die die spezifischen Tests definiert, die ausgeführt werden, sowie deren jeweilige Ziele. Diese Ziele sind der Grund und Zweck jedes Tests. Die Analyse der Ergebnisse (manuell oder aus generierten Testberichten) sollte Ihnen helfen zu bestimmen, ob die Ziele jedes Tests erreicht wurden.<\/P>Testing Framework <\/STRONG><\/H5>Das Testing Framework ist das Werkzeug oder die Technologie in Form von Bibliotheken, APIs sowie einer grafischen Benutzeroberfläche (GUI) zum Zusammenstellen von Anfragen und dem Test sowie zur Definition der anzuwendenden Last.
Es gibt viele großartige Testing Frameworks, und Apache JMeter ist nur eines<\/EM> davon. Obwohl sie alle einen ähnlichen Zweck verfolgen, verwenden viele unterschiedliche Ansätze für die Terminologie bestimmter Komponenten und wie sie einen Test erstellen und Last anwenden. Einige legen die Definition der Anfragen und Transaktionen in eigene Dateien mit der Schritt-Last-Konfiguration in einer anderen Datei ab.
Bei Apache JMeter sind alle Testobjekte im Testplan definiert und logisch innerhalb des Baums getrennt.<\/P>Einige Beispiele für Load Testing Frameworks:<\/P>Apache JMeter<\/A> <\/LI>LoadRunner<\/A> <\/LI>Silk Performer<\/A> <\/LI><\/UL>Einige Beispiele für Performance Testing Frameworks:<\/P>
wget<\/A>- Ein Kommandozeilenwerkzeug zum Abrufen einer oder mehrerer URLs<\/LI>
- Kann ein hohes Maß an Details zu jeder Anfrage und Antwort liefern<\/LI><\/UL><\/LI>
curl<\/A>
- Ein Kommandozeilenwerkzeug zum Abrufen einer oder mehrerer URLs<\/LI>
- Kann ein hohes Maß an Details zu jeder Anfrage und Antwort liefern<\/LI><\/UL><\/LI>
Fiddler<\/A>- GUI-basierter HTTP-Debugger, der allein oder mit einem Webbrowser verwendet werden kann<\/LI>
- Kann ein hohes Maß an Details zu jeder Anfrage und Antwort liefern<\/LI><\/UL><\/LI><\/UL>
Testing Framework Architektur<\/STRONG><\/H5>Beim Testen von ArcGIS Enterprise konzentriert sich der Großteil der architektonischen Aufmerksamkeit auf die Skalierbarkeit der Bereitstellungsebenen: Load Balancer, Web Adaptor, Portal for ArcGIS, ArcGIS DataStore, ArcGIS Server, Enterprise Geodatabase und Network Storage. Während eine 8-Core-Testmaschine normalerweise eine beträchtliche Anzahl von Anfragen senden kann, die den typischen Test zufriedenstellen, sind manchmal mehrere Maschinen erforderlich, wenn die anzuwendende Last ernsthafte Leistung erfordert.<\/P>Je nach verwendetem Testing Framework können mehrere der Testkomponenten auf verschiedene Maschinen ausgelagert werden, um die Skalierbarkeit des test client<\/EM> zu verbessern.<\/P>Übliche Komponenten zur Skalierung sind:<\/P>Test ControllerWie der Name schon sagt, liegt der Hauptfokus des Controllers darauf, den Test zu starten und zu stoppen sowie die Sammlung von Testmetriken von einem oder mehreren Test Agents zu koordinieren<\/LI>Im Fall von Apache JMeter ist der Controller direkt in die GUI integriert, läuft aber auch beim Ausführen des Tests über die Befehlszeile mitAndere Testing Frameworks können eine webbasierte Test Controller-Oberfläche haben<\/LI><\/UL><\/LI>Typischerweise wird für eine gegebene Testumgebung nur ein Test Controller benötigt, dieser kann jedoch auf dedizierter Hardware laufen, die von den Test Agents getrennt ist<\/LI><\/UL><\/LI>Test AgentDie Hauptaufgabe des Test Agents besteht darin, Anfragen zu senden und Antworten vom Server zu empfangenDiese Komponente erledigt den Großteil der Arbeit und benötigt die meisten CPU-Ressourcen<\/LI><\/UL><\/LI>Für große Aufgaben könnten mehrere Test Agent-Maschinen erforderlich sein<\/LI>Im Fall von Apache JMeter läuft standardmäßig der Test Agent auf derselben Maschine wie der Test Controller <\/LI><\/UL><\/LI>Test RepositoryEine Maschine, die ausschließlich zur Speicherung der Lasttestergebnisse dient Dazu können Testmetriken wie Antwortzeit, Durchsatz und Hardwareauslastung gehören<\/LI><\/UL><\/LI>Im Fall von Apache JMeter werden die Ergebnisse auf dem Controller in Textdateien (*.JTL) gespeichertEs ist möglich, die Ergebnisse an eine Datenbank zu senden, dies ist jedoch nicht Standard<\/LI><\/UL><\/LI><\/UL><\/LI>Test VisualizationEine Maschine zur Visualisierung der Testmetriken und Hardwareauslastung in Echtzeit<\/LI>Im Fall von Apache JMeter wird die GUI für die Datenvisualisierung eines Produktionstests nicht empfohlen, aber die Befehlszeile schonWenn Ergebnisse an eine Datenbank gesendet werden, kann zusätzliche Software eine Verbindung zum Test Repository herstellen, um die Informationen zu visualisieren<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>Interactive Response Time Law<\/STRONG><\/H5>Das Interactive Response Time Law ist eine Formel, die die Beziehung zwischen wichtigen Leistungsfaktoren definiert: Benutzer, Durchsatz, Antwortzeit und Benutzer-Denkzeit. Die Berechnung kann so angeordnet werden, dass der interessierende Parameter bestimmt wird, solange Sie die anderen drei kennen. Zum Beispiel können wir bei bekannter Anzahl von Benutzern im System, durchschnittlicher Antwortzeit für Anfragen und durchschnittlicher Benutzer-Denkzeit den geschätzten Durchsatzbedarf des Systems ableiten. Dieses Gesetz ist sehr nützlich beim Versuch, Benutzer in Durchsatz umzuwandeln und Durchsatz in Benutzer sowie für andere Anwendungsfälle und bildet eine Grundlage für Bereiche im Zusammenhang mit Tests wie Kapazitätsplanung.<\/P>Gegeben ist folgende Formel:
N = X * (R + Z)<\/P>N = Anzahl der Jobs oder gleichzeitigen Benutzer
X = Durchsatz pro Sekunde im System
R = Antwortzeit oder durchschnittliche Zeit, die ein Job im System verbringt
Z = Denkzeit<\/P>Für weitere Informationen zum Interactive Response Time Law siehe:<\/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<\/A> <\/P>
<\/P>
Apache JMeter<\/A> veröffentlicht unter der <\/SPAN>Apache<\/A> <\/>Lizenz 2.0.<\/> Apache, Apache JMeter, JMeter, das Apache-Feder-Symbol und das Apache JMeter-Logo sind Marken der Apache Software Foundation.<\/><\/>
