Beruflich / eZ Systems / eZ Publish Performance

Sie benutzen einen Browser der von diesen Internetseiten nicht unterstützt wird. Daher kann es sein, dass nicht alles so funktioniert und aussieht wie es sollte.

eZ Publish Performance-Optimierungen

Für fast jeden Internetauftritt ist eine schnelle Auslieferung der Seiten wichtig. Das gilt ebenso für Internetseiten, die durch das Enterprise Content Management System eZ Publish verwaltet werden. Für einen professionellen Internetauftritt muss eine Standard-Installation in den meisten Fällen angepasst werden und das gilt insbesondere im Hinblick auf die Geschwindigkeit mit der Seiten ausgeliefert werden. Es gibt bereits viele Artikel die von eZ Systems selbst, von Partnern oder von der Community veröffentlicht wurden. In vielen Fällen sind diese in Englischer Sprache verfasst und beschränken sich auf spezielle Bereiche. Da es schwierig ist eine Aussage über die Hardware und das Betriebssystem zu machen, werden diese Aspekte in vielen Artikeln vernachlässigt. Dieser Artikel versucht die Lücken zu schließen und ist ausgerichtet auf eZ Publish 4.1.0 .

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 überspitztes 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 anschließend 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
Prozessor Festplatte Typ Festplatte Geschwindigkeit Betriebssystem Dateisystem Hauptspeicher AVS PHP Version Dauer
AMD Athlon(tm) 64 X2 Dual Core 5000+ SATA II 7.200 U/Min Gentoo Linux 64 Bit 2008.0 2.6.29-r1 Reiser FS 2GB nein 5.2.9 9,5s
AMD Athlon(tm) 64 X2 Dual Core 5000+ SATA II 7.200 U/Min Gentoo Linux 64 Bit 2008.0 2.6.30-r3 Reiser FS 2GB nein 5.3.0 (*) 7s
AMD Athlon(tm) 64 X2 Dual Core 5000+ SATA II 7.200 U/Min Windows Vista 32 Bit Service Pack 2 NTFS 2GB ja 5.2.9-2 136s
AMD Athlon(tm) 64 X2 Dual Core 5000+ SATA II 7.200 U/Min Windows Vista 32 Bit Service Pack 2 NTFS 2GB nein 5.2.9-2 133s
AMD Athlon(tm) 64 X2 Dual Core 5000+ SATA II 7.200 U/Min Windows Vista 32 Bit Service Pack 2 NTFS 2GB ja 5.3.0 (*) 73s
AMD Athlon(tm) 64 X2 Dual Core 5000+ SATA II 7.200 U/Min Windows Vista 32 Bit Service Pack 2 NTFS 2GB nein 5.3.0 (*) 71s
Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (2 x quad core) MegaRaid 10.000 U/Min Gentoo Linux 64 Bit 2007.0 2.6.23-r3 Extended 3 8GB nein 5.2.5 8,5s
Intel(R) Pentium(R) 4 CPU 2.40GHz (dual core) Ultra ATA/133 (ATA-7) 7.200 U/Min Gentoo Linux 32 Bit 2008.0 2.6.28-r4 Extended 3 512MB nein 5.2.8 13,5s
Intel(R) Pentium(R) 4 CPU 2.40GHz (dual core) Ultra ATA/133 (ATA-7) 7.200 U/Min Gentoo Linux 32 Bit 2008.0 2.6.32-r7 Extended 3 512MB nein 5.3.1 8,5s
Intel(R) Pentium(R) 4 CPU 2.40GHz (dual core) Ultra ATA/133 (ATA-7) 7.200 U/Min Gentoo Linux 32 Bit 2008.0 2.6.32-r7 XFS 512MB nein 5.3.1 8,5s

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.

Host
Nr Prozessor HD Gesch. HD Typ Betriebssystem Dateisystem Hauptspeicher PHP Version Virtuelle Maschine
1 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ 7.200 U/Min SATA II Gentoo Linux 64 Bit 2008.0 2.6.29-r1 Reiser FS 2 GB - VirtualBox 2.2
2 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ 7.200 U/Min SATA II Gentoo Linux 64 Bit 2008.0 2.6.30-r3 Reiser FS 2 GB - VirtualBox 3.0.2
Gast
Nr Prozessor Werkzeuge VT-x AVS HD Typ Betriebssystem Dateisystem Hauptspeicher PHP Version Dauer
1 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (1 CPU verfügbar) installiert Nein Ja PCI-Bus-Master IDE Windows XP 32 Bit Service Pack 3 NTFS 512MB 5.2.9-2 288,5s
2 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (1 CPU verfügbar) installiert Ja Nein PCI-Bus-Master IDE Windows XP 32 Bit Service Pack 3 NTFS 512MB 5.2.8 121s
2 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (1 CPU verfügbar) installiert Ja Ja PCI-Bus-Master IDE Windows XP 32 Bit Service Pack 3 NTFS 512MB 5.2.8 160s
2 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (1 CPU verfügbar) installiert Ja Nein PCI-Bus-Master IDE Windows XP 32 Bit Service Pack 3 NTFS 512MB 5.3.0 (*) 38,5s
2 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (1 CPU verfügbar) installiert Ja Ja PCI-Bus-Master IDE Windows XP 32 Bit Service Pack 3 NTFS 512MB 5.3.0 (*) 104,5s

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. Hierbei spielt auch die Netzwerk-Verbindung eine Rolle.

