Eigenschaften von eZ Publish

Eine Eigenschaft von eZ Publish, die für die Optimierung der Geschwindigkeit von Bedeutung ist, wird oft nur unzureichend berücksichtigt. Diese Eigenschaft ist die enorme Anzahl an Zugriffen auf das Dateisystem. Das bedeutet bei einem Seitenzugriff wird eine Vielzahl an Dateien "berührt": die PHP-Dateien, die die eigentliche Funktionalität bereitstellen; die ini Dateien, die die Einstellungen beinhalten; die vielen, unterschiedlichen Cache-Dateien; und so weiter. Dieses "berühren" ist deshalb so kostspielig, weil auf der Datei- und Betriebssystem-Ebene viele weitere Prüfungen vorgenommen werden, die auf den ersten Blick nicht ersichtlich sind. Ein vielleicht etwas überspiztes Beispiel soll dies verdeutlichen: der Zugriff auf die Datei settings/override/site.ini.append.php. Einfach wäre es, wenn geprüft werden würde, ob die Datei existiert und der Benutzer diese lesen darf, um sie anschliessend zu öffenen. Allerdings geht es in der Realität etwas weiter, denn die Prüfungen werden nicht nur für die Datei selbst, sondern für das Verzeichnis settings und das Verzeichnis override gemacht. Nun Stelle man sich vor, dass die Installation 20 Erweiterungen und 6 siteaccesses hat, dann wird diese Datei in allen Erweiterungen und in allen siteaccess gesucht, auch wenn sie dort gar nicht existiert. Dann werden bereits grob über 700 Dateisystem-Operationen (file IO) benötigt. Unter Linux kann das Programm strace dazu verwendet werden, um derartige Aufrufe zu verfolgen.

Die Hardware

Der wesentliche Bestandteil eines Webservers ist der Computer (Hardware) auf dem der Webserver ( Software ) läuft. Eine Aussage zu treffen, welche genaue Hardware (CPU, Hauptspeicher, Festplatte, Netzwerkkarte, etc.) für einen Internetauftritt verwendet werden sollte, gestaltet sich äußerst schwierig, da die Wahl stark vom Einsatzzweck der Website und der erwarteten Anzahl der Benutzer abhängt. Es gibt bereits einen Artikel , der auf diese Anforderungen eingeht. Hierbei geht es jedoch in erster Linie um die Wahl der Netzwerkkarte, der Internet-Anbindung, die CPU bzw. die Anzahl der eingesetzten Server. Prinzipiell ist ein ausreichend großer Hauptspeicher wichtig, da sich die folgenden Komponenten diesen Hauptspeicher teilen müssen: der Webserver und damit auch PHP, ein Byte-Code-Beschleuniger wie der eAccelerator sowie ggf. ein Proxy und die Datenbank (gerade die InnoDB beansprucht die Ressourcen des Computers) soweit diese auf dem gleichen Computer installiert werden sollen. In einer Cluster-Umgebung können der Proxy und die Datenbank auf separate Computer ausgelagert werden. In diesem Fall sollte die Netzwerk-Verbindung zwischen diesen Computer entsprechend gut sein. Neben dem Hauptspeicher gehört die Festplatte mit zu den wichtigsten Komponenten, aufgrund der oben genannten Eigenschaften von eZ Publish. Je schneller die Festplatte (Umdrehungen pro Minute) und je mehr Cache die Festplatte besitzt, desto besser. Der Durchsatz der Festplatte (und genauso der Netzwerkkarte) spielt erst dann eine Rolle, wenn die Anzahl der Benutzer steigt, da die verwendeten Dateien typischerweise eher klein sind.

Das Betriebssystem

