Teil 5 - Grails in Produktion – mit Apache, Tomcat und MySQL

von Peter Soth

In meinem letzten Blog-Post dieser Serie (hier geht es zum ersten Blog-Post) möchte ich das Thema Lasttest im Kontext von Grails Web Applikationen adressieren, und warum diese so wichtig sind. Wir wissen alle, dass Lasttests in den meisten Projekten gerne vernachlässigt werden. Mit diesem Blogpost möchte ich zeigen, dass es gar nicht so schwierig ist einen Lasttest durchzuführen. Wir benutzen hierzu JMeter von Apache. Es hat sich gezeigt, dass JMeter vollkommen ausreicht. Die Anschaffung einer teuren Lösung wie HP Loadrunner ist für Lasttests von reinen Web-Applikationen nicht zwingend notwendig.

Warum sind Lasttests überhaupt wichtig?

Mit Lasttests lassen sich folgende Aspekte beleuchten:

  • Skalierbarkeit – hierbei wird überprüft, ob die Applikation skaliert, sprich eine gewünschte Benutzerlast abgearbeitet und ob durch hinzufügen weiterer Knoten in ein Cluster eine weitere Anzahl von Benutzern bedient werden kann. Jeder weiter hinzugefügte Clusterknoten soll die gleiche Anzahl von Benutzern bedienen können. Hierbei stellt man schnell fest, ob bspw. die Einstellungen der Java Virtual Machine oder die Größe des MySQL Connection Pools stimmen.
  • Parallelität – Anwendungen, die auf einem Tomcat-Server laufen unterscheiden sich von reinen Client-Anwendungen dadurch, dass mehrere Benutzer „gleichzeitig“ bedient werden. Hierfür erhält jede Benutzeranfrage ein Zeitfenster, in der die Anfrage abgearbeitet wird. Dies bedeutet, dass Codestellen zeitversetzt (quasi parallel) abgearbeitet werden. Dies ist vor allem bei Grails Services der Fall, die per Standardeinstellung als Singleton laufen. Fehler in der Parallelität  können im schlimmsten Fall dazu führen, dass sich die Tomcat-Threads unter Last selbst blockieren - da der eine Thread auf eine Resource (bspw. Datenbank) wartet, die von einem anderen Thread blockiert wird - oder dass ein Benutzer Informationen angezeigt bekommt, die eigentlich für diesen nicht bestimmt waren.

Warum eine Thinking-Time wichtig ist?

Ich habe es oft erlebt, dass Applikation totgefahren werden, indem keine Thinking-Time benutzt wurde und zusätzlich bspw. alle Portlets in einer Endlos-Schleife arbeiteten. Diese Herangehensweise ist vergleichbar mit einem Autofahrer, der den Drehzahlbegrenzer ausbaut und sich dann wundert, wenn der Motor bei einer viel zu hohen Drehzahl den Geist aufgibt.
Bei einem Lasttest werden parallele User simuliert indem JMeter für jeden Test-User einen Thread öffnet. Über die Thinking-Time erhält ein User-Thread auf dem Tomcat-Server - auf dem die zu testende Applikation läuft - wieder eine Verschnaufpause um wichtige Resourcen wie bspw. Speicher oder Datenbank-Connections freizugeben. Ich benutze hier gerne einen Wert zwischen 7 und 10 Sekunden und dies in Verbindung mit einem Gaussian Random Timer in JMeter. Hiermit kann ich dann die Thinking-Time zwischen bspw. 8 und 10 Sekunden variieren lassen.

Welche Schritte sind für einen Lasttest notwendig?

Ich gehe hierbei folgendermaßen vor:

  • Ich konfiguriere in JMeter einen HTTP Proxy [1]
     
  • Dann konfiguriere ich in einem Browser bspw. Firefox den Proxy-Port.
  • Nun beginne ich mich durch die Applikation zu hangeln. Wichtig hierbei ist, auch die Schreibzugriffe zu testen. Dies wird meistens vergessen oder viele wissen nicht, dass dies mit JMeter überhaupt möglich ist. Folgender Link [2] listet alle Funktionen und Variablen von JMeter auf. Diese benutze ich um Dummy-Attributnamen zu erzeugen. Das Bild rechts unten zeigt die JMeter-Konsole. Die Verwendung von Dummy-Attributen reicht in den meisten Fällen vollkommen aus. Wer es noch komplexer braucht kann in JMeter auch Testdaten per CSV Datei zur Verfügung stellen.
  • Nach jedem Klick füge ich dann einen Gaussian Random Timer ein, damit nach jedem Klick das System eine Verschnaufpause erhält.
  • Nachdem ich eine typische Benutzerinteraktion in JMeter erfasst habe, beginne ich den Lasttest zu starten. Bei der Simulation der parallelen Benutzer starte ich immer klein mit 10 und dann geht es weiter mit 20, 50, 150, 200, 250 und so weiter. Niemals gleich mit einer großen Last starten.
  • Das Monitoring des Lasttests kann mit folgenden Tools auf den jeweiligen Tiers des Clusters durchgeführt werden:
    • Apache Web-Server: JKStatus Konsole. Beschrieben im zweiten Teil meiner Blog-Serie.
    • Tomcat: PSI-Probe. Beschrieben im dritten Teil meiner Blog-Serie.
    • MySQL: Mit den Tools mysqltuner und tuning-primer. Beschrieben im vierten Teil meiner Blog-Serie.

Fazit

Mit diesem Blog-Post wollte ich kurz aufzeigen, wie einfach es ist mit JMeter einen Lasttest durchzuführen. Erst ein Lasttest gibt die Gewissheit, dass eine Grails Web-Applikation auch zuverlässig läuft.

Zurück

© 2006-2024 exensio GmbH
Einstellungen gespeichert
Datenschutzeinstellungen

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell, während andere uns helfen, diese Website und Ihre Erfahrung zu verbessern.

Sie können Ihre Einwilligung jederzeit ändern oder widerrufen, indem Sie auf den Link in der Datenschutzerklärung klicken.

Zu den gesetzlichen Rechenschaftspflichten gehört die Einwilligung (Opt-In) zu protokollieren und archivieren. Aus diesem Grund wird Ihre Opt-In Entscheidung in eine LOG-Datei geschrieben. In dieser Datei werden folgende Daten gespeichert:

 

  • IP-Adresse des Besuchers
  • Vom Besucher gewählte Datenschutzeinstellung (Privacy Level)
  • Datum und Zeit des Speicherns
  • Domain
You are using an outdated browser. The website may not be displayed correctly. Close