Apache

TYPO3 mit Komprimierung auf Plesk-Host mit Reverse Proxy nginx

caticonslite_bm_alt

Wird in TYPO3 die Frontend-Komprimierung mit „$GLOBALS[‚TYPO3_CONF_VARS‘][‚FE‘][‚compressionLevel‚] = 9″ und in den TypoScript-Setup-Einstellungen „config.compressJs“ bzw. „config.compressCss“ aktiviert, werden statische „pre-rendered“ JavaScript- und CSS-Dateien im gzip-Format im Ordner „typo3temp/compressor“ abgelegt. Für die korrekte Auslieferung ist für Apache (z.B. in der Datei .htaccess) die folgende Konfiguration erforderlich:

<FilesMatch "\.js\.gzip$">
	AddType "text/javascript" .gzip
</FilesMatch>
<FilesMatch "\.css\.gzip$">
	AddType "text/css" .gzip
</FilesMatch>
AddEncoding gzip .gzip

Seit Plesk 12 wird nginx als Reverse Proxy eingesetzt und statische Dateien werden nicht mehr von Apache, sondern direkt von nginx ausgeliefert. Das führt dazu, dass nginx die Dateien zwar mit dem korrekten „Content-Type“, aber ohne erforderliches „Content-Encoding: gzip“ im HTTP-Header ausliefert und infolgedessen die Dateien vom Browser falsch (so als wären sie nicht komprimiert) interpretiert werden. Analog zur o.g. Konfiguration für Apache ist auch eine Konfiguration für nginx erforderlich: In Plesk kann unter „Einstellungen für Apache & nginx“ der Domain entweder die Option „Intelligente Bearbeitung statischer Dateien“ deaktiviert werden (nicht empfohlen), oder folgende Konfiguration unter „Zusätzliche nginx-Anweisungen“ hinterlegt werden:

location ~ "\.js\.gzip$" {
	add_header Content-Encoding gzip;
	gzip off;
	types { text/javascript gzip; }
}
location ~ "\.css\.gzip$" {
	add_header Content-Encoding gzip;
	gzip off;
	types { text/css gzip; }
}

Diese Konfiguration bringt nginx dazu die komprimierten JS- und CSS-Dateien analog zu Apache zu behandeln und das erforderliche „Content-Encoding: gzip“ im HTTP-Header zu setzen.

Verwendung des ApplicationContext in TYPO3

caticonslite_bm_alt

TYPO3 bietet die Möglichkeit die Applikation in unterschiedlichen Kontexten (z.B. Development, Staging und Production) laufen zu lassen. Hierfür wird mittels Webserver-Konfiguration die Environment-Variable „TYPO3_CONTEXT“ gesetzt. Ein mögliche Variante zum Setzen des Kontexts befindet sich in der .htaccess-Beispieldatei aus dem typo3_src-Ordner, in angepasster und optimierter Form sieht dies wie folgt aus:

RewriteRule .? - [E=TYPO3_CONTEXT:Production]
RewriteCond %{HTTP_HOST} =staging.webentwickler.at
RewriteRule .? - [E=TYPO3_CONTEXT:Production/Staging]
RewriteCond %{HTTP_HOST} =dev.webentwickler.at
RewriteRule .? - [E=TYPO3_CONTEXT:Development]

Im o.g. Beispiel wird standardmäßig der TYPO3_CONTEXT bzw. in weiterer Folge der ApplicationContext auf „Production“ gesetzt. Für den Hostnamen „staging.webentwickler.at“ wird der Kontext „Production/Staging“ und für „dev.webentwickler.at“ der Kontext „Development“ gesetzt.

Der somit gesetzt Kontext kann nun in TypoScript bzw. direkt im Programmcode verwendet werden. Grundsätzlich wäre es  möglich den Kontext via Environment-Variable abzufragen, darauf sollte aber verzichtet werden und stattdessen die vom TYPO3-Core bereitgestellten Wrapper-Methoden verwendet werden, da es z.B. bei der Verwendung von php_fpm zu veränderten Environment-Variablen (REDIRECT_-Präfix, z.B.: REDIRECT_TYPO3_CONTEXT) kommen kann. In TypoScript verwendet man:

[applicationContext = Development]
	plugin.tx_webentwickler.settings.email = [email protected].webentwickler.at
[global]

Im PHP-Code (hier: „AdditionalConfiguration.php“):

if (\TYPO3\CMS\Core\Utility\GeneralUtility::getApplicationContext() == 'Development') {
	$GLOBALS['TYPO3_CONF_VARS']['SYS']['displayErrors'] = 1;
}

In einer sauber programmierten Anwendung sollte es grundsätzlich so sein, dass sämtliche Konfigurationen in TypoScript vorgenommen werden und somit die Verwendung der Methode getApplicationContext() im Programmcode nicht erforderlich sein, sondern ausschließlich auf die Konfigurationsdatei beschränken sollte.

Weitere Informationen zur Verwendung findet man in der TypoScript Reference unter Condition reference/applicationContext.

Piwik-Problem „Please check your server configuration. You may want to whitelist „*.html“ files from the „plugins“ directory.“ beheben

Nach der Aktualisierung von Piwik von 2.2.x auf 2.3.0 erhält man für das Plugin „ZenMode“ den Fehler „Please check your server configuration. You may want to whitelist „*.html“ files from the „plugins“ directory.“. Das Problem ist, dass sämtliche Ordner des Plugins für den Webserver nicht lesbar sind und somit ein „Access denied“ die Folge davon ist. Eine Anpassung der Ordner-Rechte schafft Abhilfe – am einfachsten erledigt man dies via SSH ausgehend vom Root-Ordner von Piwik:

