SPDY für das TYPO3 Backend: Erstes Benchmark

28.02.2017 - Erstellt von Ekkehard Gümbel

SPDY (gesprochen “Speedy”) ist ein aktueller Ansatz zur Beschleunigung des Web-Datenverkehrs durch Einfügen einer ausgefeilten Zwischenebene zu den Netzwerkprotokollen (Wikipedia für Details und Links zu den einschlägigen Seiten und Standards.)

SPDY gibt es nun seit einiger Zeit, und inzwischen wird es von diversen sehr großen Websites wie Gmail und Twitter verwendet… Aber wie ist der praktische Nutzen, sprich: Geschwindigkeitsgewinn für den “normalen” Anbieter globaler Webauftritte?

Um mich dieser Frage zu nähern, habe ich mich dazu entschieden, ein bestimmtes Szenario herauszugreifen und zu überprüfen: Und zwar die Bedienung der TYPO3 CMS Redakteursoberfläche (Backend) aus großer Entfernung – man denke an den asiatischen Kollegen, der auf dem Server in Deutschland arbeiten und z.B. Übersetzungen einpflegen soll.

Also… habe ich ein Testsystem in Singapur aufgesetzt und Messungen von hier in Deutschland aus durchgeführt, mit und ohne SPDY. Hier sind die Ergebnisse.

Mein Setup: TYPO3 mit nginx, FastCGI und SPDY

Der SPDY-Einsatz ist zwar für die Web-Anwendung transparent, aber natürlich müssen sowohl Client (Webbrowser) als auch Server (Webserver) das Protokoll unterstützen. Stand heute ist das u.a. bei Chrome und Firefox standardmäßig der Fall (Tipp: SPDY indicator in Chrome!) Die großen Server-Produkte hingegen beherrschen SPDY von Haus noch nicht. Aber…

Für Apache gibt es mod_spdy von Google
Für nginx gibt es eine SPDY Beta Implementierung

…und mehr, aber für mich waren diese zwei die Kandidaten. Was wählen? Ich entschied mich zunächst für die den meisten Leuten naheliegendere Variante mod_spdy. Welche für mich aber leider in segfault-Fehlern verendete, so dass ich dann für’s Erste ohne weitere Nachforschungen zu nginx mit SPDY wechselte. Dieses Setup hatte ich bereits verwendet, daher verlief die Einrichtung reibungslos.

Wer nginx kennt, weiß auch, dass es keinen eingebauten PHP-Support kennt, sondern solche Anfragen entweder als Reverse Proxy durchleitet (z.B. an einen Apache) oder die FastCGI-Schnittstelle verwendet. Um die Dinge simpel zu halten (und mir das Einrichten von TYPO3 mit SSL Reverse Proxy zu ersparen), wurde es FastCGI.

(An dieser Stelle sei übrigens noch erwähnt, dass SPDY die Verwendung von SSL erfordert.)

Nun ist dieser Text nicht als “Kochbuch”-Anleitung gedacht, dennoch seien hier ein paar Eckpunkte der Einrichtung festgehalten:

VERWENDETE VERSIONEN

Ubuntu 10.04
nginx 1.3.13 mit patch.spdy-65_1.3.13
spawn-fcgi v1.6.3
TYPO3 CMS 6.0.2 “Introduction Package”

WICHTIGE SCHRITTE IN DER INSTALLATION

Vorausgesetzte Software beachten (OpenSSL, PCRA, php5cgi, …)
nginx Patch und Installation – http://nginx.org/patches/spdy/README.txt
Startskript dazu: http://www.rackspace.com/knowledge_center/article/ubuntu-hardy-adding-an-nginx-init-script (PATH und DAEMON anpassen!)
spawn-fcgi installieren
und start mit
/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -f /usr/bin/php5-cgi -P /var/run/fastcgi-php.pid
oder vgl. http://blog.codefront.net/2007/06/11/nginx-php-and-a-php-fastcgi-daemon-init-script/
SSL Zertifikate-Dateien erzeugen
cgi/php.ini (e.g. in /etc/php) editieren: Kommentar entfernen vor der Zeile cgi.fix_pathinfo=1
nginx.conf (e.g. in /usr/local/nginx/conf) editieren: SSL Zertifikates-Dateien anpassen entsprechend der oben erzeugten, und SSL Server-Abschnitt aktivieren einschließlich der nachfolgenden “location”-Ausdrücke:

listen 443 ssl spdy default_server;

location / {
root /var/www;
index index.php index.htm index.html;
try_files $uri $uri/ /index.php;
}

location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/$fastcgi_script_name;
include fastcgi_params;
}

