Testen der Skalierbarkeit von Webanwendungen

Zum Testen sollten Sie die Hardware, die der Produktion ähnelt, einschließlich Daten, Kapazität oder Volumen.

Beim Testen der Skalierbarkeit der Anwendung sollten die folgenden Leistungsfaktoren berücksichtigt werden: -

• Reaktionszeit
• Durchsatz
• JVM-Nutzung wie Heap, Non-Heap und GC-Intervalle
• Nutzung der Netzwerk-Bandbreite
• Serveraktivität einschließlich IO-, Benutzer- und Systemnutzung
• Geschwindigkeit beim Lesen/Schreiben der Festplatte
• Ähnliche Hardware-Konfigurationen wie bei der Produktion
• Wissen, wie skalierbar die Software istDas Testen der Skalierbarkeit beantwortet zum Beispiel die folgenden Fragen:
  1. Wie viele Benutzer kann ich hinzufügen, ohne die Leistung der Anwendung zu beeinträchtigen?
  2. Wird das Hinzufügen weiterer Server meine Leistungsprobleme lösen?
  3. Kann ich durch die Verdoppelung der Hardware die Anzahl der Benutzer verdoppeln?

  Die oben genannten Fragen können durch verschiedene Arten von Skalierungstests beantwortet werden, die im Folgenden kurz beschrieben werden:

  • Vorhersagbare Skalierbarkeit: Wenn Sie die Hardware statisch halten und die Anzahl der Benutzer erhöhen oder verringern, um zu sehen, ob die Leistung proportional beeinflusst wird, um die Vorhersagbarkeit des Systems zu kennen, spricht man von vorhersagbarer Skalierbarkeit.
  • Horizontale Skalierbarkeit: Wenn ein Server nicht ausreicht, um die aktuelle Arbeitslast zu bewältigen, wird der Prozess der Einführung eines neuen Servers, der die Arbeitslast mit dem aktuellen Server teilt, als Skalierung oder horizontale Skalierung bezeichnet.
  • Vertikale Skalierbarkeit: Wenn der aktuelle Server nicht ausreicht, um die Arbeitslast zu bewältigen, wird der Prozess des Ersetzens durch einen Server mit höherer Kapazität als vertikale Skalierung bezeichnet.
  Alle oben genannten Ansätze zum Testen der Skalierbarkeit haben ihre eigenen Vor- und Nachteile.
• Vorbereitungen für den TestBevor wir mit dem Test beginnen, müssen wir die Last mit einer ähnlichen Hardwarekonfiguration vorbereiten, die der Produktionsumgebung ähnelt, um den angenommenen eingehenden Datenverkehr in einer realen Situation zu verarbeiten.

  Bevor wir die Skalierbarkeit testen, müssen wir auch die Sollbruchstelle der Anwendung finden, indem wir Stresstests durchführen. Anhand der Ergebnisse des Stresstests können wir analysieren, wie viel Leistung wir erreichen und an welchem Punkt die Anwendung/der Server zusammenbricht.

  Nehmen wir an, dass 10000 Anfragen pro Sekunde, die auf den Server einprasseln, die Anwendung zum Erliegen bringen, dann ist dies die Sollbruchstelle, und wir könnten 80 % dieser Sollbruchstelle, d.h. 8000 Anfragen pro Sekunde, als Standardschwelle betrachten. Auf der Grundlage dieser Analyse sollten wir eine Skalierung der Anwendung planen, wenn die Auslastung diesen Schwellenwert erreicht. Außerdem hängt es von der Auslastung/Startzeit der Anwendung ab, einschließlich der Bereitstellung von Ressourcen zum Starten der Anwendung.

  Skalierbarkeit Testplan Für die Durchführung der Skalierbarkeitstests wurden die folgenden Schritte durchgeführt:
  1. Wählen Sie einen Prozess oder eine Funktionalität aus, der bzw. die ein End-to-End-Szenario oder ein häufig verwendetes Szenario für die Durchführung von Skalierbarkeitstests abdeckt.
  2. Definieren Sie Reaktionszeiten und andere kritische Leistungskriterien gemäß SLA
  3. Legen Sie fest, wie Sie die Skalierbarkeitstests durchführen, entweder mit Skripten oder Tools oder mehreren Umgebungen, und richten Sie die Umgebung ein.
  4. Stellen Sie sicher, dass alle erforderlichen Anpassungen, Konfigurationen oder Änderungen vor dem Testen vorgenommen werden.
  5. Führen Sie ein Beispielszenario aus, um sicherzustellen, dass alles erwartungsgemäß funktioniert, und führen Sie dann die geplanten Testszenarien aus.
  6. Ausführen von Lasttests
  7. Analysieren Sie die Ergebnisse und erstellen Sie einen Bericht

  Ausführen von Skalierbarkeitstests

  Ziel: Die zu testende Anwendung führt eine Login-Anfrage durch, die intern für Sicherheitsüberprüfungen umgeleitet wird und dann in der Anwendung landet. Hier ist das Ziel, 1 Million Anfragen zu erreichen, die die Anwendung in einem bestimmten Zeitraum auslösen, um sicherzustellen, dass die Umleitungen und die Anmeldung bei der Anwendung mit maximaler Erfolgsrate und minimaler Antwortzeit bei maximaler Auslastung der Ressourcen durchgeführt werden.

  Systemübersicht - bei einem einfachen Setup wird eine Docker-basierte Webanwendung in AKS bereitgestellt, die auf eine relationale Datenbank verweist.

  • Verwendet den Azure Event Hub Service mit aktiviertem Kafka
  • Verwendet Azure SQL Service
  Horizontale Skalierung - automatische Skalierung standardmäßig aktiviert mit Minimum 4PODS und Skalierung um 1 POD
