UX-Bridge - Technisches Datenblatt

Es wird davon ausgegangen, dass mit dem FirstSpirit Client 100 Redakteure gleichzeitig arbeiten. Dabei entstehen pro Tag 1.000 Änderungen im System (neue Inhalte oder Bearbeitung von bestehenden Inhalten). Zusätzlich gibt es einen automatischen Importmechanismus von Inhalten, der ebenfalls 1.000 Änderungen pro Tag erzeugt. Alle Änderungen werden über einen Arbeitsablauf freigegeben und deployed. Die Generierung umfasst sowohl vorgenerierte HTML-Dateien, die notwendigen Assets (Grafiken, CSS, JS) als auch die notwendigen Nachrichten, um die Daten im Content-Repository zu aktualisieren.

Als Webseite wurde das im Tutorial News-Szenario entwickelte Projekt verwendet. Details dazu finden Sie in der UX-Bridge Entwicklerdokumentation. Es handelt sich dabei um einen hybriden Internetauftritt mit dynamischen und vorgenerierten Anteilen. Im Newsbereich kommt eine dynamische Webapplikation zum Einsatz, die dem Benutzer die aktuellen Pressemitteilungen anzeigt und eine dynamische Filterung nach Kategorien ermöglicht. Die restlichen Seiten enthalten vorgeneriertes HTML.

Es wird angenommen, dass 30% der Seitenaufrufe auf die dynamische Webapplikation für die Pressemitteilungen entfallen. Die restlichen 70% sind Aufrufe von vorgenerierten Seiten. Dies erscheint realistisch, da die eigentliche Pressemitteilung eine vorgenerierte Seite ist und nur die Übersicht der Pressemitteilung dynamisch ausgeliefert wird.

Um das Benutzerverhalten so exakt wie möglich abzubilden, enthalten die Testszenarien entspreche think times. Diese wurden aus realem Surfverhalten extrapoliert. Die Verweildauer auf einer Seite variiert zwischen 1-4 Sekunden.

Ein simulierter Benutzer surft pro Besuch immer mehrere Seiten ab. Während eines Besuches wird ein Browsercache simuliert, so dass Designelemente, JavaScript und CSS nicht erneut angefordert werden müssen. Um das Browserverhalten nachzubilden, werden maximal 5 gleichzeitige Anfragen pro Benutzer erzeugt, um Ressourcen nachzuladen. Nach Beendigung einer solchen Sitzung wird der Cache wieder geleert.

Eine aufgerufene Webseite führt dabei im Durchschnitt zu 44 HTTP-Requests mit einem durchschnittlichen Übertragungsvolumen von 180kb. Befinden sich die Dateien im Browsercache, so reduziert sich das Übertragungsvolumen auf durchschnittlich 25kb.

Im Laufe des Testes werden bis zu 5000 gleichzeitige Benutzer auf der Webseite simuliert. Die Content-Änderungen durch das Redaktionssystem erfolgen im Test zeitgleich zu den Lasttests auf dem Webserver.

Dieser Graph stellt die benötige Zeit dar, um eine inhaltliche Änderung in das Content-Repository zu schreiben. Gemessen wurde die Zeit zwischen der Freigabe und dem Schreiben in das Content-Repository. Es gilt die Y-Achse links.

Die Spitze ganz zu Beginn lässt sich durch den Overhead des initialen Verbindungsaufbaus der einzelnen Komponenten erklären. Es ist deutlich zu sehen, dass die Last auf den Webservern keine Auswirkung auf diese Messgröße hat.

Durchschnittliche Antwortzeit aller Aufrufe von Webseiten (30% dynamisch, 70% statisch). Der Wert bezieht sich auf die komplette Seite inkl. Javascript, Stylesheets und Grafiken. Es gilt die Y-Achse links.

Erst ab ca. 4000 gleichzeitigen Benutzern ist ein kleiner Anstieg der Antwortzeiten zu erkennen. Gleichzeitig ist ein Anstieg der Load auf den jMeter-Instanzen und dem Webserver zu beobachten. Dabei ist die Load bei allen Maschinen noch im akzeptablen Bereich. Zudem deuten die Zahlen des Webservers darauf hin, dass ab dieser Zahl das Connection-Handling des Webservers zu einer Verschlechterung der Antwortzeiten führt.

Zahl der HTTP-Anfragen pro Sekunde die auf dem Webserver ankommen. Es gilt die rechte Y-Achse.

Die Ausschläge unter Volllast nach oben korrelieren mit einer erhöhten Last auf den jMeter. Diese wurde durch die Variablen think times verursacht. Die Messdaten zeigen, dass zu diesem Zeitpunkt deutlich mehr Requests von den jMeter-Instanzen erzeugt wurden.

Zahl der gleichzeitigen Benutzer auf der Webseite. Es gilt die rechte Y-Achse.

Der Graph entspricht genau dem erwarteten Verlauf. Die Ramp-Up- und Ramp-Down-Phase sind deutlich zu erkennen.

In der zweiten Grafik ist die Last der beteiligten Maschinen abgebildet. Keine der Maschinen wurde während des Testlaufes an seine Belastungsgrenzen gebracht. Für den FirstSpirit-Server, den Adapter und den UX-Bus stellten die Inhaltsänderungen keinerlei Problem dar. Der Applikationsserver wurde durch die Verwendung des Webservers als Proxy nur zeitweise belastet, so dass die durchschnittliche Last ebenfalls sehr gering ausfällt.