Datenkompression Serverlast (gelöst)

[sander]

Ich habe mir in heute zum Spaß angesehen wie groß einige Seiten in STNE sind. Dabei ist mir aufgefallen, dass 200-300 KB die Regel sind. Das kam mir komisch vor, da andere Webseiten mit weit unter 100KB auskommen und teilweise auch ziemlich viel HTML Code aufweisen.

Der Grund ist die scheinbar deaktivierte Daten-Kompression im Webserver. (Siehe Grafik 2) Darum habe ich mal einen Vergleich gemacht.
Einmal sieht man links die Seitengröße direkt auf dem STNE Server. Rechts habe ich mir genau diesen Seitenquelltext als HTML anzeigen lassen, danach als HTML gespeichert und auf einem anderen Webserver gespeichert, der die Kompression aktiviert hat.

Das Ergebnis ist ganz nett, eine Reduzierung von 200KB auf 50KB. (Siehe Grafik 2) Das ist 1/4 der vorherigen Seitengöße oder um es in Wartezeiten auszudrücken:
Bei meiner 768er DSL Leitung warte ich alleine ~3 Sekunden (Siehe Grafik 1) und mehr auf eine STNE Seite, während es mit Kompression in etwa eine Sekunde wäre.

Daher mein Frage, rennt die CPU schon am Limit, dass die Kompression die Kiste überfordern würde? Selbst die schwächste Stufe einer Datenkompression würde sicher eine Reduzierung von 50% erzielen und somit den Usern mit einer schwachen Leitung mehr als zugute kommen. Es ist ja nicht so, als würden wir unbedingt so langsames Internet haben wollen... Wir haben schlichtweg keine Alternativen.

Allerdings kenne ich mich mit dem IIS von Windows nicht aus, der Apache bietet diese Kompression "ab Werk", genannt "mod_deflate". je nach Distribution muss es nur noch aktiviert werden.

[Brokkoli]

Allerdings kenne ich mich mit dem IIS von Windows nicht aus, der Apache bietet diese Kompression "ab Werk", genannt "mod_deflate". je nach Distribution muss es nur noch aktiviert werden.

Ist beim IIS im Prinzip genauso. Ist nur eine Konfigurationseinstellung, um das zu aktivieren.

Ich bezweifel aber, dass es dadurch wirklich besser wird. Wer ne sehr langsame Verbindung hat, wird sicher davon profitieren. Wer ne schnelle Verbindung hat (die meisten haben nunmal DSL6000 oder schneller -> unter 1/2 Sekunde Übertragungszeit), wird möglicherweise eher längere Ladezeiten haben wegen dem Overhead durch die Kompression.

[Navek]

Denkt auch an die Smartphone-User bitte. Da geht's auch um die Menge der übertragenen Daten. An vielen Stellen, an denen man nur mit EDGE surfen kann, sind 150 gesparte Kilobytes verdammt viel Wert.

Die gzip-Kompression ist auch wahnsinnig schnell. Viel an Performance geht da nicht drauf.

[Proximo]

Hallo zusammen,

ich habe selbst auf DE1 und DE4 die Kommunikation überprüft, der Server hat mir stets in gzip-kompremierten Übertragungen geantwortet. Vielleicht wären Details/spezifische Seite des Aufrufs o.ä. nützlich? Des weiteren natürlich der exakte Anfrage/Antwortheader.

MFG Proximo

[Brokkoli]

Also mir antwortet er auch immer gzipt. so wie ich das sehe immer auf der niedrigsten kompressionsstufe, ca 50-70% reduziert

[sander]

Aye, ihr habt recht, beim Rechner meiner Frau ( Anderer Standort, anderer Rechner ) am heutigen Tag kann ich ebenfalls eine aktive Kompression bestätigen.
Ich werde das am Nachmittag zu Hause nochmals überprüfen, ob dort eventuell etwas falsch eingestellt ist. Anschließend melde ich mich hier zurück.
( Alternativ bleibt eigentlich nur noch, dass es zwischenzeitlich aktiviert wurde aber das ist im Moment reine Spekulation. )

Auf jeden Fall danke dafür, dass ihr der Sache nachgeht.



http://game.stne.net/Game.aspx?cr=AZ5EwBOSsHBs9VUCEYdvjTX_1usIB4cHg3lvm lvWeoVdMJ2xAJHVVnTri7kfYx0dS1RL2mf4vuSjvfyi9OVwt9Q _3_3
Antwort-Header
Cache-Control no-cache
Pragma no-cache
Transfer-Encoding chunked
Content-Type text/html; charset=utf-8
Content-Encoding gzip
Expires -1
Vary Accept-Encoding
Server Microsoft-IIS/7.5
X-AspNet-Version 4.0.30319
X-Powered-By ASP.NET
Date Sat, 29 Oct 2011 07:24:53 GMT

Nachtrag: Die Ursache ist tatsächlich an meinem Rechner zu Hause zu suchen, woran genau (Router, Proxy oder Browser) muss ich mir erst einmal in Ruhe ansehen.
Vielleicht ist das ein generelles Problem meiner Konfiguration nud betrifft alle Seiten. Oder es ist nur die Übertragung Proxy -> Browser unkomprimiert aber STNE-Server -> Proxy ist noch komprimiert?!
Wie auch immer, die Details habe ich heute nicht prüfen können. ( Zu viel Arbeit im Garten und schönes Wetter, da sitzt man nicht drinnen. )
Ich halte euch aber gerne auf dem Laufenden.

Nachtrag 2: Nach einem Blick in die Weiten des Internets hat sich herausgestellt, dass der von mir verwendete Proxy Server Squid Probleme mit gzip hat, wenn dies Seite von einem IIS Webserver stammt.
Das spiegelt auch meine Beobachtungen wieder. Beim Frauchen geht es, bei mir zu Hause wo sämtlicher Datenverkehr durch einen Proxy geht, ist die Kompression nicht gegeben. Von daher ist das eher kein Problem von STNE sondern meines, wie es scheint.

Nachtrag 3: Die Ursache für die fehlende Kompression während der Verwendung des Proxy Server ist scheinbar darin begründet, dass der IIS bei der Verwendung von HTTP/1.0 in der Standardkonfiguration keine Kompression aktiviert. Der von mir verwendete Proxy in der aktuellen Version jedoch nur HTTP/1.0 entgegen nimmt bzw. anfordert. Der Browser ohne Proxy dazwischen arbeitet jedoch durchweg mit HTTP/1.1.
Nun denn Ursache erkannt. Problem liegt definitiv auf meiner Seite. Jetzt muss ich also Lösungen suchen, die nächste Version soll zwar voll HTTP/1.1 fähig sein aber bis die erscheint, kann das durchaus noch ein paar Tage länger dauern. ;)