Server
Nr CPU Festplatte Typ Festplatte Geschwindigkeit Betriebssystem Dateisystem Hauptspeicher PHP Version Netzwerk
1 AMD Athlon(tm) 64 Processor 3200+ SATA II 7.200 U/Min Gentoo Linux 64 Bit 2008.0 2.6.28-r4 Reiser FS 1 GB - 100 MBit Switched
Client
Nr CPU Festplatte Typ Festplatte Geschwindigkeit Betriebssystem Dateisystem Hauptspeicher PHP Version Dauer
1 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ SATA II 7.200 U/Min Gentoo Linux 64 Bit 2008.0 2.6.29-r1 NFS 3 2 GB 5.2.9 76s
1 AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ SATA II 7.200 U/Min Gentoo Linux 64 Bit 2008.0 2.6.29-r1 NFS 3 2 GB 5.3.0 (*) 76s

(*) 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 außerdem 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.

[DebugSettings] DebugOutput=disabled # keine Debug-Ausgaben DebugByIP=disabled # Keine Prüfung der IP DebugByUser=disabled # Keine Prüfung des Benutzers DebugLogOnly=enabled # Debug nur in Dateien, aber AlwaysLog[] # Nur Fehler und Warnungen in Dateien schreiben AlwaysLog[]=error AlwaysLog[]=warning [TemplateSettings] TemplateCompile=enabled # Templates sollen kompiliert und als PHP Dateien abgespeichert werden TemplateCache=enabled # cache-block Anweisungen in Template sollen interpretiert werden TemplateCompression=disabled # Keine CPU-Zeit für Kompression verwenden TemplateOptimization=disabled # Keine CPU-Zeit für Optimierungen verwenden Debug=disabled # Keine Debug-Ausgaben (verursacht im IE ggf. fehlerhafte Darstellung) DevelopmentMode=disabled # Keine zusätzlichen Prüfungen [ContentSettings] ViewCaching=enabled # Cache-Mechanismus von /content/view verwenden [OverrideSettings] Cache=enabled # Auswertung wann welches Template verwendet werden soll speichern [HTTPHeaderSettings] CustomHeader=enabled # HTTP-Header anpassen (Seiten sind 10 Minuten lang "gültig") HeaderList[] HeaderList[]=Cache-Control HeaderList[]=Pragma HeaderList[]=Expires Cache-Control[] Cache-Control[/]=public, max-age=600, s-maxage=600, no-cache=Last-Modified;15;0 Cache-Control[/rss]=public, must-revalidate, max-age=600, no-cache=Last-Modified;15;0 Pragma[] Pragma[/]=;15;10 Expires[] Expires[/]=+600;15;0 [DatabaseSettings] SQLOutput=disabled # Keine Debug-Ausgaben für Datenbank-Zugriffe [RegionalSettings] TranslationCheckMTime=disabled # Zeitstempel von Übersetzungs-Dateien nicht prüfen TranslationCache=enabled # Übersetzungen zwischenspeichern DevelopmentMode=disabled # Keine zusätzlichen Prüfungen [RoleSettings] EnableCaching=true # Rollen zwischenspeichern UserPolicyCache=enabled # Richtlinien zwischenspeichern

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.

locale -a

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.

export LC_ALL="de_DE.utf8" export LANG="de_DE.utf8"

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.