Neben der Hardware spielt das Betriebssystem und innerhalb des Betriebssystems vor allem das verwendete Dateisystem eine entscheidende Rolle. Soweit Wert auf eine gute Performance gelegt wird, ist Linux als Betriebssystem die erste Wahl, da die Dateisysteme bzw. der kernel entsprechend performant sind. Bei Installationen im professionellen Umfeld ist vor allem der Hersteller-Support wichtig und aus diesem Grund werden Distributionen wie Red Hat Enterprise Linux oder SUSE Linux Enterprise Server gerne verwendet. Jedoch sind die Pakete oft nicht auf dem aktuellsten Stand und beinhalten damit nicht immer Verbesserungen die hinsichtlich der Geschwindigkeit gemacht wurden. Vielmehr bieten sie Pakete in denen Sicherheitslücken geschlossen wurden. Eine Alternative stellt die Distribution gentoo dar, die weitestgehend aktuelle Pakete beinhaltet. Allerdings wird von gentoo bisher keine Unterstützung im Enterprise Bereich angeboten, durch die Sicherheitslücken entsprechend schnell und garantiert behoben werden. Zusätzliche Unterstützungs-Dienstleistungen können für gentoo derzeit ebenfalls nicht eingekauft werden.

Das Netzwerk

Soweit es sich um eine verteilte Installation handelt (z.B. in einem Cluster Setup) gewinnt auch die Netzwerk-Infrastruktur an Bedeutung. Dabei ist weniger die Anbindung des Webservers an ein Backbone gemeint, als vielmehr die Verbindungen zwischen den einzelnen Servern, die für den Betrieb der Website notwendig sind. Prinzipiell gilt auch hier je leistungsstärker die Netzwerk-Schnittstellen, desto besser die Geschwindigkeit des gesamten Systems. Eine für fast alle beteiligten Komponenten wichtige Konfigurationsmöglichkeit, mit der die Geschwindigkeit gesteigert werden kann, ist das Eintragen der Namen von Servern in die Datei hosts (bei Linux Betriebssystemen liegt sie normalerweise im Verzeichnis /etc). Dadurch werden zusätzliche Anfragen an DNS-Server vermieden und das Netzwerk entlastet.

Das Dateisystem

Eine der wichtigsten Komponenten, wenn es um die Performance von eZ Publish geht, ist das Dateisystem . Dateisysteme unter Windows sind für eine performante eZ Publish Installation nicht zu empfehlen. Gängige Linux-Dateisysteme unterscheiden sich nur marginal und bieten prinzipiell eine gute Performance. Die einzige Ausnahme hier bilden verteilte Dateisysteme. Diese Dateisysteme sind erst dann von Bedeutung, wenn sich die Installation auf mehr als einem Computer befinden und in einem Cluster läuft (bei dem die binären Dateien und der Cache nicht in der Datenbank gespeichert werden). In diesem Fall teilen sich mehrere Computer das var/storage und das var/cache Verzeichnis und diese Verzeichnisse müssen über ein Netzwerk verteilt werden. Dabei hat sich gezeigt, dass das Network File System (NFS) eine schlechte Wahl ist, da die Dateisystem-Zugriffe relativ langsam sind (selbst wenn es hier Unterschiede in den einzelnen Versionen gibt). Eine bessere Performance bietet das Global File System (GFS), allerdings ist die aktuelle Implementierung ein wenig instabil und kann zu Problemen führen. Eine stabile und performante Lösung könnte das Oracle Cluster File System 2 sein mit dem die derzeit besten Ergebnisse erzielt werden. Allerdings kommen auch beim OCFS2 Nachteile zum Vorschein, wenn eine hohe Anzahl an gleichzeitigen Benutzern auf das System zugreift (ca. 200 Benutzer pro Sekunde), da das OCFS2 eher auf große Dateien ausgerichtet ist, die es gerade beim eZ Publish Cache nicht gibt. Eine der schlechtesten Ansätze ist, die Dateien mittels rsync o.ä. zu synchronisieren.

Um die Geschwindigkeit eines Dateisystems in etwa einschätzen zu können, habe ich einen Test entwickelt, mit dem die Geschwindigkeit gemessen werden kann. Das darin enthaltene PHP Skript liest dazu 1080 Dateien 100 mal ein und misst die dafür notwendige Zeit in Sekunden. Die Dateien stammen aus einer eZ Publish Installation und sind daher nah an der Realität. Der Test kann von der zentralen Downloadseite herunter geladen werden.