TESTVERFAHREN UND ERGEBNISSE

Nachdem nun all dies sauber funktioniert, und natürlich auch die Anwendung (hier:TYPO3 CMS), können die Tests beginnen. Wie gesagt wollte ich die Auswirkung auf die Geschwindigkeit des Redakteurs-Backeends messen, da dies ja nicht gerade leichtgewichtig ist und somit ein lohnendes Ziel darstellen könnte, und außerdem dürften größere Ladezeiten die Messung der Unterschiede vereinfachen.

Der zu testenden Arbeitsablau (genauer: vier mal zu testen, um zufällige Fehler zu reduzieren) ist dieser:

Sicherstellen, dass der Benutzer “admin” nach Login auf der “Home”-Seite des Introduction Package ist (auf welcher Inhalte liegen)
Browser-Cache löschen
Am TYPO3-Backend als admin anmelden
Inhaltselement vom Typ “Text” zum Bearbeiten öffnen, anschließend wieder schließen
Da selbe Inhaltselement erneut öffnen anschließend wieder schließen
Anderes Inhaltselement (Typ “HTML”) öffnen anschließend wieder schließen
Zur “Features”-Seite wechseln
Auch hier ein Inhaltselement vom Typ “Text” zum Bearbeiten öffnen, anschließend wieder schließen
Zur “Liste”-Ansicht wechseln
Zur “Home”-Seite wechseln
Zur “Seite”-Ansicht wechseln
Abmelden

Und hier nun also endlich die Resultate (zur Erinnerung: Zugriff vonDeutschland nach Singapur):

INTERPRETATION: AUSWIRKUNG JA, ENORME AUSWIRKUNG NEIN…

Was sagen uns diese Messwerte nun? Auf den Punkt gebracht dies:

Eine Verbesserung gegenüber einer SSL-Verbindung ohne SPDY ist eindeutig abzulesen.
Richtig signifikant ist diese Verbesserung wie zu erwarten bei “schwergewichtigen” Zugriffen ohne Browser-Cache.
Bei leichtgewichtigeren Zugriffen ist die Wirkung naturgemäß geringer, vor allem in absoluten Zahlen, aber offenbar auch prozentual.

Mit anderen Worten: Für das TYPO3-Backend, welches stark vom Browser-Caching profitiert, ist SPDY im vorliegenden Setup ein guter Bonus, aber kann auch keine Bäume ausreißen. Vor allem wenn SSL nicht ohnehin gefordert ist: Im Vergleich zur Verwendung ohne SSL ist der Geschwindigkeitsgewinn geringer, potentiell sogar ein Verlust.

Für andere, weniger caching-lastige Webanwendungen dürfte der Geschwindigkeitsvorteil allerdings signifikanter ausfallen.

Man beachte allerdings meine Einschränkung “im vorliegenden Setup” – ein wichtiges Detail! Denn nginx, wie von mir verwendet, hat seine Grenzen- beherrscht vor allem kein SPDY v3 (d.h. Server push / Server hint). Dieses könnte, gerade in Verbindung mit Applikationsunterstützung für SPDY v3, noch deutlich mehr Geschwindigkeit bringen.

Dennoch, nach Auswertung der Tests und Piloteinsätzen führen auch wir nun SPDY in Produktionsumgebungen ein, “weil wir es können” – schließlich kostet es nichts, und alle Chrome- und Firefox- (und Opera-) Benutzer profitieren automatisch davon, während sich für alle anderen gar nichts ändert. Keine Probleme bisher… klopfen wir auf Holz.

Was bleibt zu tun?

Zum einen natürlich werde ich mir mod_spdy noch einmal vornehmen, um es zum Laufen zu bringen – kann so schwer nicht sein. Dann wären erweiterte Vergleiche denkbar, etwa nginx vs. mod_spdy vs non-SSL.
Eine schwer zu testende Frage ist: Wie verhält sich das Ganze bei “wackeligeren” Verbindungen? Etwa im Mittleren Osten sind ja tendenziell hohe Paketverlustraten zu beobachten, und ich habe keine Aussage gefunden, ob SPDY unter diesen Bedingungen noch Spaß macht.
Ebenso interessant: SPDY und mobile Endgeräte? (Natürlich eher nicht für das TYPO3 Backend ;- )
Und das Thema “Anwendungsunterstützung für SPDY v3” verdient sicherlich ebenfalls nähere Beleuchtung.

Weitere Blogposts dürften also folgen. Sollte jemand Anmerkungen oder Fragen haben, oder eigene Erfahrungen, freue ich mich wie immer über Feedback!