Wer das Content Management Framework Drupal das erste Mal einsetzt wird womöglich nach kurzer Zeit ein wenig gefrustet sein, spätestens wenn er die erstesn komplett weißen Seiten angezeigt bekommt, der sog. WSOD (white screen of death). Ursache ist, dass gerade nach der Installation und Aktivierung einiger zusätzlicher Module der Speicherbedarf während der Ausführung von Drupals PHP Skripten ansteigt und häufig ber dem liegt, was man von Systemen wie Wordpress & Co. gewohnt ist.

Serverseitig gibt es eine Konfigurationsoption des PHP Interpreters namens php_memory_limit. Sie legt den maximal von einem Skript während der Ausführung belegbaren Platz im Hauptspeicher des Servers fest. Dies ist im Grunde ein Sicherheitsmechanismus der verhindern soll, dass ein fehlerhaftes Skript zu viele Ressourcen an sich reißt, die dann an anderer Stelle im System fehlen und dieses zum Absturz bringen könnten.

Bis Drupal 6 kam man für kleinere Standardgeschichten mit einem Limit von 32 MB noch halbwegs hin. 64 MB sollten es aber schon sein und empfohlen wurden 128 MB, gerade wenn das Modul ImageCache eingesetzt wird, dass Bilder automatisch skaliert und je nach Ausgangsmaterial (Auflösung und Dateigröße bei modernen Digital Kameras steigen ja zusehends) zur Berechnung kleinerer Bildversionen entsprechend Hauptspeicher benötigt. Auch beim Einsatz des E-Commerce- / Shop-Moduls Übercart für Drupal wird das Limit von 64 MB schnell einmal überschritten.
Bei Drupal 7 ist der Grundbedarf nochmals deutlich angestiegen, da Funktionen die sonst durch zusätzliche Module nachgerüstet wurden nun bereits in der Basisversion vorhanden sind.

In der Praxis stellt sich für den Webmaster daher die Frage ob sein Webspace geeignet ist, was er noch für Reserven hat und wo er geeigneten Webspace findet. Die meisten Hobby- und semi-professional Drupaler raten von Strato und 1&1 ab.
Hetzner, im Bereich Root-Server sehr gut aufgestellt, lässt bei Shared Hosting Paketen lediglich ein PHP Memory Limit von max. 50 MB zu - zu wenig.
All-Inkl. (Neue Medien Münnich) setzt standardmäßig ein Limit von 64 MB, welches sich aber über einen Eintrag wie "php_value memory_limit 96M" in der .htaccess Datei erhöhen lässt. ggf. muss man aber damit rechnen, dass einem All-Inkl. bei der "Entdeckung" hier einen Strich durch dei Rechnung macht. Dann zeigt man sich gerne etwas unflexibel und verweist den Kunden darauf, dass er ja einen ungleich teureren Managed Server anmieten kann. Ich spreche hier aus Erfahrung (direkte Nachfrage beim Support).
Mein Tipp lautete im Bereich Shared Hosting daher derzeit Hosteurope, wo seit dem WebPack 3.0 genannten Paketen ein PHP Memory Limit von 128 MB zur Verfügung steht.
Daneben gibt es mittlerweile auch den ersten auf Drupal spezialisierten Hoster in Deutschland. Die Jungs von DrupalCONCEPT bieten High Performance Drupal Hosting an. Dieser ist zwar auf den ersten Blick recht hochpreisig, ist es aber auch wert. Dahinter steckt ein Hosting Setup inkl. Memcache und Varnish, man bekommt u.a. einen direkten Wartungszugang via SSH, ein eigenes Repository für das Versionskontrollsytem Git und auch um Updates der Drupal Installation können sich die Jungs eigenständig kümmern.

Auf meinen eigenen Root-Servern stelle ich in der Regel ein Limit von 196 MB ein. Da meine Maschinen ausreichend Ressourcen und Reserven haben und sie nicht mit Kunden / Projekten vollgestopft sind wie bei den großen Hostern, muss ich mir hier keine Sorgen machen. Für den Endkunden ist die Suche nach passendem Shared Hosting Webspace recht schwierig, denn Angaben zum PHP Memory Limit findet man in den selten in den Hosting Paketen und müssen daher erst beim Support erfragt werden. Seit der Veröffentlichung von Drupal 7 am 5. Januar 2011 sollte man zudem auch einen Blick auf die verwendbaren Versionen von PHP und MySQL werfen, denn Drupal 7 hat als Systemvoraussetzung mindestens PHP 5.2.5 und MySQL 5.0.15 (falls MySQL eingesetzt werden soll). Auch hier gilt es ggf. die Systemanforderungen mit den Gegenbenhetern der Hoster unter Zuhilfenahme des Supports abzugleichen, um böse Überraschungen und Webspace-Wechselorgien zu vermeiden.