crashcow
strict warning: Declaration of views_handler_filter_node_status::operator_form() should be compatible with views_handler_filter::operator_form(&$form, &$form_state) in /srv/crashcow.de/6.x_sites/all/modules/views/modules/node/views_handler_filter_node_status.inc on line 0.

Drupal, GPFS, Dateizugriffe und Performance

Jedem, der sich schon einmal gewundert hat, warum Drupal in einer etwas größeren Installation doch sehr schnell schnarchend langsam wird, sei empfohlen, sich einmal die von Drupal pro Request benutzten Dateien anzuschauen. Ich kämpfe momentan mit einer Installation, die bei jedem Seitenaufruf mehr als 400 Dateien einlesen musste. Solange sich diese Installation in einer normalen Serverumgebung befindet, sollte das nicht wirklich problematisch sein, braucht php doch nur 0.02 - 0.03 Sekunden um diese Dateien einzulesen und zu verarbeiten. Diese extrem verkürzte Bearbeitungszeit merkt man deutlich wenn man sich die Latenz anschaut, mit der Drupal auf einen Request antwortet.

 

Hinderlich wird das alles erst, wenn sich mehrere Server ein Filesystem via GPFS sharen, dann braucht php ganz schnell mehr als 6 Sekunden um die gleichen Operationen auszuführen. Die Lösung ist also Drupal aus dem GPFS auszulagern und im normalen Filesystem des Servers abzulegen. Der Nachteil liegt auf der Hand: keine einzelne über viele Server verteilte und von allen Servern aus erreichbare Drupalinstallation mehr und daher synchronisieren der Server von Hand.

 

Nach ein paar Experimenten war dann jedoch schnell klar, dass man das "default"-Verzeichnis und vor allem das darin enthaltene "files" lieber doch wieder ins GPFS zurücklegt, damit sich alle Server in Echtzeit bei den hochgeladenen Dateien und vor allem bei der settings.php bedienen können.

 

Der Zeitgewinn ist jedenfalls enorm. In Verbindung mit einem vernünftigen Caching - zum Beispiel memcache - ist es so möglich selbst komplexe Drupal-Seiten in weniger als 2 Sekunden auszuliefern.

Tags:

Kommentare

Bild von Gast
Gast sagt:

Also 2 Sekunden halte ich schon für kritisch bei einem social network. Ist das unter starker Last als authorisierter Nutzer oder der Optimalwert für anonymen traffic?
Wie sind denn die mount optionen (mtime, atime, etc.) und Konfiguration für das GPFS (pagepool, filecache, etc.)? Ist die Latenz zum GPFS Server das bottleneck?
Normalerweise sollte der PHP Bytecode cache die access times doch ausgleichen? Der aggregierte code sollte ja gecached werden. Oder waren das vorher diskless clients? Läuft das GPFS über ein seperates Netz? Vielleicht lohnt es sich auch in Infiniband zu investieren? Auch schonmal mit nginx+fcgi experimentiert?

Bild von Andreas
Andreas sagt:

Das GPFS ist optimal für unsere Serverumgebung eingerichtet, da läuft nicht nur Drupal drauf. Daher ging die Lösung eher in die Richtung Drupal auszulagern als an unserer Implementation von GPFS herumzuschrauben.
Die zwei Sekunden bezogen sich auf einen angemeldeten Nutzer.

Bild von Gast
Gast sagt:

Hallo Andreas,
gut, vielen Dank für die Antwort :o)
Übrigens finde ich berliner.de sehr gut gelungen.
Darüber bin ich auf Dich gestoßen (bzw über drupel.org).
Viele Grüße,
Doris

Bild von Andreas
Andreas sagt:

Das freut mich. Danke :)

Bild von Gast
Gast sagt:

Das hört sich sehr interessant an... aber leider weiß ich nicht, was dieses GPFS bedeutet.
Ist das nur möglich, wenn man Zugriff auf den Server hat? Was ist also, wenn ich meine Drupal-Seite bei einem ganz normalen Procier wie hosteurope oder strato habe. Hat man dann die Voraussetzungen dafür??
Sorry für die vielleicht für Dich etwas dumme Frage...
Würde mich aber über eine Antwort freuen :o)
Doris

Bild von Andreas
Andreas sagt:

Hallo Doris,

also normalerweise ist das etwas, mit dem man sich nur rumschlägt, wenn man eigene Server betreut. GPFS ist dabei ein bestimmtes Dateisystem, welches es erlaubt, Festplattenplatz über mehrere Server zu verteilen.

Im Normalfall solltest du als Nutzer eines großen Providers dir da eigentlich keine Gedanken machen müssen.

VG - Andreas