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.
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.
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 :)
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 :)