Empfohlene Strategien für Lasttests einer ArcGIS Server-Bereitstellung
- Beginnen Sie mit einem Testplan
Die meisten Testsoftware kann nach Abschluss des Tests eine Art Bericht erstellen. Dieser Bericht sollte die Fragen beantworten, die der Testplan gestellt hat.
Zum Beispiel:
a) Konnte der ArcGIS-Dienst die gesamte CPU auslasten (z.B. CPU-gebunden)?
b) Konnte der ArcGIS-Dienst einen bestimmten Durchsatz liefern (z.B. eine bestimmte Anzahl von Transaktionen/Sekunde)?
c) Hat der Durchsatz eine durchschnittliche Antwortzeit geliefert, die unsere Leistungsanforderung erfüllt?
Die Definition eines Zwecks für einen Test hilft, den Testaufwand auf ein Ziel zu konzentrieren.
- Tests sollten gegen Anwendungen ohne bekannte größere Fehler oder Defekte durchgeführt werden
Lasttests sollten nicht verwendet werden, um eine Bereitstellung oder Anwendung funktional zu testen.
Eine Anwendung sollte die Qualitätssicherung (QA) bestanden haben, bevor Lasttests durchgeführt werden.
Außerdem könnten größere Fehler in einer Anwendung messbare Auswirkungen auf die Leistung und Skalierbarkeit der angebotenen Dienste haben. Dies würde höchstwahrscheinlich die Testergebnisse ungültig machen und möglicherweise Zeit, Geld und Ressourcen verschwenden.
- Interagieren Sie mit Ihrer Anwendung (und ArcGIS-Diensten), bevor Sie Lasttests durchführen
Wenn Sie der einzige Benutzer auf Ihrem System sind und die ArcGIS-Dienste sehr langsam reagieren, ist es nicht notwendig, einen Test unter Last durchzuführen. Der nächste Schritt sollte sein, die ArcGIS-Dienste für die Leistung zu optimieren und abzustimmen.
- Koordinieren Sie die Testausführung
Oft wird ein Lasttest in einer QA/Staging- oder Testumgebung durchgeführt, gelegentlich auch in der Produktion.
Unabhängig von der Umgebung ist es wichtig zu bedenken, dass Dienste und Ressourcen oft auch von anderen Benutzern genutzt werden (und nicht nur vom Lasttest-Team).
Um Verwirrung und unerwartete Erfahrungen zu vermeiden, wird dringend empfohlen, die Durchführung von Lasttests mit dem entsprechenden Personal abzustimmen.
Dies kann dazu beitragen, eine bessere Erfahrung für tatsächliche Benutzer zu gewährleisten und unerwünschte Störungen im Lasttest (durch Aktionen realer Benutzer) zu vermeiden.
- Überprüfen Sie, ob die Testumgebung den Erwartungen entspricht
Manchmal wird die Testumgebung aus verschiedenen Gründen reduziert. Im Laufe der Zeit können sich Test- und Produktionsumgebungen stark unterscheiden. In diesem Fall hätten Testergebnisse aus der Testumgebung wenig Aussagekraft bezüglich der Leistung oder Skalierung in der Produktion.
Zum Beispiel:
a) Wenn erwartet wird, dass die Produktion mit einer hochverfügbaren Architektur bereitgestellt wird, sollte dies auch für den Test gelten
b) Wenn erwartet wird, dass die Produktion eine Enterprise-Geodatabase mit 500 GB Vektordaten nutzt, sollte dies auch für den Test gelten
c) Wenn in der Produktion ArcGIS Server mit 32 Kernen verwendet werden und Serviceinstanz-Maximalwerte auf 32 gesetzt sind, sollte dies auch für den Test gelten
Die Synchronisierung von Test- und Produktionsumgebungen kann helfen, den besten Wert (und Erwartungen) an die Ergebnisse zu liefern. Falls sie bewusst nicht übereinstimmen, sollte dies vor Beginn des Tests vermerkt und bei allen daraus abgeleiteten Schlussfolgerungen berücksichtigt werden.
- Beginnen Sie einen Lasttest bei Schritt 1
Die Verwendung von 1 als initialen Lastschritt kann Ihre Nachtestanalyse unterstützen.
Schritt 1 (oder ein gleichzeitiger Testthread) stellt das Best-Case-Szenario für Ihren Test dar. Dies ist Ihre Basislinie und ein guter Maßstab, um zu verstehen, wie gut oder schlecht der ArcGIS-Dienst skaliert hat, wenn der Druck zunahm (z.B. wenn zusätzliche Testthreads hinzugefügt wurden).
- Sammeln Sie Hardware-Auslastungsdaten von allen am Test beteiligten Maschinen
Die meisten Testframeworks bieten typischerweise die Möglichkeit, Hardware-Auslastungsdaten von den Servern und dem Testclient selbst zu sammeln. Dies kann wertvoll sein, um den Ressourcenverbrauch zu verstehen und Engpässe zu identifizieren (z.B. können auch die Ressourcen des Testclients ein begrenzender Faktor sein).
Trotz dieser Funktion in der Testsoftware ist das Sammeln der Hardware-Auslastung nicht immer möglich aufgrund von Berechtigungen oder Netzwerkzugang (z.B. Verbindungen durch Firewalls/Router).
Obwohl es bequem ist, diese Informationen direkt über ein Testframework zu erhalten, gibt es andere Möglichkeiten, diese Aufgabe zu erfüllen. Die Verwendung kostenloser Tools wie PerfMon in Windows oder dtstat in Linux zur Erfassung dieser Daten ist ein zusätzlicher Schritt, aber lohnenswert. Nach Abschluss des Tests kann die Analyse weiterhin anhand der manuell erstellten Diagrammdaten aus der Hardware-Auslastung erfolgen.
- Testen Sie einzelne ArcGIS-Dienste zuerst
Wenn eine bestimmte Webanwendung mehr als einen ArcGIS-Dienst verwendet, testen und optimieren Sie jeden einzeln.
Dieser Ansatz erleichtert es festzustellen, welche Dienste Engpässe oder Einschränkungen haben könnten, die sie daran hindern, die verfügbare Hardware vollständig zu nutzen.
Wenn ein ArcGIS-Dienst nicht alle verfügbaren CPU-Ressourcen des ArcGIS Servers nutzen kann, sollte der Tester/Analyst die zuständige Person darüber informieren, dass eine Optimierungsmöglichkeit in der Bereitstellung besteht.
Vermeiden Sie außerdem den Start des Testaufwands mit dem vollständigen Anwendungsworkflow, da es schwierig sein kann, potenzielle Engpässe zu erkennen, wenn viele ArcGIS-Dienste gleichzeitig getestet werden.
- Testen Sie so physisch nah wie möglich an der Bereitstellung
Versuchen Sie nicht, den Internetverkehr im Test „zu simulieren“. Das Testen so physisch nah wie möglich an der Bereitstellung kann helfen, das beste Verständnis dafür zu erhalten, was die Serverhardware leisten kann.
Das absichtliche Einführen von Netzwerkverzögerungen oder schlechter Bandbreite fügt einem Test Störungen hinzu und erschwert es, das volle Potenzial der ArcGIS-Dienste und ihrer Server zu erkennen.
- Schrittweite und Testdauer
Tests müssen nicht acht Stunden laufen, um nützliche Informationen über den betreffenden ArcGIS-Dienst zu liefern. Es wird jedoch empfohlen, keine zu kurzen Lasttests durchzuführen. Es geht darum, eine geeignete Dauer für den gesamten Test (und für jede Schrittweite) auszuwählen, die genügend Informationen liefert. Mit anderen Worten: Es geht darum genug Anforderungsproben aufzuzeichnen, um einen „guten“ Durchschnittswert zu erhalten.
Die Dauer hängt typischerweise von Ihrer Antwortzeit ab: Eine schnelle Antwortzeit kann viele Anforderungen innerhalb eines fünfminütigen Lastschritts liefern. Eine langsame Antwortzeit benötigt möglicherweise einen fünfzehnminütigen Lastschritt um ebenso viele Werte aufzuzeichnen.
Als Tester gelingt Ihnen möglicherweise nicht immer beim ersten Versuch die richtige Wahl von Schrittweite und Testdauer – Anpassungen und erneutes Ausführen des Tests können erforderlich sein.
- Achten Sie auf das Log-Level des ArcGIS Servers
Obwohl die Logs des ArcGIS Servers viele Informationen zur Analyse liefern können, ist es wichtig zu verstehen, dass höhere Log-Level wie VERBOSE und DEBUG die Leistung einer stark ausgelasteten Seite verlangsamen können und für Produktionsumgebungen nicht empfohlen werden. Der Wert WARNING (Standard) bietet hingegen die bestmögliche Serviceleistung, da nur Warnungen und Fehler protokolliert werden.
Ein Log-Level FINE stellt einen guten Kompromiss zwischen nützlichen analytischen Informationen (wie verstrichene Zeiten bei dynamischen Anfragen) und Geschwindigkeit dar.
- Traditionelle ArcGIS-Dienste können innerhalb des (ArcGIS) Servers optimiert werden
Bevor Sie einen traditionellen (z.B. dedizierten) ArcGIS-Dienst lasttesten oder optimieren wollen bzw. seine Leistung verstehen möchten, versuchen Sie den Wert seiner maximalen ArcSOC Instanzen auf die Anzahl der verfügbaren CPU-Kerne des ArcGIS Servers einzustellen.
Nach dem Neustart des Dienstes ermöglicht diese Einstellung mehreren gleichzeitigen Anfragen die Nutzung der verfügbaren Hardware und zeigt ihn im bestmöglichen Licht (vorausgesetzt der Dienst ist CPU-begrenzt).
style="padding-left : 30px;">Die Erhöhung des maximalen Werts der ArcSOC-Instanz ermöglicht es dem Dienst auch, mehr CPU zu nutzen, aber im Gegenzug auch mehr Speicher. Bitte stellen Sie sicher, dass auf der ArcGIS Server-Maschine ausreichend Speicher verfügbar ist, um die Anpassung zu ermöglichen. Wenn der Dienst nicht stark nachgefragt wird, werden die zusätzlichen Instanzen nach einer Leerlaufzeit (Standard ist 1800 Sekunden) inaktiv und heruntergefahren, um Serverspeicher freizugeben.<\/P>
Ebenso ist es eine gute Strategie, das Minimum einer Service-Instanz (um das Maximum zu erreichen) zu erhöhen, um eine vorhersehbare Leistung zu erzielen. Dies wird für die beliebtesten Dienste empfohlen, aber beachten Sie, dass eine solche Konfiguration immer Speicher verbraucht (für diesen Dienst), da keine Instanzen nach Ablauf der Leerlaufzeit heruntergefahren werden.<\/P>
Geteilte Dienste haben ebenfalls Instanzeinstellungen, die angepasst werden können. Wenn ein geteilter Dienst jedoch so beliebt ist, dass er einem Lasttest unterzogen wird, sollte er so angepasst werden, dass er als traditioneller, dedizierter Dienst läuft.<\/P>
- Nicht alle ArcGIS-Dienste sind CPU-begrenzt<\/STRONG><\/LI><\/UL>Wenn ein ArcGIS-Dienst CPU-begrenzt ist, bedeutet dies, dass die Menge an Durchsatz (oder Kapazität), die er liefern kann, nur durch die Anzahl der CPUs auf der ArcGIS Server-Maschine(n) begrenzt ist. In vielerlei Hinsicht kann dies von Vorteil sein.<\/P>Dies ist jedoch nicht immer der Fall. Manchmal gibt es Engpässe in anderer Hardware wie z.B. im Netzwerk. Gelegentlich kann man auch auf einen Engpass in einer Softwarekomponente stoßen, der absichtlich oder unbeabsichtigt ist.<\/P>Daher ist das Sammeln von Hardware-Metriken während des Tests sehr wichtig. Die Beobachtung der Auslastung von CPU, Speicher, Netzwerk und Festplatte kann dem Tester/Analysten wichtige Informationen liefern, um zu verstehen, ob etwas die Skalierbarkeit des ArcGIS Server-Dienstes einschränkt und ob es an der Hardware des Servers oder des Testclients liegt.<\/P>Es geht um den Durchsatz (nicht um Benutzer)<\/STRONG><\/LI><\/UL>Der Durchsatz wird gemessen, Benutzer werden berechnet... sie sind zwei unterschiedliche Artefakte eines Tests.<\/P>In einem Test wird der Durchsatz typischerweise als Transaktionen pro Sekunde (oder Operationen pro Sekunde) definiert und sollte vom Testclient-Software gemessen werden. Andererseits kann die Definition eines „Benutzers“ variieren und wird normalerweise aus dem Durchsatz berechnet.<\/P>Da der Durchsatz direkt aus den Ergebnissen eines Lasttests beobachtet wird, ist er eine der besten Metriken zur Bestimmung der Skalierbarkeit einer Bereitstellung.<\/P>In diesem Zusammenhang ist ein Testthread (z.B. das Element, das mit zunehmendem Druck im Lasttest steigt) ebenfalls nicht dasselbe wie ein Benutzer. Die Anzahl der verwendeten Testthreads und deren Dauer werden typischerweise in der Schrittbelastungsdefinition eines Tests konfiguriert.<\/P>Überprüfen Sie, ob der Test erfolgreich war<\/STRONG><\/LI><\/UL>Der Abschluss eines Tests bedeutet nicht unbedingt, dass er „gut“ war und in der Lage war, die Fragen im Testplan erfolgreich zu beantworten. Es ist wichtig zu überprüfen und zu validieren, ob der Test die richtigen Anfragen gesendet hat und die erwarteten Antworten erhalten hat.<\/P>Eine schnelle manuelle Qualitätskontrolle (QC) der Anfragenzusammensetzung im Test kann bei ersterem helfen.<\/P>Während die Überwachung der durchschnittlichen Inhaltslänge (pro Antwort) bei letzterem helfen kann.<\/P>Die meisten Testsoftwares bieten eine Möglichkeit zur Erfassung der durchschnittlichen Inhaltslänge (oder ähnliches). Die allgemeine Faustregel besagt, dass dieser Wert während des Tests relativ konstant bleiben sollte. Wenn er stark ansteigt oder abfällt, wird eine weitere Untersuchung empfohlen, da die erwartete Antwort möglicherweise nicht zurückkommt (z.B. Fehler statt Bild- oder JSON-Inhalt) oder wenn die Antwort gültig aber stark variabel ist, könnte ein anderes Testdesign erforderlich sein.<\/P>Außerdem ist es wichtig festzustellen, ob die Anfragen selbst erfolgreich waren (z.B. HTTP 200). Einige Testsoftwares erlauben es dem Analysten möglicherweise, Validierungsprüfungen auf den Antworten innerhalb des Tests zu konfigurieren. Dennoch bietet das Profiling der durchschnittlichen Inhaltslänge meist eine genauere Sicht auf die erwartete Antwort vom Server.<\/P>Testergebnisse sind keine Garantie für die Unterstützung von X Benutzern<\/STRONG><\/LI><\/UL>Testergebnisse validieren nur den getesteten Workflow. Dieser getestete Workflow zeigt den Durchsatz für einen bestimmten Anfragetyp mit entsprechender Antwortzeit. Es verspricht oder garantiert nicht, dass die Bereitstellung X Benutzer unterstützt.<\/P>Denken Sie daran: Die Definition eines Benutzers kann variieren und für verschiedene Bereitstellungen unterschiedliche Bedeutungen haben.<\/P>Vermeiden Sie das Testen gemeinsamer Ressourcen wie ArcGIS Online oder Google Maps<\/STRONG><\/LI><\/UL>Kostenlose und öffentliche Serviceangebote von ArcGIS Online oder Google Maps sind für die „Community“ gedacht. Solche Ressourcen sind ziemlich robust und skalierbar, können aber nicht für jeden Benutzer leistungsoptimiert werden.<\/P>Da sie nicht direkt Teil einer On-Premise-Bereitstellung sind, sollten sie als „externe“ Ressource betrachtet werden. Daher sollten Anfragen an sie aus einem Lasttest entfernt werden, da sich der Test ausschließlich auf die Fähigkeiten der eigenen Hardware konzentrieren sollte.<\/P>Wiederholbare Testergebnisse<\/STRONG><\/LI><\/UL>Wenn die Ergebnisse eines Lasttests gegen einen ArcGIS Server-Dienst ähnliche Trendlinien über mehrere Testläufe zeigen (z.B. derselbe Durchsatz wird ungefähr zum gleichen Zeitpunkt im Test erreicht), gilt die Ressource allgemein als „stabil“. Wiederholbare Ergebnisse sind ein gutes Merkmal.<\/P>Wenn Ergebnisse nicht sofort wiederholbar sind, muss der Tester/Analyst tiefer schauen und versuchen das inkonsistente Verhalten zu verstehen. Es könnte sein, dass die Hardware für andere Anfragen als den Test verwendet wurde (z.B. ein anderer Benutzer auf dem System). Oder wenn die Bereitstellung auf gemeinsamer Infrastruktur lief (z.B. Virtualisierung), wurde die zugrundeliegende Hardware für andere Zwecke genutzt (andere virtuelle Maschinen führten ressourcenintensive Aufgaben aus). In solchen Fällen könnten Lasttests außerhalb der Spitzenzeiten reproduzierbarere Ergebnisse liefern und zeigen, dass der Dienst potenziell stabil sein kann.<\/P>Das Design von Tests/Workflows sollte realistisch sein und auf dem basieren, was von einem Benutzer erwartet wird<\/STRONG><\/LI><\/UL>Vermeiden Sie Theorien und Projektionen; konzentrieren Sie sich darauf, wie der Benutzer die Anwendung tatsächlich verwenden sollte... den erwarteten Workflow.
Lasttests können einfach durchzuführen sein, aber es ist auch leicht möglich den Umfang unnötig oder unwahrscheinliche Szenarien einzubeziehen.<\/P>Verstehen Sie den Wert<\/STRONG><\/LI><\/UL>Oftmals ist der Weg zu einem guten und nützlichen Test genauso wichtig wie der Test selbst. Als Analyst hilft Ihnen dies:<\/P>a) Die Prüfverfahren zu validieren<\/P>b) Die größte Fähigkeit zu haben, die Ergebnisse zu erklären, was wiederum Ihren Test wertvoll macht<\/P> 1) Einige Personen verlangen nicht nur Ergebnisse sondern auch Analysen und Schlussfolgerungen<\/P> 2) Seien Sie bereit diese Schlussfolgerungen mit Daten zu untermauern<\/P>Halten Sie es einfach<\/STRONG><\/LI><\/UL>Manchmal sind einfache und nicht übermäßig komplexe Tests am informativsten.<\/P>
