Drupal Optimierungen für jederman - Part 1

Änderungen an der includes/commin.inc

Zeile
file_save_data($data, $csspath .'/'. $filename, FILE_EXISTS_REPLACE);
durch
file_save_data(gzencode($data,9), $csspath .'/'. $filename . '.gz', FILE_EXISTS_REPLACE);
ersetzen. Genauso Zeile
file_save_data($contents, $jspath .'/'. $filename, FILE_EXISTS_REPLACE);
durch
file_save_data(gzencode($contents,9), $jspath .'/'. $filename .'.gz', FILE_EXISTS_REPLACE);
ersetzen.

In der .htacces folgendes am Anfang eingügen:

Und vor der Drupal Rewrite Regel:

Ist das ganze Gehacke wirklich vonnöten?

Bei mir tuts auch dies in der .htaccess, da sind auch gleich Workarounds für die üblichen Verdächtigen bei :

Alexander Langer, bei deinem Weg werden wie Files in Echtzeit bei der Auslieferung vom Server gezipt, bei mir werden die Files einmal beim Cache Refresh erstellt und liegen als gzip vor. 2 Unterschiedliche Lösungen zu einem Problem. Bei einem Hochbelasteten Webserver ist das schon ein kleiner Unterschied.

Ok, den Punkt lasse ich gelten.

Zum Glück habe ich den Fall bislang noch nicht gehabt. Meist laggen Server wegen zu wenig I/O Performance.
Aber ist doch schön, dass es immer einen Plan B gibt. :-)

Bevor ich aber am Core rumfrickeln würde, würde ich über nen Proxy und / oder lighttpd oder nginx nachdenken ... (ist zwar nicht ganz "für jedermann", aber das sind "hochbelastete Webserver" ja auch nicht ;) )

Hehe, da muss ich dir auch wiederum zustimmen.
Ich hab mal ein par Experimente mit lighttpd als statischen Fileserver gemacht. Brachte nicht so viel. Richtig interessant war dagegen der Einsatz vom APC.. Da kann man echt nur sagen "wow - das Ding geht ab wie Schmids Katze..... ;)".Lief richtig gut. Leider gab nach ein par Tagen gab es auf dem Server nen Memory Problem. Daher wieder deaktiviert. Aber php6 kommt......

nach dem "vorführeffekt" von gestern ging später die Seite gut ab. Aber ob ich das wirklich einsetze ist sone sache. im core rumzufrickeln ist sone sache. Kann man bestimmt auch nen Modul für schreiben, werde mal gucken was man da so machen kann!

APC betrachte ich als Standardausrüstung eines jeden produktiven PHP Webservers. Was die meisten lustigerweise nicht wissen ist, dass man es mitunter konfigurieren muss.

Statt lighhtppd als statischen File-Server auf derselben Maschine würde ich es lieber mit Squid als Proxy probieren und / oder aber geich komplett auf lighty oder nginx umsteigen.

Es gibt so viel was man im Einzelfall machen kann, wenn man erstmal weiß so die Karre im Dreck steckt. MySQL tunen (inkl. Auslagerung von /tmp ins RAM, gerade für Drupal 5, bringt aber für manche MySQL 5 Versionen wegen Bug nichts), statischen File-Cache (Boost), Memcache, Proxy, Datenbankserver auslagern, und und und

ACP als default? Auch mit Konfiguration macht er ein manchen Fällen so einige Probleme die auch sehr gut Dokumentiert sind. Auch steht in vielen Dokumentation das man bei einem Einsatz von APC den Server mal gegeben falls neu starten muss. Das ist für mich dann keine Software die unbedingt Produktiv ist. Hängt aber auch sehr stark vom Einsatzort ab. z.b mod_php oder fcgi Lösungen und und und....aber wirst du ja selber wissen ;).

Lighttpd habe ich bei meinen Test als CDN verwendet, er lief auf einen anderen Server. Bevor ich Drupal modifizieren wollte, hab ich einfach mit einigen Apache proxy Tricks und Rewrite alle statischen Files von diesem Server geholt - aber APC brachte mich mehr zum stauen :D

Alexander Langer, schon Erfahrungen mit Kombinationen von obcode Cache Techniken und mysql Cache gemacht? Beispiel APC + Memcache????