Bereits seit einigen Jahren gibt es Google App Engine (GAE) für Python, nun wurde die PHP Unterstützung vorgestellt. Wir haben es ausprobiert und Alltagstauglichkeit sowie Performance getestet. Als Testsysteme haben wir uns für WordPress, Shopware und OXID entschieden.
Unterschiede zur herkömmlichen Cloud
Im Gegensatz zu Amazon EC2 oder Rackspace läuft die Applikation bei Google App Engine nicht auf virtuellen Maschinen, sondern in einer Runtime Engine. Jeder Request ist quasi eine eigene Instanz. Einfach formuliert ist Google App Engine ein skalierbares Shared Hosting.
App Engine Werbeversprechen
Im Wesentlichen verspricht Google App Engine zwei Vorteile: Automatische Skalierung bei Trafficschwankungen und einfaches Deployment. Genauer gesagt, Entwickler sollen sich voll und ganz auf die Applikation konzentrieren und müssen sich keine Gedanken um das Live-Deployment machen. Beides funktioniert in der Tat wie beworben: Hat man es geschafft die lokale Entwicklungsumgebung einzurichten, ist das Live-Deployment nur noch ein Mausklick.
Einschränkungen
Wegen des Shared-Hosting-Ansatzes sind viele PHP-Funktionen aus Sicherheitsgründen gesperrt. Mailing darf nur über die Google-Mail-API erfolgen, PHP „mail()“ ist nicht erlaubt. Die wohl größte Einschränkung ist jedoch, dass Applikationen nicht ins DocRoot schreiben dürfen. Damit wird zwar einerseits das Problem verhindert, dass verschiedene Appserver unterschiedliche Files z.B. in einem tmp-Dir generieren, anderseits benötigt jede App dafür zusätzlichen Storage. Google bietet hierfür Cloud Storage an, was kein Dateisystem ist, sondern simpler Object-Storage. Für PHP steht ein Wrapper zur Verfügung, der Cloud Storage transparent in PHP einbindet z.B. fopen(„gs://bucket_name/file“). Die Unterstützung ist aber sehr rudimentär, viele Dateisystemoperationen wie z.B. Locks oder Funktionen zur Verwaltung von Verzeichnissen stehen bisher nicht zur Verfügung. Es gibt zentrale Logfiles, in denen je Request alle PHP-Fehlermeldungen übersichtlich gesammelt sind, darüber hinaus ist GAE aber eine Blackbox. Es gibt keine Möglichkeit zu Debuggen und auch keine Profilings.
OXID Test-Installation
OXID ist nicht mit GAE kompatibel, weil zu viele PHP-Funktionen gesperrt sind, die OXID im Core benötigt. Dies sind vor allem Dateisystem-Funktionen, die für das tmp-Dir und die SMARTY Template-Engine benutzt werden. An einigen Stellen werden in OXID beispielsweise per realpath() oder ähnlichen Funktionen Pfade analysiert und zusammengebaut, diese Funkionen sind teilweise damit überfordert, dass die Pfade in Cloudstorage mit „gs://“ beginnen. Nach etlichen Änderungen im Core, konnten wir die Startseite zum Laden überreden, allerdings mit inakzeptabel langen Ladezeiten. Woran das liegt, ließ sich nicht feststellen, das es bis auf Logfiles keinerlei Debugging oder Profiling Funktionalität gibt.
Shopware Test-Installation
Shopware ist ebenfalls nicht GAE kompatibel, einige der verwendeten Doctrine-Features verursachen PHP-Parse-Errors. Darüber hinaus fehlen, wie auch bei OXID, zu viele Dateisystemfunktionen, die für das aufwändige Caching benutzt werden.
WordPress
WordPress lässt sich installieren und funktioniert „out of the box“, vor allem weil WordPress während des normalen Betriebs keine Dateisystemoperationen ausführt. Um jedoch File-Uploads in WordPress zu erlauben, ist ein Plugin nötig, das Google Cloud Storage einbindet, anstatt das DocRoot zu benutzen.
Performance
Die Geschwindigkeit von einzelnen Seitenaufrufen überzeugt nicht, GAE landet auf dem letzten Platz hinter 1&1 Shared-Hosting-Paket und SysEleven Testservern.
Skalierbarkeit
Wenn es um Skalierung geht, spielt Google seine Stärke aus. Die einzelnen Seitenladezeiten sind nicht schnell, dafür steigt die Kapazität bei wachsenden Zugriffszahlen. In der folgenden Tabelle sind die im Lasttest erreichten Seitenrufe pro Sekunde bei jeweils 1, 10 und 100 gleichzeitigen Zugriffen dargestellt:
Dieser Lasttest zeigt, dass GAE bei der Erhöhung von 1 auf 10 gleichzeitige Zugriffe linear skaliert. Bei 100 gleichzeitigen Zugriffen jedoch nicht mehr, hier werden nicht zehnmal so viele Seiten ausgeliefert wie bei 10 parallelen Zugriffen, sondern nur anderthalb mal so viele. Das 1&1 Shared-Hosting-Paket konnte 100 gleichzeitigen Zugriffen nicht standhalten, hier konnten wir keine Messwerte ermitteln. Die Messwerte des SysEleven-Testservers sind deutlich höher als bei beiden anderen Anbietern, der Vergleich ist aber zugegebenermaßen unfair, da die Hardware nicht vergleichbar ist. Bei SysEleven wird keine Commodity Hardware genutzt, sondern wir setzen auf Enterprise Server, aktuell ist das die neuste Generation von HP (HP DL380 Gen8) im Vollausbau.
Fazit
Google App Engine skaliert wie versprochen automatisch. Bei mehr gleichzeitigen Zugriffen entstehen automatisch neue Instanzen und verschwinden wieder, wenn der Traffic nachlässt. Die einzelnen Seitenaufrufe sind jedoch deutlich langsamer als auf SysEleven Test-Hardware (GAE: 682ms, Sys11: 117ms). Die Applikation „bezahlt“ also Kapazität mit Latenz. Für Applikationen, die neu geschrieben werden und sich an die Spielregeln halten, ist GAE geeigent. Bereits vorhandene oder Standard-Applikationen zum Laufen zu bringen, ist sehr anstrengend, vor allem wenn die Applikation ins Dateisystem schreiben muss. Profiling und Debugging müssen in die Applikation eingebaut werden, von außen lassen sich keine Messwerte ermitteln, außer der Seitenladezeit.