# Apache Konfiguration als Beispiel um den Expires Header zu verändern <IfModule mod_expires.c> ExpiresActive On # JavaScript, Flash und Stylesheets verändern sich normalerweise eher selten: ExpiresByType application/x-javascript "access plus 1 year" ExpiresByType application/javascript "access plus 1 year" ExpiresByType application/x-shockwave-flash "access plus 1 hour" ExpiresByType application/shockwave-flash "access plus 1 hour" ExpiresByType text/css "access plus 1 year" # Gleiches gilt für Bilder, Pakete und Icons: <LocationMatch /design/[^/]+/images> ExpiresDefault "access plus 1 year" </LocationMatch> <LocationMatch /extension/[^/]+/design/[^/]+/images> ExpiresDefault "access plus 1 year" </LocationMatch> <LocationMatch /var/storage/packages/[^/]+/[^/]+> ExpiresDefault "access plus 1 year" </LocationMatch> <LocationMatch /var/[^/]+/storage/packages/[^/]+/[^/]+> ExpiresDefault "access plus 1 year" </LocationMatch> <LocationMatch /var/storage/images> ExpiresDefault "access plus 1 week" </LocationMatch> <LocationMatch /var/[^/]+/storage/images> ExpiresDefault "access plus 1 week" </LocationMatch> <Location /share/icons> ExpiresDefault "access plus 1 week" </Location> </IfModule>
# Apache Konfiguration als Beispiel um Inhalte zu komprimieren: <IfModule mod_deflate.c> DeflateFilterNote deflate_ratio LogFormat "%v %h %l %u %t \"%r\" %>s %b mod_deflate: %{deflate_ratio}n pct." vhost_with_deflate_info CustomLog ${LOGSDIR}/deflate_access_log vhost_with_deflate_info # Stylesheets und JavaScript Dateien in den cache Verzeichnissen können komprimiert werden: <LocationMatch /var/cache> AddOutputFilterByType DEFLATE text/css application/x-javascript application/javascript BrowserMatch ^Mozilla/4 no-gzip BrowserMatch \bMSI !no-gzip #Header append Vary User-Agent env=!dont-vary </LocationMatch> <LocationMatch /var/[^/]+/cache> AddOutputFilterByType DEFLATE text/css application/x-javascript application/javascript BrowserMatch ^Mozilla/4 no-gzip BrowserMatch \bMSI !no-gzip #Header append Vary User-Agent env=!dont-vary </LocationMatch> # Stylesheets und HTML Dateien können komprimiert werden: <Location /> AddOutputFilterByType DEFLATE text/css text/html BrowserMatch ^Mozilla/4 no-gzip BrowserMatch \bMSI !no-gzip !gzip-only-text/html #Header append Vary User-Agent env=!dont-vary SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary Header append Vary User-Agent env=!dont-vary </Location> </IfModule>
# Weitere Apache-Anweisungen, die sich auf die Geschwindigkeit auswirken AddDefaultCharset utf-8 # Zeichensatz-Konvertierung vermeiden HostnameLookups off # Namensauflösung per DNS vermeiden AllowOverride None # Nicht nach .htaccess Dateien suchen EnableMMAP on # Operationen im Speicher durchführen EnableSendfile on # Dateien direkt ausliefern ExtendedStatus off # Keine Zusatzinformationen generieren KeepAlive off # Keine Verbindungen offen halten MaxClients = 100 # ( "Verfügbarer RAM" - "RAM von anderen Prozessen" ) / ( "RAM von Apache verwendet" ) MaxSpareServers = 20 # abhängig von den Rahmenbedingungen StartServers = 10 # abhängig von den Rahmenbedingungen Options -FollowSymLinks -SymLinksIfOwnerMatch # Berechtigungen von symbolischen Verknüpfungen nicht prüfen Timeout = 10 # Langsame Verbindungen vermeiden MaxRequestsPerChild = 5000 # bei Speicherlöchern reduzieren RewriteLog = /dev/null # Keine Protokollierung von Rewrite Regeln RewriteLogLevel = 0 # Ausgaben bei der Protokollierung von Rewrite Regel ausschalten

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

GRANT ALL ON 'ezpublish_db'.* TO 'ezpublish'@'192.168.0.1' IDENTIFIED BY 'passwort';

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.

Einschränkung Wert
MAX_QUERIES_PER_HOUR 500000
MAX_UPDATES_PER_HOUR 20000
MAX_CONNECTIONS_PER_HOUR 5000
MAX_USER_CONNECTIONS 100
[mysqld] key_buffer = 500M # Zur Laufzeit abfragen mit SHOW VARIABLES LIKE '%key_read%' table_cache = 4000 # max_connections * 10 max_connection = 100 # Analog zu MaxClients in der Apache Konfiguration (s.o.) sort_buffer_size = 3M # Verbrauchter Speicher berechnet sich durch sort_buffer_size * max_connections query_cache_type = 1 # Abfragen können gecacht werden query_cache_limit = 1M # Abfragen mit mehr als 1M Speicherbedarf nicht cachen query_cache_size = 100M # Zur Laufzeit abfragen mit SHOW STATUS LIKE '%qcache%' character-set-server = utf8 # UTF-8 als Zeichensatz für den Server (intern) default-character-set = utf8 # UTF-8 als Standard-Zeichensatz (Server) innodb_flush_log_at_trx_commit = 0 # Transaktionen nach commit nicht zwingend abschliessen innodb_buffer_pool_size = 700M # Verfügbarer Speicher für Tabellen und Indizes (70% des Hauptspeichers) innodb_additional_mem_pool_size = 50M # Speicher für interne Datenstrukturen innodb_log_file_size = 256 # Größe der log-Dateien innodb_log_buffer_size = 4M # Puffer-Speicher für log-Dateien innodb_thread_concurrency = 8 # Verwendete Threads innodb_file_per_table = On # Jede Tabelle in einer eigenen Datei verwalten transaction_isolation = READ-COMMITTED # Konsistentes nicht-blockierendes lesen [mysql] default-character-set = utf8 # UTF-8 als Standard-Zeichensatz (Client)

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:

  • Derzeit 0 von 5 Sternen.
  • 1
  • 2
  • 3
  • 4
  • 5
Bewertung: 0/5 (Abgegebene Stimmen: 0)

Vielen Dank für die Bewertung!

Sie haben diesen Inhalt bereits bewertet. Sie können jeden Inhalt nur einmal bewerten!

Ihre Bewertung wurde geändert, vielen Dank für die Bewertung!

Ähnliche Inhalte