Da eine solche Messung alleine kaum eine Aussage macht, ist es wichtig Vergleichswerte zu erhalten. Einige Vergleichswerte habe ich in den folgenden Tabellen zusammen gefasst. Ich bin gerne bereit die Tabellen um zusätzliche Meßwerte zu erweitern. Falls also jemand den Test durchgeführt hat, können mir die Ergebnisse über das Kontaktformuler zugesendet werden. Um eine bessere Vergleichbarkeit zu bekommen, sollte der Test jedoch nicht durchgeführt werden, wenn die jeweiligen Systeme bereits unter Volllast stehen. Um ein besseres Ergebnis zu erhalten können auch mehrere Messungen durchgeführt und dann ein Mittelwert gebildet werden.

Dedizierte Server

Legende: AVS = Antiviren Software

(*) eZ Publish 4.0.6 und 4.1.3 sind noch nicht kompatibel zu PHP 5.3.x

Virtuelle Server

Da es bei virtuellen Servern immer einen Gast und einen Host (auf dem der Gast bzw. die virtuelle Maschine läuft) gibt, ist die folgende Tabelle in zwei Bereiche aufgeteilt. Dabei gehört die Zeile im ersten Bereich zu der Zeile mit der gleichen Nummer im zweiten Bereich. Die Daten für den Dateisystem Test liegen auf dem Gast-System und werden auch auf dem Gast-System gelesen.

Legende: HD = Festplatte; VT-x = Hardwaregestüzte Virtualisierung; AVS = Antiviren Software

(*) eZ Publish 4.0.6 und 4.1.3 sind noch nicht kompatibel zu PHP 5.3.x

Verteilte Server

Ähnlich wie bei den virtuellen Servern gibt es auch in einer Client-Server-Architektur zwei Systeme über die Informationen benötigt werden. Dabei liegen die Daten für den Dateisystem Test auf dem Server und werden vom Client gelesen. Hierbeit spielt auch die Netzwerk-Verbindung eine Rolle.

(*) eZ Publish 4.0.6 und 4.1.3 sind noch nicht kompatibel zu PHP 5.3.x

Verwendung von RAM-Disks

Der Zugriff auf den (Haupt-)Speicher ist mit am schnellsten (nur der Zugriff auf den Prozessor-Cache ist noch schneller). Daher ist die Auslagerung von Dateien in den Speicher durchaus eine Option um die Performance zu verbessern. Allerdings ist diese Option auch teuer, da der Hauptspeicher selbst relativ teuer ist und der Hauptspeicher auch von anderen Komponenten benötigt wird. Während das var/storage Verzeichnis nur selten in eine RAM-Disk ausgelagert werden kann, ist dies für das var/cache Verzeichnis und auch für das eZ Publish Verzeichnis selbst durchaus möglich. Hierdurch kann die Geschwindigkeit verbessert werden.

Verwendung virtueller Server

Virtuelle Sever sind derzeit sehr beliebt und werden gerne für Internetauftritte verwendet. Prinzipiell kann eZ Publish auf virtuellen Server performant eingesetzt werden, allerdings sollten diese virtuellen Server von Profis eingerichtet und konfiguriert werden. Typischerweise gibt es für virtuelle Server entsprechende Werkzeuge um deren leistung zu optimieren. Diese sollte auf jeden Fall zum Einsatz kommen. Ein worst case Szenario wäre der Einsatz von virtuellen Servern, deren Images auf einem NFS Laufwerk gespeichert sind und auf denen neben den Images auch noch das var/storage und das var/cache Verzeichnis von eZ Publish liegen. Dedizierte Server liefern in der Regel jedoch eine bessere Performance als virtuelle.

Verwendung eines Reverse Proxy

Proxies werden in vielen Unternehmen bereits eingesetzt, allerdings dienen sie eher der Reduzierung des Volumens von übertragenen Dateien und der Zugriffsbeschränkung. Der Einsatz eines Reverse Proxies wie z.B. Varnish kann einen enormen Einfluss auf die Auslieferung von Webpages haben. Selbst wenn die Konfiguration gerade bei stark personalisierten Websites noch etwas kompliziert ist und die Unterstützung durch eZ Publish noch verbessert werden kann, lohnt sich ein Einsatz in den meisten Fällen.

Erweiterungen für eZ Publish

