© Excellent backgrounds/Shutterstock.com
Java Magazin
Realistische Belastungsprofile für Webapplikationen

Lasttests mit Selenium

Häufig werden Lasttests so verstanden, dass eine Vielzahl unterschiedlicher Anfragen unkoordiniert an einen Server gesendet wird. In diesem Zustand kann beobachtet werden, wie sich ein System während einer Extremauslastung verhält und wo dessen Grenzen liegen. Wenn ein System asynchrone Vorgänge startet, die einen erheblichen Teil der Systemauslastung ausmachen, können Kennzahlen aus solchen Lasttests nur wenige Erkenntnisse enthalten. In diesem Fall ist es interessant, wie sich ein System unter hoher, aber realistischer Belastung verhält. Der folgende Artikel berichtet über die Erfahrungen aus einem Projekt, das dieser Frage nachgegangen ist.

Johannes Tonn


In unserer Abteilung wurde in den letzten Monaten eine Webapplikation zur Modernisierung eines etablierten Softwaresystems für den Datentransport entwickelt. Das vorhandene System basiert auf einer Rich-Client-/Server-Architektur mit zwei Serverkomponenten. Neben einem Applikationsserver existiert ein eigener Dateiserver, der eine verteilte Persistierung von Dateien ermöglicht. Der Zugriff auf beide Server erfolgt mit einem proprietären HTTP-basierten Protokoll. Die Webapplikation ist mit Googles JavaScript-Framework AngularJS implementiert. Zwischen der Webapplikation und dem bestehenden Applikationsserver vermittelt ein Apache Tomcat, der sich um TLS, WebSocket, Authentifizierung und das Session Handling kümmert. Er nimmt die Anfragen der Webapplikation an, reicht sie – soweit autorisiert – an den Applikationsserver weiter und vermittelt die Antwort.

Es liegt in der Natur einer Single Page Application (SPA), dass keine großen HTML-Seiten auf einem Server erstellt werden. Stattdessen werden genau die Daten nachgeladen, die der Benutzer gerade sehen möchte. Es werden Templates/Scripts nachgeladen und zyklische Aktualisierungen durchgeführt. Gleichzeitig findet die Kommunikation mit den bestehenden Rich Clients statt. Ein Teil der Anfragen kann z. B. durch Minifizierung und Einbettung von Templates verhindert werden. Das Grundproblem jedoch bleibt: Das Belastungsprofil der bestehenden Systeme ändert sich erheblich, und diese Auswirkungen sollten in einem Lasttest untersucht werden.

Klassische Belastungstests

Für einen klassischen Belastungstest werden unterschiedliche Anfragen zusammengestellt, die in hoher Frequenz an einen Server gesendet werden. Bei diesen Anfragen handelt es sich um API-Aufrufe auf der Serverseite, die im normalen Betrieb von einem Client (in unserem Fall die SPA) aufgerufen werden. Sinnvollerweise werden die Antwort und die Antwortzeit gegen einen definierten Toleranzbereich geprüft. Warum kann mit diesem Vorgehen kein realistisches Belastungsprofil generiert werden?

Das Verhalten einer SPA in einem Browsers muss nachgebildet werden: Zunächst lädt der Browser die SPA (statische Dateien), anschließend lädt diese selbst Dateien nach und beginnt, mit dem Server zu kommunizieren. Hier müssen Reihenfolgen und zeitliche Faktoren berücksichtigt werden.Die Verweildauer eines echten Benutzers variiert.Der Browser wird bei erneuten Besuchen statische Dateien aus dem Cache laden oder lediglich HEAD-Anfragen senden, um den Cache-Inhalt zu validier...

Java Magazin
Realistische Belastungsprofile für Webapplikationen

Lasttests mit Selenium

Häufig werden Lasttests so verstanden, dass eine Vielzahl unterschiedlicher Anfragen unkoordiniert an einen Server gesendet wird. In diesem Zustand kann beobachtet werden, wie sich ein System während einer Extremauslastung verhält und wo dessen Grenzen liegen. Wenn ein System asynchrone Vorgänge startet, die einen erheblichen Teil der Systemauslastung ausmachen, können Kennzahlen aus solchen Lasttests nur wenige Erkenntnisse enthalten. In diesem Fall ist es interessant, wie sich ein System unter hoher, aber realistischer Belastung verhält. Der folgende Artikel berichtet über die Erfahrungen aus einem Projekt, das dieser Frage nachgegangen ist.

Johannes Tonn


In unserer Abteilung wurde in den letzten Monaten eine Webapplikation zur Modernisierung eines etablierten Softwaresystems für den Datentransport entwickelt. Das vorhandene System basiert auf einer Rich-Client-/Server-Architektur mit zwei Serverkomponenten. Neben einem Applikationsserver existiert ein eigener Dateiserver, der eine verteilte Persistierung von Dateien ermöglicht. Der Zugriff auf beide Server erfolgt mit einem proprietären HTTP-basierten Protokoll. Die Webapplikation ist mit Googles JavaScript-Framework AngularJS implementiert. Zwischen der Webapplikation und dem bestehenden Applikationsserver vermittelt ein Apache Tomcat, der sich um TLS, WebSocket, Authentifizierung und das Session Handling kümmert. Er nimmt die Anfragen der Webapplikation an, reicht sie – soweit autorisiert – an den Applikationsserver weiter und vermittelt die Antwort.

Es liegt in der Natur einer Single Page Application (SPA), dass keine großen HTML-Seiten auf einem Server erstellt werden. Stattdessen werden genau die Daten nachgeladen, die der Benutzer gerade sehen möchte. Es werden Templates/Scripts nachgeladen und zyklische Aktualisierungen durchgeführt. Gleichzeitig findet die Kommunikation mit den bestehenden Rich Clients statt. Ein Teil der Anfragen kann z. B. durch Minifizierung und Einbettung von Templates verhindert werden. Das Grundproblem jedoch bleibt: Das Belastungsprofil der bestehenden Systeme ändert sich erheblich, und diese Auswirkungen sollten in einem Lasttest untersucht werden.

Klassische Belastungstests

Für einen klassischen Belastungstest werden unterschiedliche Anfragen zusammengestellt, die in hoher Frequenz an einen Server gesendet werden. Bei diesen Anfragen handelt es sich um API-Aufrufe auf der Serverseite, die im normalen Betrieb von einem Client (in unserem Fall die SPA) aufgerufen werden. Sinnvollerweise werden die Antwort und die Antwortzeit gegen einen definierten Toleranzbereich geprüft. Warum kann mit diesem Vorgehen kein realistisches Belastungsprofil generiert werden?

Das Verhalten einer SPA in einem Browsers muss nachgebildet werden: Zunächst lädt der Browser die SPA (statische Dateien), anschließend lädt diese selbst Dateien nach und beginnt, mit dem Server zu kommunizieren. Hier müssen Reihenfolgen und zeitliche Faktoren berücksichtigt werden.Die Verweildauer eines echten Benutzers variiert.Der Browser wird bei erneuten Besuchen statische Dateien aus dem Cache laden oder lediglich HEAD-Anfragen senden, um den Cache-Inhalt zu validier...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang