Unternehmen wollen Produkte entwickeln, die nicht nur funktional, sondern auch skalierbar, leistungsfähig und sicher sind. Um die Leistungsziele zu erreichen, müssen die Lasttests so nah wie möglich an den realen Anforderungen durchgeführt werden. Es gibt viele Aspekte, die berücksichtigt werden müssen, um den Echtzeit-Traffic zu imitieren, z. B. User Mix, Mix der Transaktionen, Denkpausen der Nutzer, Browser Mimicking (wie Caching, Cookies und paralleles Laden von Ressourcen), Serverkonfigurationen usw. Lasst uns jeden dieser Punkte besprechen.
Als Performancetester muss man die Szenarien/Arbeitsabläufe in Skripten simulieren, die die realen Anwendungsfälle abbilden, sonst sind die Ergebnisse des Lasttests für den Einsatz der Produkte möglicherweise nicht zuverlässig. Eine fehlende Implementierung von nutzerbedingten Denkpausen könnte dazu führen, dass bei gleicher Anzahl von Threads mehr Last als erwartet simuliert wird. Ebenso kann eine unsachgemäße Caching-Strategie dazu führen, dass die Antwortzeiten länger ausfallen, als es der tatsächliche Nutzer erlebt.
Es folgt eine unvollständige Liste von Faktoren, die bei der Simulation von Leistungstests als kritische Variablen für die Gestaltung der Arbeitslast fungieren:
Für die meisten Anwendungen gibt es verschiedene Arten von Nutzern. Wenn wir eine Webanwendung betrachten, die eine Schule darstellt, haben wir verschiedene Arten von Nutzern: Schulleiter, Lehrer, Schüler, Administratoren, IT usw. Auch was die Anzahl der Nutzer/innen angeht, ist die Verteilung nicht gleichmäßig. Es gibt z. B. mehr Schüler/innen als Lehrer/innen. Der Benutzermix soll die relative Verteilung der Anzahl der Threads in einer Performance-Testsimulation darstellen, die den verschiedenen Rollen entsprechen. Die Festlegung eines realistischen Nutzermixes ist sehr wichtig. Ein Nutzermix von 70 % Schülern, 20 % Lehrern und 10 % Administratoren ist an sich weder richtig noch falsch. Seine Korrektheit kann nur im Kontext einer bestimmten Anwendung in einem bestimmten Zeitrahmen der Nutzung bewertet werden.
Die modernen Anwendungen von heute haben eine Menge zu bieten. Es gibt Dutzende oder Hunderte von Arbeitsabläufen. Für Lasttests ist es eine mühsame Aufgabe, alle verfügbaren Workflows zu simulieren, und auch nicht praktikabel. Ein Tester muss die am meisten genutzten Vorgänge identifizieren, wie z. B. in einer Schule die Anwesenheitsbewertung, die Erteilung von Hausaufgaben, die Durchführung von Tests, die Notenvergabe, die Fahrt mit dem Schulbus usw., während die am meisten genutzten Vorgänge wie die Fahrt auf einen Schulausflug, die Bewertung von Impfungen oder die Beantragung von Urlaub zwar weniger genutzt werden, aber dennoch wichtig sind. Die Betrachtung der am häufigsten genutzten Vorgänge für Lasttests würde helfen zu verstehen, wie das Produkt auf die täglichen Aktivitäten reagiert. Diese Arbeitsabläufe müssen auf verschiedene Nutzertypen verteilt werden, wie wir unter Nutzermix besprochen haben.
Moderne Browser tun viel im Hintergrund, um dem Endnutzer ein optimales Erlebnis zu bieten, z. B. paralleles Laden von Ressourcen, Caching usw., um die Ladezeiten zu verkürzen. Die meisten Tools bieten diese Funktionen zwar standardmäßig an, aber man muss wissen, wie man sie aktiviert/deaktiviert/konfiguriert, um sie zu nutzen.
Während der Nutzung einer Anwendung füllen die Endnutzer Formulare aus oder brauchen Zeit, um die Seite zu lesen oder zu entscheiden, welchen Schritt sie als Nächstes tun wollen usw. Diese Aktionen brauchen Zeit und sind bei jedem Nutzer anders. Beim Performance-Testing bezeichnen wir dies als "User Think Time". Das Ausfüllen des Anmeldeformulars kann 4-8 Sekunden dauern (je nach Tippgeschwindigkeit und Temperament des Nutzers), das Lesen eines kleinen Absatzes kann 15-60 Sekunden dauern, je nach Umfang des Inhalts, der für den nächsten Schritt wie Akzeptieren/Zustimmen usw. erforderlich ist. Beim Skripting müssen User Think Times implementiert werden, sonst kann es passieren, dass wir am Ende mehr Last simulieren, als für eine bestimmte Nutzerlast vorgesehen ist, da mehr Anfragen in der gleichen Zeiteinheit generiert werden. Viele Tools erlauben die Verwendung von zufälligen Schlafzeiten in einem bestimmten Bereich, um ein realistisches Verhalten der verschiedenen Endnutzer zu erreichen.
Während wir die clientseitigen Konzepte besprochen haben, ist die richtige Serverkonfiguration ebenso wichtig. Die Serverkonfiguration muss so nah wie möglich an der Produktionsumgebung sein. Das können Ressourcen wie CPU, RAM, Speicherplatz, Netzwerkbandbreite usw. sein. Oder Konfigurationen wie Threads, Timeouts, Lastausgleich usw. All diese Konfigurationen müssen den Anforderungen der Produktion entsprechen, sonst sind die Ergebnisse des Lasttests möglicherweise nicht zuverlässig.
Das Motto eines jeden Performance-Testers ist es, die Last zu simulieren und den Test so nah wie möglich am Echtzeit-Traffic durchzuführen. Dies ermöglicht genaue Ergebnisse, auf die man sich beim Einsatz in der Produktionsumgebung verlassen kann. Die meisten Performance-Testing-Tools unterstützen alle oben genannten Konfigurationen. Diese Konzepte und Faktoren sind werkzeugunabhängig und können von den Testern unabhängig von ihrem funktionalen Kontext für alle Anwendungen angewendet werden.
Solltest Du einen Workshop rund um Performance Testing für Dich und Dein Team wünschen, kannst Du Dich gern an Naveen und unsere Engineering-Kollegen wenden.
trendig
