Zum Magazin

Web Service Lasttest mit simulierten Nutzern

Singen und Tanzen sind ein wichtiger Teil der lettischen Kultur. Alle fünf Jahre findet eine große Song and Dance Feier statt, die das meistbesuchte Event des Landes ist. Der Verkauf von Tickets für dieses Event ist eine sehr anspruchsvolle Aufgabe.

Web Service Lasttest mit simulierten Nutzern
Blagovest Ouglechov 23.09.24

S uchen Sie ein Tool, das die Last auf Ihren Web Services realistisch simulieren kann? Dann lesen Sie mehr über unser neues Tool zur Lasttestautomatisierung in diesem Beitrag.

Einleitung

Die Tickets für die diesjährige Feier wurden im März online und in den Ticketläden verkauft. Fast 100.000 Tickets für 19 Veranstaltungen waren innerhalb weniger Stunden ausverkauft. Wie viele vorhergesagt hatten, verlief der Ticketverkauf nicht wie geplant, da es viele technische Herausforderungen gab.

Unsere Entwicklung

Wir entwickeln derzeit ein Tool zum Lasttest von Web Services, das die Last simulieren kann, die von Nutzern erzeugt wird. Dieser Blogbeitrag beschreibt unsere Erfahrungen bei der Entwicklung dieses Tools. Es gibt viele Dinge, die schiefgehen können, wenn die Belastung steigt, aber wir glauben, dass unser Tool Ihnen helfen kann, Probleme zu identifizieren, bevor sie zu realen Problemen werden.

Herausforderungen

Was kann schiefgehen?

Große Belastungen bringen in der Regel viele Herausforderungen mit sich, auf die Dienstleister vorbereitet sein müssen, beginnend mit der großen Nutzerlast bis hin zu Angriffen auf das System. Wenn man eine große Belastung erwartet, ist das absolute Minimum, das getestet werden sollte, ob die Server die gesamte Last bewältigen können. Große Belastungen können zu Wettlaufbedingungen führen, die unter normalen Bedingungen nicht beobachtet werden. Solche Wettlaufbedingungen können parallelen Datenbankzugriff, Netzwerkbandbreite oder Probleme mit gemeinsam genutzten Variablen umfassen, die nicht auftreten, wenn nur wenige Personen den Dienst gleichzeitig nutzen.

Sicherheit und DoS-Attacken

Eine weitere Herausforderung, auf die sich Dienstleister vorbereiten müssen, ist eine Denial-of-Service (DoS)-Attacke. Bei deutlich höheren Belastungen als üblich kann diese Belastung leicht zu einer unbeabsichtigten DoS werden, da die Server nicht in der Lage sind, so viel Last zu bewältigen. Besonders wenn die Netzwerkschnittstelle die zusätzliche Last nicht verarbeiten kann oder der erhöhte Verkehr unerwartet ist.

Es könnte auch jemand versuchen, einen verteilten DoS-Angriff zu starten, um das System weiter zu verlangsamen. In jedem Fall sollte es einen Mechanismus geben, der eine DoS verhindert, indem die Last auf mehrere Handler verteilt wird oder Anfragen aus einer einzigen Stelle begrenzt werden. Auch generelle Sicherheitsbedrohungen müssen berücksichtigt werden, z. B. Cross-Site-Scripting oder SQL-Injectionen - diese Angriffe könnten die Datenintegrität ernsthaft gefährden oder zu Datenlecks führen.

Unsere Lösung

Unsere Lösung

Seit über einem Jahr entwickeln wir ein Framework, das helfen kann, potenzielle Probleme durch Lasttests zu identifizieren. Die Idee hinter diesem Framework ist es, so viele Nutzer wie möglich zu simulieren, ohne dabei Bedingungen zu opfern, z. B. browserbezogene Probleme. Das bedeutet, dass Sie ein sehr realistisches Setup erstellen können, um das Verhalten des Dienstes aus der Sicht des Endbenutzers zu überwachen.

