Hallo,
meine Plone-basierte Website fühlt sich etwas "träge" an (nahezu Standard-Layout). Um das Rendering im Browser ausschließen zu können und das Bauchgefühl mal mit Fakten zu untermauern, habe ich die Site gestern mit httperf unter die Lupe genommen und mit Entsetzen festgestellt, dass ich so zwischen 1,5 und 3 Requests pro Sekunde hinbekomme. Auf der Seite ist nicht allzu viel los, aber der gefühlt langsame Seitenaufbau nervt (bei ca. 300 - 500 ms pro Request, mehreren Stylesheets und Layout-Grafiken etc. summiert sich das ganz schön).
beim googlen nach Performance Tuning für Plone und Zope bin ich bisher auf zwei Hauptthemen gestoßen: vorgeschalteter Caching Proxy und ZEO. Ehrlich gesagt halte ich beide für mit Kanonen auf Spatzen geschossen, aber wenn's nicht anders geht...
Wenn Cache Proxy, worauf würdet ihr setzen? Squid? Apache? oder etwas völlig anderes? Bei Lighty macht mir die unvollständige Dokumentation von mod_proxy und mod_mem_cache noch zu schaffen...
Wie steht's mit ZEO? Verhindert das globale Interpreterlock von Python wirklich, dass innerhalb einer Prozessgruppe immer nur jeweils ein Thread laufen kann, auch auf einem SMP-System?
Und zu guter letzt: Gibt es noch andere Möglichkeiten als die genannten? Wie habt ihre eure Zope/Plone-Sites beschleunigt?
Plone Performance Tuning
-
- Posts: 133
- Joined: 2004-03-30 14:44
Re: Plone Performance Tuning
Deine Plone/Zope-Instanz läuft nicht im Debug-Mode?jfreund wrote:Hallo,
meine Plone-basierte Website fühlt sich etwas "träge" an (nahezu Standard-Layout). Um das Rendering im Browser ausschließen zu können und das Bauchgefühl mal mit Fakten zu untermauern, habe ich die Site gestern mit httperf unter die Lupe genommen und mit Entsetzen festgestellt, dass ich so zwischen 1,5 und 3 Requests pro Sekunde hinbekomme. Auf der Seite ist nicht allzu viel los, aber der gefühlt langsame Seitenaufbau nervt (bei ca. 300 - 500 ms pro Request, mehreren Stylesheets und Layout-Grafiken etc. summiert sich das ganz schön).
Das ist korrekt, ein Zope-Request hat einen globalen Lock auf die ZODB. Abhilfe bringt nur die Konfiguration von ZEO: Das ist nicht wirklich schwierig und du kannst mehrere Frontend-Server betreiben um die Performance weiter zu steigern. Ansonsten ist die Kombination Squid/Zope weit verbreitet.jfreund wrote: beim googlen nach Performance Tuning für Plone und Zope bin ich bisher auf zwei Hauptthemen gestoßen: vorgeschalteter Caching Proxy und ZEO. Ehrlich gesagt halte ich beide für mit Kanonen auf Spatzen geschossen, aber wenn's nicht anders geht...
Wenn Cache Proxy, worauf würdet ihr setzen? Squid? Apache? oder etwas völlig anderes? Bei Lighty macht mir die unvollständige Dokumentation von mod_proxy und mod_mem_cache noch zu schaffen...
Wie steht's mit ZEO? Verhindert das globale Interpreterlock von Python wirklich, dass innerhalb einer Prozessgruppe immer nur jeweils ein Thread laufen kann, auch auf einem SMP-System?
Jürgen
-
- Administrator
- Posts: 2639
- Joined: 2004-01-21 17:44
Re: Plone Performance Tuning
Nein, ganz normal als Daemon per zopectl gestartet...juergen wrote:Deine Plone/Zope-Instanz läuft nicht im Debug-Mode?
Nachdem ich endlich wieder mal ein bisschen Zeit hatte, mich damit zu beschäftigen, kann ich jetzt folgendes berichten: Die Umstellung auf ZEO ist sehr zu empfehlen. Selbst bei nur einer Zope-Instanz macht sich das bereits bemerkbar (allerdings leider auch im RAM-Konsum). Der Einsatz mehrer Zope-Instanzen mit demselben ZEO-Backend bringt natürlich auch etwas, aber die Steigerung ist nicht so enorm. Knackpunkt ist da auch eine vernünftige Balance-Strategie des Reverse Proxies...
Unterm Strich bin ich jetzt mit 4 Instanzen und Lighty davor (Balance-Modus "fair") auf ca 130ms pro Request runtergekommen; das ist schon mal eine ganz passable Steigerung. Für den regulären Betrieb werde ich wohl wieder auf Hash als Balance-Mode zurückgreifen und noch ein bisschen an der Caching-Policy der einzelnen Zope-Instanzen schrauben (für den Benchmark wäre Hash ziemlich sinnfrei gewesen, da ja immer dieselbe URI aufgerufen wird und bei "hash" dann auch immer derselbe Backend-Host vom Proxy bemüht würde).