Performance-Analyse und -Optimierung bei umfangreichem Moduleinsatz (>100 Module und mehr)
am 18.09.2008 - 14:41 Uhr in
Hallo Leute,
wie einige von euch wissen, habe ich mir eine Liste der ca. 300 meistgenutzten und attraktivsten Dupal-Module zusammengestellt, um auf diese Art für meine Kunden umfangreichere und attraktivere Portale aufbauen zu können. Gleichzeitig möchte zu einer Erforschung umfangreicherer Drupal-Portale und zur Einschätzung und Lösung von Komplexitäts-Problemen beitragen.
Ich fürchte mich bei diesem Pionier-Vorhaben vor 2 möglichen Problemquellen :
a)Inkompatibilitäten zwischen zwei oder mehreren Modulen (, die nicht einfach zu diagnostizieren sind)
b)Performance-Einbußen durch die schiere Anwesenheit so vieler Module in einer Installation oder durch 'Performance Lecks' einzelner Module bzw. Modulkombinationen.
Einen Thread zu a) habe ich bereits eröffnet und werde mich hier mit b) beschäftigen.
Grundsätzlich ist ja Drupal von sich aus schon sehr performant. (Deutlich performanter als Typo3 und Joomla)
Darüberhinaus erlaubt es auch selbst noch weitgehendere Optimierung z.B. mitttels folgenden Modulen
- Vielfältige allgemeine Performance-Optimierung (mit dem 'boost'-Modul)
- Zusammenfassung der Javascript-Dateien, um eine einzige schnelle Übertragung zu ermöglichen (per 'javascript-aggregator'-Modul)
- Zusammenfassung der CSS-Dateien
- Throtteling (Kern-Modul) zum selektiven Abschalten, nicht zwingend benötigter Module.
Es sind auch viele händische programmier-technische Performance-Optimierungen möglich.
Schlußendlich läßt sich natürlich jedes Drupal-Portal beliebig(!!) skalieren mit Mitteln wie :
- Schnellere(r) Anschluß, HW, Server, Prozessor(en), Speicher, Festplatte etc.
- Aufspaltung in Funktionsserver wie : Proxyserver, Apache-Server, PHP-Script-Server, DB-Server, Such-, Multimedia-, Streaming- u.ä. Server
- Paralelle Server-Architekturen
Auf diese Weise ist dem Umfang und der Größe eines Drupal-Portals keine prinzipielle Schranke gesetzt, während natürlich Kosteneinschränkungen stets existieren können. Ich möchte nun in einem ersten Schritt in einer Multisite-Installation 2 ähnliche Seiten vergleichen, von denen die erste 50 Module hat und die zweite 150 Module haben soll. Eine erste Performance-Messung soll die Ladezeit-Messung per Firebug sein.
Nun zu meiner Frage b) also :
- Gibt es umfangreichere, genauere und systematischere Performance-Testmethoden?
- Welche Möglichkeiten gibt es, seine Seiten Lasttests oder Stresstests zu unterwerfen?
- Welche händischen Optimierungsmethoden kennt Ihr noch für Drupal
- Kennt Ihr Leute, die sich damit beschäftigt haben oder unfreiwillig Erfahrung sammelten ?
- Gibt es vlt. Erkenntnisse, die besagen, wieviel Performance ein Modul zieht, welsches bei einem Aufruf nicht aktiv wird ?
- Gibt es systematischeres Material zu diesem Fragenkreis irgendwo im Netz ?
Ich freue mich auf einen umfangreichen Erfahrungsaustausch.
Herzlichst,
Phil Ewert
- Anmelden oder Registrieren um Kommentare zu schreiben
jmeter
am 18.09.2008 - 15:45 Uhr
für Last- und Stresstests bietet sich z.B. JMeter an (frei wie Freibier), nicht ganz einfach zu lernen, aber damit lassen sich - entsprechende Resourcen vorausgesetzt - auch mehrere 1000 parallele Lasttests starten
um dann Aussagen zu bestimmten Modulen treffen zu können, müßte man die PHP Scripte zeitgleich überwachen lassen um eben zu wissen ob Modul A oder Modul B das Zeitproblem verursacht
im Java Bereich käme dafür sowas wie Wily in Frage (kommerziell) im PHP Bereich habe ich in der Richtung noch nicht gearbeitet
Prinzipiell kannst du mit
am 18.09.2008 - 16:41 Uhr
Prinzipiell kannst du mit einem PHP-Debugger, wie xdebug feststellen, welcher Code, wieviel Zeit verbraucht. Allerdings dürfte die Auswertung bei vielen Modulen alles andere als trivial sein.
Man muss zwischen Zwei
am 18.09.2008 - 18:46 Uhr
Man muss zwischen Zwei wichtigen Dingen unterscheiden:
Dabei braucht die Zeit für die Auslieferung der Webseite in der Regel einfach länger, als die Seite zu generieren, also kann man hier am meißten drehen.
Frontend-Performance
1. CSS Aggregation gibts schon seit D5
2. JS Aggregation gibts als Path für D5 und für D6 im Core
Backend-Performance
1. PHP Code im Arbeitsspeicher halten: http://en.wikipedia.org/wiki/Alternative_PHP_Cache#Xcache
->Bootstrap von Drupal braucht deutlich weniger Zeit
2. Datenbankcache
3. Anzahl an Modulen verringern: Man bedenke:! der User möchte nicht von den Anzahl sondern vom Einfallsreichtum der Funktionen erschlagen werden(ist zumindestens bei mir so)
Performancetest
time curl -s "http://mysite.org[1-1000]"
--------------
Blog www.freeblogger.org: Deutscher IRC-Channel: irc.freenode.net #drupal.de ... Jabber-me: dwehner@im.calug.deXING
dereine schrieb 1. PHP Code
am 18.09.2008 - 18:59 Uhr
1. PHP Code im Arbeitsspeicher halten: http://en.wikipedia.org/wiki/Alternative_PHP_Cache#Xcache
Da wird nichts groß "im Arbeitsspeicher gehalten", sondern der nach dem Parsen des PHP-Quellcodes erzeugte Bytecode wird zwischengespeichert (auf der Platte) und beim erneuten Aufruf (so das Skript zwischenzeitlicht nicht verändert wurde) wird das Parsen eingespart und direkt der Bytecode ausgeführt. Darum heißen die Dinger auch Bytecode Caches.
Im Arbeitsspeicher wird was gehalten, wenn man memcache einsetzt. Performancevorteile bringt dies in der Praxis aber auch nicht zwingend in signifikantem Ausmaß.
Es sind immer viele Faktoren, die zusammenkommen. Mal einfach in ne leere Installation 50 und 100 Module reinpacken und da was messen bringt auch nur für diesen speziellen Einzelfall ein Ergebnis, sagt aber nichts über die Performance von Produktivsystemen aus.
Es gilt die alte Weisheit: Wer misst misst Mist. ;-)
--
Webseiter
Suchmaschinenoptimierung (SEO) & Drupal