Hauptmerkmale

Um realistische Szenarien für Lasttests zu simulieren und Skalierbarkeit aufrechtzuerhalten, mussten wir eine Reihe von Hauptmerkmalen entwickeln:

  • Testen der Kommunikation zwischen Frontend-Anwendung und Backend-Servern unter schlechten Netzwerkbedingungen.
  • Testen der Serviceverfügbarkeit aus verschiedenen Regionen weltweit.
  • Unterstützung mehrerer Browser.
  • Für spezifischere Anwendungen bieten wir Audio- und Videoübertragung, um die Eingabe von Webcam und Mikrofon des Benutzers zu simulieren.
Alles in allem gibt es Hunderte von möglichen Konfigurationen, die Sie während erhöhter Lastsituationen testen können. Die Kombination all dieser Optionen mit einem automatisierten Setup für simulierte Benutzer ergibt ein großartiges und einfach einzurichtendes Lasttesttool.

Ein Beispiel

Ein Beispiel

Angenommen, wir wollen einen Online-Video-Streaming-Dienst testen. In diesem Fall möchten wir die gleichzeitige Nutzung von Videos durch viele Benutzer sowie DoS testen - beide Szenarien sind mit unserem Framework testbar.

Wir müssen mehrere Schritte unternehmen, um uns auf diese Anwendungsfälle vorzubereiten. Zuerst definieren wir die Anzahl der Nutzer, die wir simulieren möchten, und teilen diese Nutzer in logische Gruppen ein. Video-Streaming-Dienste bieten in der Regel viele Videos an, daher macht es Sinn, die Nutzer nach den Videos zu sortieren, die sie ansehen werden. Auf diese Weise können wir testen, ob viele Nutzer ein bestimmtes Video ansehen, während andere Nutzer etwas anderes ansehen. Wir nennen diese Gruppen „Räume“.

Nachdem wir unsere Gruppen definiert haben, müssen wir das Testskript schreiben. Keine Sorge, es ist einfach! Das Framework unterstützt das Selenium-Scripting mit der NightWatch JS-Syntax. Alles, was Sie tun müssen, ist Aktionen zu komponieren, die die simulierten Benutzer ausführen sollen, sowie einige Assertions während des Tests.


function(client) { var roomName = 'loadero_demo'; client .url('https://appr.tc/r/'+roomName+client.globals.room) .waitForElementVisible('body', 10*1000) .click('#confirm-join-button') .pause(30*1000) .assert.cssClassPresent("#remote-video", "active") .pause(30*1000); }


Dieser Beispielcode beschreibt ein Testskript zum Starten eines Videoanrufs zwischen zwei Teilnehmern auf Google's Appr.tc.

Sie können entscheiden, in welchem Tempo die Benutzer beitreten. Für gängige Anwendungsfälle würden die Benutzer zu einem bestimmten Zeitpunkt schnell beitreten und das Tempo kurz vor dem Ereignis verlangsamen. Dieser Graph veranschaulicht die potenzielle Gesamtzahl der Benutzer im Laufe der Zeit.

Um ein realistisches Szenario zu simulieren, wollen wir nicht, dass alle Benutzer gleichzeitig den Dienst nutzen. Daher müssen wir eine Anlaufzeit konfigurieren. Die Anlaufzeit definieren wir mit zwei Parametern: der Gesamtzeit, die alle Benutzer benötigen, um sich anzuschließen, und der Anschlussfunktion. In manchen Anwendungsfällen möchten Sie, dass Benutzer in einem konstanten Tempo beitreten, während in anderen Anwendungsfällen ein plötzlicher Anstieg nach einigen ruhigen Minuten erwünscht sein kann.

Benutzerkonfiguration