Im Zeitalter von Web 2.0 und AJAX werden in den meisten Internetauftritten JavaScript-Dateien und Stylesheets verwendet. Im Hinblick auf eZ Publish, wenn viele unterschiedliche Erweiterungen verwendet werden, kann die Anzahl dieser Dateien stark ansteigen. Jede dieser Dateien erfordert einen separaten HTTP - Request und hat ein entsprechendes Volumen das übertragen werden muss. Die Erweiterung ezcore für eZ Publish versucht diese Lücke zu schließen, indem sie einerseits die JavaScript-Dateien und die Stylesheets zusammenfasst und sie ausserdem noch "komprimiert" (z.B. durch das entfernen von unnötigen Zeilenumbrüchen und Leerzeichen). Gerade bei großen Besucherzahlen kann sich eine derartige Optimierung stark auf die maximale Anzahl an gleichzeitigen Benutzer auswirken. Die Verwendung dieser Erweiterung bedingt allerdings auch, dass z.B. die in den JavaScript-Dateien verwendeten Funktionen eindeutig sind. Andernfalls kann ein Fehlverhalten der Anwendung die Folge sein.

Einstellungen

Um eine möglichst gute Geschwindigkeit bei der Auslieferung von Seiten zu erhalten, können einige Einstellungen von eZ Publish angepasst werden. Wie die Einstellungen von eZ Publish konfiguriert werden, hängt jedoch auch von der Installation selber ab. Von daher sollten alle Einstellungen zunächst in einem Test-System überprüft werden. Die folgenden Einstellungen können einen Einfluss auf die Geschwindigkeit haben.

Grafiken in Cascading Stylesheets

Eine Optimierung, die in erster Linie für Entwickler in Frage kommt, betrifft die Verwendung von Grafiken in Stylesheets. Gerade bei der Entwicklung von Design-Erweiterungen für eZ Publish werden normalerweise Grafiken verwendet, um z.B. Knöpfe oder Listen mit kleinen Icons zu versehen. In der Regel wird hierfür pro Icon eine Grafik(-Datei) erstellt, die dann in einem Stylesheet referenziert wird. Dies bedeutet für jede Grafik einen zusätzlichen HTTP-Request (soweit der Client diese Grafik noch nicht heruntergeladen hat). Auch eine Zusammenfassung der Stylesheets (wie oben beschrieben) hat hierauf keinen positiven Einfluss. Um diese zusätzlichen Requests zu verhindern, können die einzelnen Grafiken in vielen Fällen zu einer einzigen zusammengefasst werden. Dieses Vogehen ist im Artikel CSS Sprites: Image Slicing’s Kiss of Death genauer beschrieben.

Zeichensätze

Der von eZ Publish intern verwendete Zeichensatz ist UTF-8, das bedeutet die texttuellen Inhalte werden mit dem UTF-8 Zeichensatz in der Datenbank gespeichert. Um Konvertierungen zwischen Zeichensätzen zu vermeiden, sollten alle beteiligten Systeme (Datenbank-Server und Client, Betriebssystem, Webserver) standardmäßig den gleichen Zeichensatz verwenden. Im Hinblick auf das Betriebssystem hängt die Konfiguration des Standard-Zeichensatzes stark vom Anbieter / Distributor ab. Unter Linux wird der Zeichensatz üblicherweise über Umgebungsvariablen konfiguriert. Welche Zeichensätze zur Verfügung stehen kann mit dem folgenden Befehl in Erfahrung gebracht werden.

Alle dort aufgeführten Zeichensätze können entweder global oder auch benutzerabhängig verwendet werden, indem die Umgebunsvariablen LC_ALL und LANG entsprechend gesetzt werden. Um beispielsweise UTF-8 in deutscher Sprache zu konfigurieren, können folgende Befehle in der Kommandozeile eingegeben werden.

Um diese Einstellungen dauerhaft für einen Benutzer zu übernehmen, können diese Befehle beispielsweise in die Datei .profile oder in die Datei .bashrc (falls bash die Shell des Benutzers ist) eingetragen werden. Diese Dateien sind im Verzeichnis des Benutzers vorhanden oder können dort angelegt werden.

Die Webserver Konfiguration

