0

OFBiz Performance Optimierung

Geschrieben am 13.01.2012 in Projekte, Technik von Sebastian Leitner

In einem Kundenprojekt haben wir an dem Thema Performance gearbeitet und konnten durch einige wenige Einstellungen mit sehr überschaubarem Aufwand deutlich sichtbare Verbesserungen erzielen. Die Ergebnisse möchten wir hier teilen.

Ausgangssituation

Der Kunde betreibt ein geschlossenes B2B-Portal auf OFBiz-Basis, das auf zwei Systemen gehostet wird: ein Server stellt die Datenbank bereit, auf einem weiteren läuft der Webserver (hier Apache2) sowie das OFBiz-System mit dem mitgelieferten Tomcat Application Server. Viele Informationen, wie z. B. Preise oder Lagerbestände, kommen per synchroner Integration in Echtzeit aus einem externen ERP-System. Eingehende Requests landen auf dem Apache Webserver und werden von dort über den von OFBiz mitglieferten HTTP-Connector an den Tomcat weiter geroutet.

Vorgehensweise und Art der Messungen

Es wurde eine Kategorie-Seite 50 mal aufgerufen und jeweils gemessen, wie viel Zeit verstrich, bis die Seite im Browser komplett dargestellt wurde. Es wurde also die Ladezeit von Grafiken, CSS- und Javascript-Dateien sowie das Nachladen einiger Inhalte per AJAX mit berücksichtigt. Ziel war es, den Ladeprozess so nachzuvollziehen, wie er auch in den Browsern der Kunden abläuft. Diese 50 Messwerte wurden jeweils in Excel erfasst und der Mittelwert gebildet. Der Browser-Cache sowie die Caching-Mechanismen von OFBiz wurden bewusst berücksichtigt. Die Messung wurde im Firefox 8 mit dem Plugin „Firebug“ durchgeführt, da dies die Zeiten (inkl. Rendering-Zeit) gut messen kann. Die Messungen wurden im lokalen Netzwerk durchgeführt, so dass kein Routing durch das Internet lief. Ich werde später noch ausführen, welche Auswirkungen dies auf bestimmte Konfigurationen hatte. Die Requests wurden auf ein Test-System ausgeführt, dass von der Hardware-Ausstattung kleiner als das Produktivsystem dimensioniert ist.

Optimierungen und Ergebnisse

Verbesserungspotenziale bei der Peformance Optimierung von OFBiz

Umstellung auf AJP-Connector

Als erster Schritt wurde die Konfiguration des Apache-Webservers so angepasst, dass statt des HTTP-Connectors nun der AJP-Connector genutzt wird. AJP ist ein binäres Protokoll, das persistente Verbindungen nutzt, so dass sich Geschwindigkeitsvorteile ergeben. Weitere Informationen zu AJP (Apache JServ Protocol) bei Wikipedia.

  • Verbesserung um ca. 22% gegenüber aktueller Konfiguration.

Nutzung von Browser-Caching

Eine (möglichst vollständige) Darstellung der Aspekte des Browser-Caching würde den Rahmen dieses Beitrags bei weitem sprengen – aber in der Yahoo!-Developer Doku findet sich ein Einstieg in das Thema. Mit den dort genannten Stichworten kann man sich dem Thema gut nähern. Die Nutzung von Expire-Headers für statische Inhalte (Bilder, CSS, Javascript) in Verbindung mit der Umstellung auf AJP brachte in unseren Tests sehr gute Ergebnisse:

  • Verbesserung um ca. 30% gegenüber der aktuellen Konfiguration.

Nutzung von GZip

Bei der Nutzung von GZip werden die zu übermittelnden Ressourcen auf dem Server zunächst komprimiert und erst dann übertragen. So wird die zu übertragene Datenmenge minimiert, allerdings entsteht etwas CPU-Last auf dem Server (packen) und auf dem jeweiligen Client (entpacken). In unseren Tests verlangsamte sich der Seitenaufbau. Aufgrund unserer schnellen Anbindung an den Server über das lokale Netzwerk dauerte die zusätzliche Komprimierung länger, als die eingesparte Datenmenge an Übertragungszeit brauchte. Diese Messung stufen wir jedoch als nicht repräsentativ ein – die Nutzer greifen über das Internet zu und sparen so Zeit und Traffic. Tipp: es macht Sinn, sich darüber Gedanken zu machen, welche Daten man Server-seitig komprimieren lässt. Bilder wie z. B. JPEG-Dateien, sind bereits komprimiert, so dass GZip hier nur zusätzliche Last erzeugt, ohne etwas zu bewirken. Sinnvoll sind Text-basierte MimeTypes, wie z. B. HTML-, CSS- und Javascript-Dateien, da sich hier durch Komprimierung erhebliche Einsparungspotenziale ergeben.

Validierung von HTML-Code

Im Laufe der Tests stellten wir fest, dass einige (gravierende) Fehler im HTML-Markup vorhanden waren. Nachdem wir diese korrigiert hatten, stellten wir erstaunt fest, dass sich die Zeit der Darstellung (Rendering im Browser) deutlich verbesserte.

  • Verbesserung um ca. 39% gegenüber der aktuellen Konfiguration.

Zusammenfassung und Empfehlungen

Durch ein wenig durchdachte Konfiguration konnten wir die Portal-Anwendung um knapp 40% schneller bekommen, komplett ohne in das Framework selbst einzugreifen und (fast) ohne dass wir Änderungen am Frontend vorgenommen haben. Es lohnt sich also, sich für die Konfiguration etwas Zeit zu nehmen und auch die Ergebnisse sorgfältig zu überprüfen. Unsere Empfehlungen lauten:

  • Stellen Sie sicher, dass Ihr Frontend (einigermaßen) valides HTML ausliefert, da sonst der Browser Ihrer Besucher in der Darstellung Ihrer Seiten massiv ausgebremst wird.
  • Nutzen Sie AJP für die Kommunikation zwischen Webserver und Tomcat.
  • Nutzen Sie Browser-Caching und setzen Sie Expire-Headers für statische Inhalte.
  • Nutzen Sie Server-seitige Komprimierung (GZip), falls Ihre Besucher nicht (ausschließlich) aus dem lokalen Netz zugreifen.

Diese Hinweise beziehen sich in erster Linie auf OFBiz, sind aber uneingeschränkt gültig, z. B. auch für andere Java-basierte E-Commerce Systeme gültig.

Fanden Sie diesen Beitrag hilfreich? Haben Sie ähnliche oder andere Erfahrungen gemacht? Wie immer freuen wir uns über Ihren Kommentar!

Dieser Artikel gefällt Ihnen? Sagen Sie's Ihren Freunden:

Hinterlassen Sie eine Antwort





*