Foaa

Wie jeder Shared-Hoster wurden wir auch mit folgender Frage konfrontiert: Wie lösen wir das PHP Problem ?

Was dieses Problem ist und warum man es nicht mit mod_php lösen kann wird schon genügend im Netz beschrieben .

Ich habe mich damals ziemlich schnell mit der mod_fastcgi + php-cgi angefreundet und es ist nun seit nunmehr 5 Monaten auch produktiv im Einsatz .. Aber mit der Zeit hat sich leider ein großes Manko heraus kristallisiert: Der Ressourcenverbrauch der FastCGI Lösung ist einfach enorm!

Um unseren Kunden möglichst einfach und sicher von einander abzugrenzen, gleichzeitig aber noch beweglich zu bleiben haben wir jedem Virtual Host einen eigenen Unix Benutzer zugewiesen unter dessen Rechten dann die  FastCGI Server laufen (sofern PHP eingesetzt wird). Wir teilen also noch nicht einmal PHP Prozesse zwischen zwei Virtual Hosts die dem gleichen Kunden gehörten.
Der Größte VHost rennt momentan mit über 20 gleichzeitigen Servern, wird aber in absehbarer Zeit verdoppelt, denn er nutzt alle verfügbaren voll und ganz aus. Das Problem beginnt nun mit den kleinen.. die ganz kleinen, die mit einem einzelnen Prozess idle im RAM hocken und – garnichts machen. Und das sind fast alle, bis auf eine handvoll wirklich besuchter Seiten.

Die avisierte Lösung muss also drei Ziele erfüllen:

1. Es muss Sicherheit in einer Shared-Hosting Umgebung gewährleisten (mind. getrennte Userprozesse) die mod_php nicht erreicht
2. Gute und vor allem nach oben skalierbare Performance für große Internetauftritte
3. Öknomischer Umgang mit Ressourcen für kleine und hauptsächliche idle Websites

Glücklicherweise brauchen wir aber keine one-fits-all-Lösung, sondern können einfach zwei verschiedene Techniken einsetzen. Für große und stark frequentierte Seiten setzen wir also weiterhin mod_fastcgi ein. Der “ständige” RAM Vebrauch der persistenten Prozesse ist hier nicht der Flaschenhals. Für kleine, kaum besuchte Seiten hingegen benutzen wir nun suPHP. Wieder einmal klappt das aber nicht alles so, wie es soll. Die suPHP Debian Pakete unterstützen ein (IMO wichtigstes) Feature nicht: “suPHP_UserGroup <user> <group>” um Benutzer und Gruppe für ein Virtual Host zu definieren. Daher hab ich sie selber gebaut:

• libapache2-mod-suphp_0.6.2-2+fortrabbit0_amd64.deb
• libapache-mod-suphp_0.6.2-2+fortrabbit0_amd64.deb
• suphp-common_0.6.2-2+fortrabbit0_amd64.deb

Für i386 gibt es hier Pakete.