Bei der Konfiguration des Webservers gibt es mehrere Aspekte, die hinsichtlich der Geschwindigkeit zu beachten sind. Zunächst einmal sollten die Vorgaben des Herstellers berücksichtigt werden (wie z.B. Apache Performance Tuning ). Neben dieser eher trivialen Optimierungs-Möglichkeit gibt es eine weitere, die erst dann verständlich wird, wenn das Verhalten von eZ Publish hinsichtlich des Expires Header berücksichtigt wird, denn im Normalfall wird dieser Header immer auf ein Datum in der Vergangenheit gesetzt. Das bedeutet, der lokale Client (also z.B. der Webbrowser) oder der Proxy werden bei jeder Anfrage alle Elemente einer Seite immer neu Anfragen. Während das bei den Inhalten durchaus Sinn macht, ist diese Sinnhaftigkeit bei Hintergundgrafiken, Icons, o.ä. nicht gegeben. Dieses Verhalten kann durch eine entsprechende Konfiguration des Webservers abgefangen werden. Ein beispielhafter Regelsatz für eZ Publish ist weiter unten dargestellt. Eine weitere Möglichkeit der Optimierung hängt stark von den Internetseiten ab, die ausgeliefert werden sollen. Sie bezieht sich auf die Komprimierung der übermittelten Informationen. Ein Webserver bietet für gewöhnlich die Möglichkeit Inhalte vor der Übertragung zu komprimieren, soweit der Client dies unterstützt. Ein solches Vorgehen macht allerdings nur dann Sinn, wenn

• der Webserver über eine entsprechende Rechenleistung verfügt (abhängig von der erwarteten Anzahl an Besuchern)
• die Inhalte gut (d.h. mit einem hohen Grad) komprimiert werden können (das gilt z.B. nicht für PDF oder bzip2 Dateien)
• die Anzahl der gleichzeitig anfragenden Benutzer hoch oder die Netzwerkbandbreit gering ist

Diese Möglichkeit der Optimierung muss also gut abgewägt werden.

Die Datenbank Konfiguration

Die Konfiguration der Datebank, die für eine eZ Publish Installation verwendet wird, sollte auf jeden Fall auch untersucht und entsprechend optimiert werden. Da MySQL die für eZ Publish bevorzugte Datenbank ist, wird sie für die folgenden Beispiele als Referenz verwendet. Ähnliche Konfigurationen können auch an anderen Datenbanken vorgenommen werden. Letztendlich hängt die Konfiguration jedoch auch stark von der Ausrichtung der eZ Publish Installation ab (Intranet mit 200 bekannten Benutzern versus Online-Zeitschrift mit Millionen anonymer Benutzer). Die Konfiguration von MySQL erfolgt in der Regel in der Datei my.cnf die sich im /etc Verzeichnis einer Linux-Installation befindet - eine Beispiel-Konfiguration ist weiter unten beschrieben.

Die Vergabe von Benutzerrechten in MySQL kann sich ebenfalls auf die Geschwindigkeit auswirken. Falls der Datenbank-Zugriff für einen Benutzer auf bestimmte Hosts eingeschränkt werden soll, sollte auch hier kein voll qualifizierte Domain-Name sondern eine IP Adresse verwendet werden. Also zum Beispiel

Hierdurch wird dem Benutzer 'ezpublish' der Zugriff auf die Datenbank 'ezpublish_db' auf dem Server mit der IP Adresse 192.168.0.1 gewährt. Dabei ist ebenfalls wichtig, etwaige zusätzliche Einschränkungen, entsprechend dem geplanten Verwendungszweck von eZ Publish, korrekt zu konfigurieren. Die folgenden Anweisungen können mit der WITH-Klausel an die o.g. Befehlszeile angehängt werden und können je Installation konfiguriert werden.

Weiterführende Literatur

Neben den genannten Informationen gibt es noch weitere Dokumente, die für eine performante eZ Publish Installation wichtig sind. Dazu zählt die Optimierung der Datenbank MySQL und auch des Webservers . Außerdem gibt es mehrere Artikel zur Optimierung von eZ Publish:

• eZ Publish Performance Optimization Part 1
• eZ Publish Performance Optimization Part 2
• eZ Publish Performance Optimization Part 3
• eZ Publish Performance Best Practices