Sobald das Skript fertig ist, müssen wir die Benutzer konfigurieren. Dies geschieht in zwei Schritten:

  • Definiere Räume und spezifiziere Benutzerkonfigurationen in jedem Raum.
  • Während der Erstellung des Skripts haben wir verschiedene Aktionen für Benutzer definiert, die zu den angegebenen Räumen gehören. In dieser Phase müssen wir die entsprechende Anzahl von Räumen definieren. In jedem Raum legen wir dann fest, wie viele Benutzer wir haben möchten. Wenn unsere Hauptbenutzerschaft beispielsweise aus Europa stammte, könnten wir eine Benutzerverteilung nach Regionen wie folgt vornehmen: Für jeden 20 Benutzer aus Europa fügen wir sieben Benutzer aus den Vereinigten Staaten und drei Benutzer aus Asien hinzu.
Wir können Browser für diese Benutzer mischen und ihre Netzwerkbedingungen einstellen, um Hochgeschwindigkeitsverbindungen, 4G, 3G oder Verbindungen mit begrenzter Geschwindigkeit zu simulieren.

Ergebnisse

Der schwierigste Teil ist erledigt, und wir können die Tests starten und die Ergebnisse auswerten. Die Ergebnisse enthalten viele nützliche Daten, die dazu beitragen, das Geschehen auf der Clientseite zu verstehen. Beginnen wir mit den Grundlagen - der Erfolgsquote. Dies zeigt, ob die simulierten Benutzer ihre Aktionen erfolgreich abschließen konnten. Abgesehen von der allgemeinen Erfolgsquote können wir den Belastungsgrad zu jedem Zeitpunkt rekonstruieren, der gegen die Webanwendung gerichtet war. Darüber hinaus gibt es komplexe Kennzahlen wie Statistiken der Benutzermaschine (CPU-Auslastung, RAM-Auslastung usw.) oder WebRTC-Statistiken, falls dies für den Dienst relevant ist.

Die Kennzahlen können auf verschiedene Arten bewertet werden, z. B. nach Region, Browser oder einem anderen gemeinsamen Parameter. Beachten Sie: Für eine genauere Datenerfassung empfehlen wir, diese Kennzahlen zusammen mit den Kennzahlen zu betrachten, die von den Servern der Anwendung gesammelt wurden.

Fazit

Unser hauseigenes Tool kann die Lasttestinfrastruktur mit minimalem Setup und konfigurierbaren einzelnen Benutzern bereitstellen. In Kombination mit der Expertise unserer Ingenieure sind die Möglichkeiten grenzenlos.

Dieses Framework eignet sich am besten für neue Produkte, die den Markt betreten wollen und sich nicht sicher sind, welche Leistungsfähigkeit ihre Server haben. Unternehmen mit bestehenden Produkten können dieses Tool nutzen, um ihre Infrastruktur auf erhöhte Belastungen zu testen oder neue Releases zu testen. Darüber hinaus kann jede WebRTC-Anwendung auch ihre Nicht-HTTP-Server testen.

QA-Manager (w/m/d)

Q-Centric GmbH (Telekommunikation)
Veröffentlicht: 26.08.24
Manager
Vollzeit
55.000,00 € - 70.000,00 €
01.09.2024
Lazarettstraße 4, München
Berufserfahrung: 3 Jahre

Testmanager (m/w/d) | Telekommunikation

Q-centric GmbH (Telekommunikation)
Veröffentlicht: 26.08.24
Freiberuflich
100% Auslastung
15.09.2024
90% Remote & 10% Leipzig
Berufserfahrung: 4 Jahre

Test Automation Expert (m/w/d)

Q-Centric GmbH (IT-Consulting)
Veröffentlicht: 05.07.24
Festanstellung
40 Stunden
55.000,00 € - 70.000,00 €
01.08.2024
Lazarettstraße 4, München
Berufserfahrung: 2 Jahre

Blagovest Ouglechov
Blagovest Ouglechov
Geschäftsführer

Mehr als 14 Jahre Erfahrung im Software Testing

Experte in Test- und Processautomation

Kontaktieren Sie uns