Alle Neuigkeiten

Liferay Performance Optimierungen für die DCCS Website
Liferay Performance Optimierungen für die DCCS Website

Mit dem Upgrade der Website auf 7.0 war es natürlich auch unser Ziel die bestmögliche Performance der DCCS Seitenlandschaft zu erreichen. Dazu haben wir uns der Anforderung von mehreren Seiten angenähert und am Ende ein schönes Ergebnis erreicht.

- Caching am Apache
- Optimierung der Bilder
- Optimierung der Seiten

Caching am Apache

Es ist eine übliche und sinnvolle Konfiguration Liferay hinter einen Reverse Proxy zu stellen. Man gewinnt dadurch viele Vorteile. Einerseits sicherheitstechnisch - der Tomcat mit Liferay müsste sonst z.B. mit Root/Administrator Rechten gestartet werden -, andererseits durch erhöhte Flexibilität (z.B. bei der SSL Konfiguration, beim Einrichten von Redirects oder beim Anbinden mehrerer Backend-Server).

Ein solcher Reverse Proxy ermöglicht es allerdings auch, Inhalte direkt von dem Reverse Proxy auszuliefern und nicht immer vom Backend zu holen. Aus historischen Gründen verwenden wir einen Apache Webserver haben dort Caching für die statischen Inhalte, Stylesheets, Javascript und Icons unserer Website konfiguriert. Damit wird der Liferay Server entlastet, der diese Inhalte wesentlich seltener ausliefern muss.

An dieser Stelle werden gerne Benchmarks gezeigt, wie sich ein solches Caching auf die Server Performance unter hoher Last auswirkt. Unsere entsprechenden Tests zeigten wie erwartet eine Verbesserung unter hoher Last, ähnlich wie sie auch im Liferay Community Blog schon im Detail aufgezeigt wurden.
Man darf solche Benchmarks allerdings nicht überbewerten. Die relevanten Inhalte werden auch in den Internet Browsern gecacht, ein solcher Cache wirkt sich also nur beim ersten Laden der Seite aus. Diverse Benchmarks im Internet zeigen zwar gerne, wie viele Tausend Requests pro Sekunde damit zusätzlich abgearbeitet werden können, aber in den meisten realistischen Szenarien sind diese Werte nicht wirklich aussagekräftig.

Unsere Seite muss keine Tausend Besucher pro Minute bedienen können, es ist viel wichtiger dem einzelnen Benutzer eine flotte Seite zu präsentieren. Bei geringer Last sind die Auswirkungen dieser Optimierung kaum spürbar. Wir empfehlen daher den Einsatz des Caching Features am Reverse Proxy nur bedingt.

Viel wichtiger ist, dass der einzelne Kunde, zumeist am Smartphone, ein tolles Surferlebnis hat. Und hier gilt es vor allem, die Datenmenge zu reduzieren.

Optimierung der Bilder

Bilder machen zumeist einen großen Teil der Inhaltsmengen aus, die von Webseiten ausgeliefert werden.

Kleine Vorschaubilder neben einer Liste von News

 Wenn ein Redakteur ein Bild für eine Seite einbindet, wählt er oft ein sehr großes Bild. Wir haben schon erlebt, dass 6 MB Bilder hochauflösender Kameras als winzige Vorschaubilder verwendet wurden. Gerade Mobile, mit oft schwankender Netzqualität, hat die Optimierung der Datenmengen höchste Priorität.

Man kann nun den Redakteuren natürlich die Möglichkeit geben, für jedes Device die passenden Bilder hochzuladen, in der Praxis hat sich aber gezeigt, dass das meist nicht funktioniert. Tatsächlich sollte das aber gar nicht Aufgabe des Redakteurs sein, sich darüber Gedanken zu machen. Er sollte ein qualitativ möglichst hochwertiges Bild verwenden und das Portal sollte sich um die Optimierung kümmern und das Bild in der passenden Größe für Desktop und Smartphone ausliefern.

Daher haben wir nach einer besseren Lösung gesucht. Die erste Idee war, das Bild mit einem Liferay Standardfeature zu verkleinern. Man kann bei Liferay mittels des Schalters "image.auto.scale" einschalten, dass Bilder automatisch verkleinert werden. Man muss allerdings die gewünschte Auflösung bei den Bildern angeben.

Das Feature hat allerdings den schwerwiegenden Nachteil, dass das verkleinerte Bild bei jedem Zugriff neu berechnet wird. Es dauerte nach unseren Messungen mehrere hundert Millisekunden zusätzlich das Bild ausliefern zu lassen. Die Ersparnis durch das kleinere Bild wird dabei mehr als wieder wettgemacht. Ein weiterer Nachteil war die Qualität des Bildes. Die verwendete Java Bibliothek leistet zwar recht gute Arbeit, kann aber mit diversen Tools wie ImageMagick nicht ganz mithalten.