• Skalierungsschwelle - wenn die CPU-Auslastung 40% des PODs übersteigt, wird die automatische Skalierung aktiviert und 1 neuer POD erstellt. Es wird kein auf Speicherressourcen basierender Skalierungsfilter angewandt. Ansatz zur Erreichung des Ziels: Um das oben genannte Ziel zu erreichen, haben wir die Tests in 2 Kategorien unterteilt, um die Engpässe in der Datenbank und im Anwendungscode separat zu ermitteln:
  • Datenbanklasttest - um langsame Abfragen und fehlende Optimierungen im DB-Schema wie Indizes und andere DB-Konfigurationen zu identifizieren

  • Lasttest der Anwendung - zur Identifizierung von Engpässen im Anwendungscode in Bezug auf optimierte Ausführung, Speichernutzung und andere Ressourcennutzung.

  Zunächst werden die Tests mit der Datenbank durchgeführt. Test 1 beschreibt den DB-Lasttest zur Ermittlung der anfänglichen Engpässe, bei dem Daten in die DB eingefügt werden. Test 1: Der erste Test begann mit dem Einfügen von 1K #Zeilen und dauerte insgesamt 14 Stunden.

  Identifizierte Probleme: Es wurde festgestellt, dass bestimmte DB-Aufrufe viel Zeit in Anspruch nehmen. Nach einer detaillierten Analyse wurden die Abfragen identifiziert, die diese Verzögerung verursachen, und die folgenden Änderungen vorgenommen:

  • geeignete Indizes hinzugefügt, damit die Abfrage schnellere Ergebnisse liefert

  Test 2: Getestet mit 2K #rows insertion und einige weitere Engpässe festgestellt, obwohl sich der Durchsatz stark verbessert hat.

  Identifizierte Probleme: Wir haben festgestellt, dass die DB-Aufrufe immer noch sehr viel Zeit in Anspruch nehmen und haben folgende Änderungen vorgenommen:
  • die Abfragen in der DB optimiert, so dass die Einfügungen viel schneller erfolgen

  Test 3: Nach den obigen Änderungen wurde Test 1 erneut durchgeführt und 1K #Zeilen wurden nun in 56 Sekunden eingefügt, was eine dramatische Leistungssteigerung darstellt!!! Die folgende Tabelle zeigt die Ergebnisse der oben genannten Tests:

  Test Nummer	# Zeilen in DB eingefügt	Benötigte Zeit
  Test 1	1K	14Stunden
  Test 2	2K	2Std. 43Min.
  Test 3	1K	56sek
  Test 4	50K	9min

  Test 4: Nachdem wir nun die DB-Aufrufe optimiert haben, haben wir die Anzahl der eingefügten Zeilen auf 50K erhöht, um zu prüfen, ob die DB mit wachsender Datenmenge stabil bleibt und bessere Ergebnisse liefert. Wir haben festgestellt, dass der Test 4 mit 50K eingefügten Zeilen aus Sicht der DB einen guten Durchsatz lieferte.

  Nachdem wir nun die DB-Größe optimiert haben, haben wir die Testphase auf die Anwendungsleistung verlagert. Hier würde der Skalierungstest 1 Million Anfragen in einer bestimmten Zeit durchführen, um Probleme im Zusammenhang mit der Anwendungslogik, JMV oder einer Cloud-Konfiguration zu erkennen.

  Während des Tests haben wir festgestellt, dass die Anfragen auf der Serverseite fehlschlagen. Nach der Analyse dieser Fehler haben wir festgestellt, dass die bestehenden Konfigurationen für den Test nicht geeignet sind und haben sie optimiert. Derselbe Test wird mehrmals wiederholt, um eventuelle weitere Probleme zu erkennen. Nach einigen Testzyklen haben wir die folgenden Optimierungen vorgenommen, um die Leistung der Anwendung zu verbessern.

  Konfigurieren Sie die automatische Skalierung des AKS-Durchsatzes CPU-Auslastung -40%. Wenn die CPU-Auslastung 25% des PODs überschreitet, wird automatisch ein neuer POD hinzugefügt.
  • Die Anzahl der Partitionen im Azure Event Hub Service wurde erhöht
  • Datenbankebene von S2 auf S4 erhöht
  • Aktualisiert auf Java 10 für eine bessere Ressourcenverwaltung in Docker-Containern
  • Optimierte Standardwerte für Docker-Container-Ressourcen
  Nach den obigen Optimierungen waren wir in der Lage, 1 Million Anfragen in einer Zeitspanne von 1 Stunde zu erreichen. Um diese 1 Million Anfragen zu erreichen, mussten wir die Anzahl der Benutzer auf 200 auf 2 virtuellen Maschinen skalieren. Außerdem mussten wir sicherstellen, dass die Anfragen nicht ohne Unterbrechung auf den Server einprasseln, da dies zu Fehlern auf der Serverseite während der Validierung führen würde. Wir haben also eine ideale Denkzeit von 120 Sekunden angenommen und den Test wie im unten gezeigten Szenario durchgeführt: Endgültiges Szenario

  #Users	#VMs	#Pro VM-Benutzer	Zeitspanne	Denkzeit	Gesamtzahl der Anfragen
  200	2	100	1h	120sec	1 Million

  Nachdem wir das obige Szenario getestet haben, haben wir die Statistiken analysiert und festgestellt, dass die durchschnittliche Reaktionszeit <1 Sekunde beträgt, was im akzeptablen Bereich liegt. Die folgende Tabelle fasst die Testergebnisse zusammen:

  Durchschnittliche Zeit (ms)	Min (ms)	Max(ms)	Median	95% Benutzer	Durchsatz /s
  934	22	79609	235	4283 ms	80 ms

  Das Azure-Echtzeitdiagramm, das während des Tests mit 1 Million ausgelösten Anfragen aufgenommen wurde, sehen Sie unten. Sie können sehen, dass die CPU-Auslastung 100% erreicht hat, was ein gutes Zeichen für die Ressourcennutzung ist. In Echtzeit sollten wir jedoch keine 100%ige Auslastung erreichen, da wir einen gewissen CPU-Puffer für das System und andere Prozesse auf dem Server haben sollten. Es wäre ideal, die CPU-Auslastung in der Produktion auf etwa 70%-80% zu begrenzen. Aber hier ist unser Ziel, den maximal möglichen Fall zu testen, um zu sehen, in welcher Zeit wir 1 Million Anfragen bei voller Auslastung der Ressourcen erreichen können, ohne etwas kaputt zu machen. Das Diagramm unten zeigt die eingehenden Anfragen an den Event Hub. Sie können sehen, dass wir 999,91k eingehende Nachrichten erreicht haben. Der folgende Screenshot zeigt die Anzahl der während des Tests eingesetzten Container und ihre maximale Auslastung. Sie können sehen, dass der erste Container im Vergleich zu den anderen Containern als erstes maximal ausgelastet ist und der Status OK lautet. was bedeutet, dass der Test erfolgreich war.