find plugins/ZenMode/ -type d -exec chmod 0755 {} \;

Alternativ ist natürlich auch eine Anpassung mittels FTP-Programm möglich, in diesem Fall muss man u.u. die Ordner-Struktur des Plugins händisch durchgehen.

AllowOverride MultiViews

caticonslite_bm_alt

Apache stellt mit dem Modul „mod_negotiation“ und der Option „MultiViews“ eine automatische Fehlerbehandlung zur Verfügung. Sollte der angeforderte URL nicht existieren, so wird nach Dateien mit dem selben Wortstamm gesucht. Das kann sich bei der Verwendung von „mod_rewrite“ negativ auswirken und zu einer falschen Auflösung von URLs führen. Um Probleme bei der Auflösung von URLs zu verhindern setzen CMS wie Drupal 7 oder TYPO3 NEOS die Option „Options -MultiViews“ in der .htaccess-Datei.

Ist „AllowOverride“ nicht korrekt gesetzt und erlaubt das Überschreiben der Option nicht, so resultiert dies in einem „Internal Server Error“ im Browser bzw. einem „[…]/.htaccess: Option MultiViews not allowed here“ in den Apache-Logs. In den seltensten Fällen möchte man das Überschreiben aller Optionen mit „AllowOverride All“ erlauben, sondern nur gezielt Freigaben hierfür erteilen. Dies kann man beispielsweise mit „AllowOverride AuthConfig FileInfo Indexes Limit Options=All,MultiViews“ erreichen.

PHP-Serverkonfigurationen im Performancetest

caticonslite_bm_alt

Ziel dieses Vergleichs war es, die performantesten PHP-Konfigurationen für Drupal, TYPO3 und WordPress festzustellen und daraus auf die im Allgemeineinsatz performanteste Konfiguration zu schließen. Getestet wurden die Standardinstallationspakete Drupal 7.16TYPO3 4.7 Government Package und WordPress 3.4.2 mit Apache Bench für einen Zeitraum von je 30 Sekunden (z.B. „ab -kc 250 -t 30 http://127.0.0.1/drupal/“). Um möglichst faire Bedingungen zu schaffen wurden die involvierten Software-Komponenten vor jedem Test neu gestartet (z.B. „/etc/init.d/nginx restart && /etc/init.d/php5-fpm restart“). Der Testinstanz waren vier Kerne eines E5649-Xeon-Prozessors, 16 GB RAM und zwei SATA-Festplatten im Hardware-RAID 1-Verbund exklusiv zugewiesen. Als Software wurden die Komponenten in ihrer Standardkonfiguration aus dem Debian Wheezy-Repository eingesetzt.

Folgende Konfigurationen wurden getestet:

  • apache2-mpm-prefork + libapache2-mod-fcgid
  • apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  • apache2-mpm-prefork + libapache2-mod-php5
  • apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  • apache2-mpm-prefork + libapache2-mod-suphp
  • apache2-mpm-prefork + libapache2-mod-suphp + php-apc
  • apache2-mpm-worker + libapache2-mod-fcgid
  • apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  • apache2-mpm-worker + libapache2-mod-suphp
  • apache2-mpm-worker + libapache2-mod-suphp + php-apc
  • nginx + php5-fpm
  • nginx + php5-fpm + php-apc

Die performantesten Konfigurationen für Drupal:

  1. 152,94 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  2. 147,12 Requests/s, 250 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  3. 146,68 Requests/s, 100 Concurrency: nginx + php5-fpm + php-apc
  4. 145,83 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  5. 132,43 Requests/s, 50 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  6. 130,92 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  7. 128,88 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc

Die performantesten Konfigurationen für TYPO3:

  1. 180,32 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  2. 179,99 Requests/s, 250 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  3. 173,87 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  4. 166,69 Requests/s, 50 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  5. 166,03 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  6. 163,55 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  7. 111,03 Requests/s, 100 Concurrency: nginx + php5-fpm + php-apc

Die performantesten Konfigurationen für WordPress:

  1. 57,75 Requests/s, 100 Concurrency: nginx + php5-fpm + php-apc
  2. 55,97 Requests/s, 250 Concurrency:  apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  3. 52,21 Requests/s, 50 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  4. 49,93 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-fcgid + php-apc
  5. 48,99 Requests/s, 250 Concurrency: apache2-mpm-worker + libapache2-mod-fcgid + php-apc
  6. 48,09 Requests/s, 50 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc
  7. 46,7 Requests/s, 250 Concurrency: apache2-mpm-prefork + libapache2-mod-php5 + php-apc

Download aller Apache Bench-Ergebnisse und der Excel-Auswertung

Fazit:

Dass libapache2-mod-suphp im Vergleich zu den anderen Testkandidaten nicht gut abschneiden und APC die Performance enorm steigern wird, war bereits vor dem Test klar. Enttäuschend war in jedem Fall die Leistung von WordPress, welche auf fehlende Cachingmechanismen im Core zurückzuführen ist. Im allgemeinen Vergleich zeigte besonders libapache2-mod-fcgid bei hohen (250 Concurrency) und moderaten (50 Concurrency) Zugriffszahlen eine gute Performance. Als reiner Webserver mag nginx zwar schneller als Apache sein, im Zusammenspiel mit PHP konnte sich nginx gegen Apache aber nicht durchsetzen.

Mein (klarer) Favorit ist apache2-mpm-worker + libapache2-mod-fcgid + php-apc, wer einfachere Konfigurationen bevorzugt und bei dem Benutzerrechte keine Rolle spielen ist auch mit apache2-mpm-prefork + libapache2-mod-php5 + php-apc gut bedient.

 nach oben