Eine neuere Möglichkeit wurde durch Liferay "Adaptive Media", was in 7.1 standardmäßig installiert ist, eingeführt. Allerdings hat sich das als relativ kompliziert und nicht ganz passend für unsere Usecases herausgestellt. Das Modul optimiert das jeweilige Bild leider anhand der Bildschirmauflösung des Betrachters, ein winziges Vorschaubild wird damit immer noch mit 2560px Breite ausgeliefert. Wir fanden das nicht besonders zielführend.

Daher haben wir uns entschieden, das Ausliefern der Bilder durch eine Eigenentwicklung umzusetzen. Unser ImageOptimizer prüft die Berechtigungen auf dem Bild, skaliert das Bild mittels ImageMagick und cacht die optimierte Version. Zur weiteren Verbesserung der Bilder ist noch die Verwendung von Tools wie jpegoptim oder optipng möglich.

Da wir für Inhalte praktisch ausschließlich Strukturen & Templates verwenden, war es einfach dort statt des normalen Documents & Media Links unseren eigenen einzusetzen und damit in den Genuss von optimierten Bildern für Desktop und Mobile zu kommen.

Allein bei diesen drei kleinen Bildern auf unserer Startseite haben wir damit mehr als 1MB eingespart, die nicht ausgeliefert werden müssen. Diese Verbesserung hätte sich in diesem spezifischen Fall natürlich auch durch manuelle Erstellung passender Bilder erreichen lassen, aber das dazu notwendige Wissen ist oft nicht vorhanden. Wenn für Desktop und Mobile andere Bilder ausgeliefert werden müssen, ist das Problem durch einen Redakteur, ohne Anpassung durch einen Entwickler, gar nicht lösbar. Mit unserer Verbesserung kann sich der Redakteur zurücklehnen und einfach das beste/größte Bild hochladen. Der Rest passiert automatisch.

Optimierung der Seiten

Wir hatten initial hier einen sehr schwachen virtuellen Server mit nur einer CPU, die er sich auch noch mit anderen Services teilt. Leider mussten wir feststellen, dass das Ausliefern mancher Inhaltsseiten mehr als 1 Sekunde dauerte. Das ist kein akzeptabler Wert, ideal sind Zeiten unter einer Zehntelsekunde. Natürlich kann man dem System auch einfach mehr Prozessoren zuzuweisen, was in den meisten Fällen ebenfalls genügt, aber wir hatten hier den Ergeiz, dass es auch mit wenig Leistung zufriedenstellend funktionieren solle.

In einem ersten Versuch begannen wir, die Seiten ebenfalls am Apache zu cachen. Grundsätzlich hat das gar nicht schlecht funktioniert, aber einige Probleme verursacht. Wir hätten für angemeldete Benutzer/Editoren einen Zugang ohne Cache anlegen müssen, damit sie überhaupt Inhalte editieren können oder alternativ irgendwie am Reverse Proxy zwischen angemeldeten Benutzern und normalen Benutzern unterscheiden müssen. Außerdem hätten wir der Redaktion eine Möglichkeit zum löschen des Cache zur Verfügung stellen müssen, da ja jegliche Änderung unwirksam wäre, solange die ganze Seite aus dem Reverse Prox Cache kommt.

Der Versuch erwies sich daher in unserem Context als nicht praktikabel. Für einige Spezialfälle wäre der Ansatz allerdings denkbar.

Um festzustellen, wo die Zeit verbraucht wird, haben wir nachgemessen. Dabei fiel uns auf, dass Inhaltsportlets wie Assetpublisher und sogar Webcontent Display sehr viel Zeit benötigten. (Technisches Detail: Wenn man das Debug-Logging der RuntimePageImpl Klasse aktiviert, sieht man, welches Portlet wie viel Zeit benötigt)

Nach einigen weiteren Versuchen gelang es uns dann, die Portlets Asset Publisher, Webcontent Display und Navigation Portlet komplett zu cachen. Wenn die Seite aufgerufen wird, werden diese Seitenteile aus dem Cache geholt und überhaupt nicht mehr berechnet. Tatsächlich erreichten wird damit eine Verbesserung von 700 - 1500 ms pro Seite auf 20 - 80 ms pro Seite.

Wir haben zwar inzwischen dem System mehr Prozessoren spendiert, was den Effekt etwas gedämpft hat:

Optimierte Seite:          4,709 Sekunden (100 Aufrufe)

Ohne Optimierung:   19,812 Sekunden (100 Aufrufe)

Diese Optimierung wirkt sich natürlich auch auf den Einzelbenutzer aus, jeder Klick wirkt spürbar flotter.

Fazit

Der Cache am Reverse Proxy mag zwar bei hoher Last einen Vorteil bringen, bei geringer Last konnten wir keinen echten Vorteil feststellen. Durch automatische Optimierung der Bildgrößen gelang es uns einerseits hohen Komfort für den Redakteur zu erreichen, andererseits aber auch passende kleine Bilder für den jeweiligen Zweck und das jeweilige Device (Desktop, Mobile) auszuliefern. Die Optimierung der Seiten sorgte dafür, dass die Seiten nicht nur objektiv schneller ausgeliefert werden, auch das subjektive Verhalten für den Nutzer verbesserte sich massiv.      

 
Ihr Ansprechpartner
Christoph Rabel
cr@dccs.at