Das vorliegende Technische Datenblatt gilt für die aktuell freigegebene UX-Bridge Release-Version 1.6.6. Es beschreibt im Kapitel Systemvoraussetzungen die benötigten Komponenten zum Betrieb des UX-Bridge-Moduls. Die Hinweise zum Sizing resultieren aus den Ergebnisse der Lasttests.
Das UX-Bridge-Modul wurde mit FirstSpirit 5.2 entwickelt und getestet. Allerdings besteht bis einschließlich zur UX-Bridge-Version 1.6.5 auch Kompatibilität zu FirstSpirit 4.2R4, mit folgender Ausnahme:
Systemvoraussetzungen zur Installation von FirstSpirit können dem Technischen Datenblatt zu FirstSpirit entnommen werden.
Zum Betrieb des UX-Busses werden folgende Anforderungen an das System gestellt.
Die oben genannten Mindestanforderungen sollten für alle Szenarien ausreichend sein, in denen der UX-Bus primär für das Schreiben der Daten von FirstSpirit in ein oder mehrere Content-Repositories verwendet wird. Ein solcher Anwendungsfall wurde im Rahmen der Lasttests geprüft. Die Ergebnisse finden Sie im nächsten Kapitel.
Soll der UX-Bus als zentrale Nachrichtenkomponente innerhalb der Webseiten-Infrastruktur dienen, so sind ggf. mehr Ressourcen notwendig. Kandidaten sind Szenarien, in denen pro Request der Webapplikation eine Nachricht auf den UX-Bus geschickt wird, beispielsweise um das Userverhalten zu analysieren. Details zur Skalierung des UX-Busses finden Sie in der UX-Bridge-Installationsanleitung. Für solche Szenarien sollte innerhalb des Projekts immer ein entsprechender Lasttest durchgeführt werden, um sicherzustellen, dass die Anforderung an Performance und Skalierbarkeit auch erfüllt werden.
Im Rahmen der Entwicklung der UX-Bridge wurden Lasttests durchgeführt. Die Zielsetzung war, ein möglichst realistisches Szenario zu entwickeln, welches eine konkrete Nutzung der UX-Bridge im Rahmen einer Webseite simuliert, die sowohl dynamische als auch vorgenerierte Inhalte enthält.
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.
Um die Zahl der Benutzer einfach skalieren zu können, wurde der komplette Test auf der Amazon Cloudinfrastruktur durchgeführt. Dabei wurden bewusst alle Komponenten auf dedizierte Instanzen installiert, um etwaige Flaschenhälse einfacher identifizieren zu können.
Details zu den Amazon EC2 Instanztypen finden Sie unter http://aws.amazon.com/de/ec2/instance-types/.
Dort finden Sie auch Hinweise welcher Hardware die Instanzen in etwa entsprechen.
Ein EC2 Compute Unit bietet die entsprechende CPU-Kapazität eines 1,0-1,2 GHz Opteron oder Xeon Prozessors von 2007.
Die beteiligten Systeme waren:
Jedes System (bis auf die jMeter Instanzen für die Client-Simulation) war nur einmal vorhanden, d.h. es wurde hier noch keinerlei Clustering zur Performance-Verbesserung betrieben.
Der Webserver wurde als Proxy für den Tomcat konfiguriert. Da die dynamische Webapplikation keine personalisierten Inhalte ausliefert, kann der Webserver die vom Tomcat erhaltenen Inhalte für maximal eine Minute cachen. Findet während dieser Zeit eine Inhaltsänderung durch das Redaktionssystem statt, so wird der Cache entsprechend vorher invalidiert, so dass die Änderung sofort auf der Webseite sichtbar wird.
In einer Ramp-Up-Phase von 30 Minuten wurde die Zahl der Webseitenbesucher bis auf 5000 gleichzeitige Benutzer gesteigert. Diese Last wurde über 1 Stunde gehalten, gefolgt von einer Ramp-Down-Phase von 10 Minuten. Für Contentänderungen im Redaktionssystem gab es keine Ramp-Up- bzw. Ramp-Down-Phasen. Hier wurden eine konstante Erstellung von Inhalten sowie ein anschließendes Deployment durchgeführt.
Die Erfassung aller relevanten Messdaten erfolgte über eine Reihe von Werkzeugen und wurde zentral in einer Graphite-Instanz (siehe http://graphite.wikidot.com/) gesammelt und visualisiert.