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?
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 - 17. Mai. 2013, 20:10 - Rubrik: Performance
chapeau für die Initiative.
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.
Könnten sie das näher Ausführen
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 :)