help.twoday.net: mod_deflate / GZIP (Apache Server)

mod_deflate / GZIP (Apache Server)

In letzter Zeit häuft sich der Twoday-Fehlerklassiker "Maximum Thread Count Reached". In dem Zusammenhang ist mir aufgefallen, dass mod_deflate (GZIP) auf Eurem Apache Server derzeit nicht aktiviert ist, was dazu führt, dass der gesamte Traffic vom Server zum Client unkomprimiert erfolgt.

Verschiedene gzip-Testseiten errechnen für twoday.net veritable Transfereinsparraten von 77%+ und eine Faktor4-Geschwindigkeitserhöhung, wenn man GZIP einsetzen würde ( siehe http://www.bilder-hochladen.net/files/5loo-7v-db8e.jpg ).

Hat es einen besonderen Grund, dass mod_deflate auf dem Webserver nicht aktiv ist?

P.S. GZIP verursacht zwar eine leicht höhere Serverlast durch die Seitenkomprimierung - diese wird jedoch m.E. überkompensiert durch die geringere Belastung der Client-Downloads. Abgesehen davon ist die tatsächliche und gefühlte Performance für den Twoday-Anwender sehr viel besser. Nicht zuletzt könnte dies auch helfen das "Maximum Thread Count"-Aufkommen zu nivellieren. Any thoughts?

NeonWilderness vor 4886 Tagen

2085

6 Kommentare Kommentar verfassen

Kienspan vor 4886 Tagen

chapeau für die Initiative.

Der "max-thread-count" kommt aus helma und hängt mit den Datenbankrequests zusammen. Wenn die zulange dauern, gehen die threads aus. Datenbankrequests von spamern und Suchmaschinen können da negative Auswirkungen zeitigen, keine Frage. Allerdings ist die (schleissige) Organisation der Datenbank und die (ungeschickte) Formulierung der requests im helma von größerer Bedeutung.

antworten

NeonWilderness vor 4886 Tagen

Hm, verstehe, wenn die Datenbankthreads der Bottleneck sind, dann würde GZIP in dem Fall nicht helfen (unabhängig davon würde ein GZIP-Einsatz für die Anwenderseite sicher positiv zu vermerken sein).

Wenn also die Datenbankrequests das Problem sind, wäre es möglicherweise eine Tuning-Option, diejenigen Anwendungsfunktionen zu ermitteln, die wg. ihrer SQLs/DB-Zugriffe häufig zu Problemen führen, z.B. sowas wie %Imagelist% / Twoday-Bildergallerien oder Ähnliches. Womöglich wäre es ein Weg, diese Ressourcen- und Performance-Killer zugunsten einer besseren allgemeinen Nutzererfahrung zu deaktivieren (unter der Annahme, dass die Datenbankstruktur und das SQL-Design wahrscheinlich nicht angerührt werden).

Das ist wie im wirklichen Leben: manchmal muss man amputieren, damit der Rest überlebensfähig bleibt.

antworten

kender vor 4883 Tagen

Könnten sie das näher Ausführen

Allerdings ist die (schleissige) Organisation der Datenbank und die (ungeschickte) Formulierung der requests im helma von größerer Bedeutung.

Was genau meinen sie damit? twoday hat ein sehr einfaches Datenbankshema wo wir 166 Abfragen pro Sekunde machen, im Durchschnitt. Selects dauern 3 milis auf Beiträge, also da von ungeschickter Formulierung zu sprechen, find ich jetzt ein bißchen wage.

Die Datenbank ist nach unserer Ansicht tot optimiert.

Was ich aber anmerken muß ist das helma selbst ein "Problem" darstellt. Wie sie sicher wissen wird helma, in der von uns eingesetzten Version, nicht mehr weiterentwickelt. Sicherheitstechnisch stellt das kein Problem da, weil bis jetzt gab es noch keinen einzigen helma Hack. Performance technisch kann man da aber sicher was rausholen, wie z.B. Update des verwendeten Webservers jetty.

Hier gibt es sicher viel Diskkusionsraum, ich weis aber nicht ob das hier der richtige Platz ist? OK "Forum" also vielleicht doch :)

antworten

kender vor 4883 Tagen

Bezüglich mod_deflate

Danke für die Anregung. Leider ist es nicht so einfach. Die CPU Load bildet eine nicht abschätzbare Komponente abhängig von der File Größe.

Bei kleinen Files ist das kein Problem da bleibt die CPU Last im Rahmen. Bei Filegrößen ab 50KByte steigt die CPU Last um das ~10 fache.

Bei normaler Last (15 bis 20 requests pro Sekunde) glaub ich stellt das kein Problem da, aber wenn "viel" los ist (30 oder mehr requests pro Sekunde) glaub ich ist das ein nicht zu verachtender Faktor.

Das der User ein verbessertes Browseerlebnis bekomm halte ich für ein Gerücht. Das Entpacken muß ja wieder am Clientrechner passieren und das hängt dann wieder von der CPU des Clients ab. Für mobile Geräte wäre das sicher ein Vorteil, noch als Anmerkung, wegen langsamer Internetverbindung.

antworten

NeonWilderness vor 4883 Tagen

Vielen Dank für die Anmerkungen! Ich glaube eher nicht, dass die verbesserte Performanceeinschätzung "ein Gerücht" ist. Ich betreibe selber eine Joomla-Seite auf einem Apache-Server, die nach der Aktivierung von GZIP spürbare Performanceverbesserung im Rendering der Webseite auf dem Client zeigte. Ich glaube auch weniger, dass man sich bei heutigen Prozessoren große Gedanken um die Auslastung der Client-CPU für das Entpacken von vielleicht 4-5k großen Packets machen muss. Meine Erfahrung ist da eher positiv.

Wieauchimmer - am Ende des Tages ist das keine Glaubensfrage, sondern man kann es ganz einfach testen und messen. Wenn sich sowohl die CPU Last als auch die Enduserperformance auch nur graduell verbessert, spräche doch nichts dagegen, GZIP zu nutzen.

antworten

kender vor 4883 Tagen

In letzter Zeit häuft sich der Twoday-Fehlerklassiker "Maximum Thread Count Reached"

Bedeutet übrigens das 100 gleichzeitige requests gleichzeitig bearbeitet werden. Das deutet auf ein helma Problem hin (dem wir noch nicht auf die Schliche gekommen sind) oder mehr als 100 requests pro Sekunde, wo ich allerdings schon von einer DOS Attacke ausgehe ;), oder es ist demjenigen egal ob er uns lahmlegt oder nicht. Manchmal "verläuft" der java Prozess sich in 100% CPU Last und bleibt dabei.

das tritt übrigens 1 mal pro Woche auf. Wir sollten mal einen Fail Whale einführen dann entsteht ein Hipe ;)

antworten