http-response / gzip

Re(2): http-response / gzip

Hawelka — Thu, 19 Jan 2012 12:00:20 GMT

gzip ist recht schnell, wenn du nicht den Fehler machst, eine Kompressionstufe höher als 4 oder so zu nehmen (höhere Stufen brauchen deutlich mehr CPU bringen aber nur wenig Vorteil in der Dateigröße)

Danke für diesen Tipp!

Das bringt in Bezug auf Seitengeschwindigkeit dem Besucher schon etwas, zumal
man bedenken muß daß nicht jeder in einer Stadt wohnt und Breitbandzugang hat.

Das ist es ja. Bei mir wären die Teilnehmer kleine Shops, die irgendwo in der Pampas angesiedelt sind

Re(6): http-response / gzip

Hawelka — Thu, 19 Jan 2012 11:58:48 GMT

warum ? Weil es kein testsystem gibt ?

Genau! Weil eben lighttpd das nicht kann.
Ich könnte einen Vergleich mit statischen Files machen, aber der erscheint mir nicht ganz fair zu sein. Schon mal hinsichtlich Cache auf beiden Seiten.

Danke jedenfalls!

Re(5): http-response / gzip

Desolationrob — Thu, 19 Jan 2012 07:47:30 GMT

warum ? Weil es kein testsystem gibt ? Ansonsten eben irgendwann des nächstens testen und einene Browser verwenden der so speed7Entwicklungstools/AddIns hat. da sieht man dann eh schön was wie schnell geleifert wurde.

Die endgültige Perfomance hängt halt von vielem ab, aber komprimierte Übertragung kann schon mal was bringen

Re: http-response / gzip

frostschutz — Wed, 18 Jan 2012 20:24:49 GMT

gzip ist recht schnell, wenn du nicht den Fehler machst, eine Kompressionstufe höher als 4 oder so zu nehmen (höhere Stufen brauchen deutlich mehr CPU bringen aber nur wenig Vorteil in der Dateigröße).

Bei Textdaten (HTML etc.) hast du gute Chancen daß das Zeug 50% oder mehr kleiner wird. Das bringt in Bezug auf Seitengeschwindigkeit dem Besucher schon etwas, zumal man bedenken muß daß nicht jeder in einer Stadt wohnt und Breitbandzugang hat.

Re(4): http-response / gzip

Hawelka — Wed, 18 Jan 2012 19:25:15 GMT

gzip/deflate muss doch eh der Browser auch mal anfordern iirc ?

Anfordern nicht - er teilt mit, dass er das kann.

Aber - jaja - das wäre eh nicht das Thema, die können das eh alle (bis auf IE6 bei Javascript).

Ich frag mich nur, wie viel Unterschied so etwas machen kann - zwischen einem Response mit 5KB und sagen wir 2KB.
Ich kann das schwer testen,

Re(4): http-response / gzip

Hawelka — Wed, 18 Jan 2012 19:25:15 GMT

gzip/deflate muss doch eh der Browser auch mal anfordern iirc ?

jaja - das wäre eh nicht das Thema, die können das eh alle (bis auf IE6 bei Javascript).

Ich frag mich nur, wie viel Unterschied so etwas machen kann - zwischen einem Response mit 5KB und sagen wir 2KB.
Ich kann das schwer testen,

Re(3): http-response / gzip

Desolationrob — Wed, 18 Jan 2012 18:41:13 GMT

hm, dann lässt sich schon ein wenig rausholen, aber da schon mobiele Zugänge relativ flott sind ist es halt so ne Sache ob man wirklich komprinmiert oder nicht. Ich würds mal testweise aufdrehen wenn wenig los ist und gucken wie es deiner CPU geht. Ist dann auch in den Hauptverkehrszeiten noich genug Luft nach oben kannst es ja aufdreht lassen.

gzip/deflate muss doch eh der Browser auch mal anfordern iirc ?

Re(2): http-response / gzip

Hawelka — Wed, 18 Jan 2012 18:14:06 GMT

welcher Content ?

reines "HTML" - sorry, hab ich vergessen dazu zu schreiben.

Re: http-response / gzip

Desolationrob — Wed, 18 Jan 2012 18:09:34 GMT

welcher Content ? Wenn das Bilder sind bringts ohnehin nix, ausser das du deien CPU bissl beschäftigst.

http-response / gzip

Hawelka — Wed, 18 Jan 2012 16:39:55 GMT

Hallo Leute!

Leider hab ich heute feststellen müssen, dass "lighttpd" nur statischen Content komprimieren kann.
Was meint ihr: wenn 95% aller Responses (dynamisch generiert) ca. 5KB groß sind - lohnt das Komprimieren überhaupt noch?
Serverseitig hätte ich halt den Vorteil, dass die CPU etwas weniger belastet wird, die hat eh schon mit SSL-Verschlüsselung zu tun.

Danke schon mal!
Hawelka