nicht angemeldet
Hi Andreas,
Was ich nicht so ganz verstehe, warum Provider,
die ja wohl auch an einer Verringerung des
Traffics interessiert sind,
Ja? Wieso? Die verdienen jawohl an jedem MB Traffic
extra! Oder brauchst Du den Traffic nicht bezahlen?
(Fast) kein Provider besitzt ein eigenes Internet-Backbone. Sie müssen also die Auffahrt zur Daten-Autobahn einkaufen.
Es wäre für jeden Provider _dringend_ zu empfehlen, komprimierte Daten auszuliefern.
Das pricing kann er dann ja einerseits auf den Bruttodaten (vor Komprimierung) basieren lassen, um vergleichbare Preise zur Konkurrenz zu bieten - er kann aber auch billigere Preise anbieten (z. B. 30% günstiger), wenn er beim Einkauf durch die Komprimierung 50% sparen kann.
Wäre ich ein Provider, dann würde ich allerdings Preispakete auf Netto-Traffic basieren lassen, dann etwas höher als bei der Konkurrenz, aber den Kunden erklären, wieso das für _sie_ trotzdem besser ist.
Das Problem ist in jedem Fall, daß der Provider nicht entscheiden _sollte_, welche Seiten komprimiert ausgeliefert werden.
Meiner Meinung nach _muß_ das der Seitenanbieter entscheiden - weil angesichts der zahlreichen kaputten Browser (ungefähr 99% aller verfügbaren, inklusiver aller M$IE und aller Mozillas!) nur dieser selbst entscheiden kann, welche Risiken er einzugehen bereit ist.
Ich würde als Provider mod_gzip also laden, nicht aber einschalten, und den Kunden erklären, wie sie via .htaccess eine ihren Wünschen entsprechende Konfiguration schreiben können, _um_ dadurch ihren Traffic-Preis zu reduzieren.
wer verbraucht schon mehr als den im Paket
enthaltenen Traffic, ich glaube nicht sehr
viele, naja...
Eben. Um so mehr muß der Provider aber daran interessiert sein, daß die Daten komprimiert ausgeliefert werden! Die Kunden zahlen ja immer noch den Paketpreis, der Provider muß aber weniger Bandbreite einkaufen!
Und "nebenbei" hat er auch noch zufriedenere Kunden, weil deren Seiten schnellere Antwortzeiten haben.
mod_gzip kennen die meisten potetnteillen Kunden
der Massenhoster eh nicht, also warum sich diesen
Klotz ans Bein binden, denn mod_gzip ist durchaus
eine höhere Serverbelastung, was bei gleibleibender
Performance mehr Server benötigt, und die kosten
Geld...
Die Bandbreite kostet viel mehr zusätzliches Geld. mod_gzip erzeugt zwar zusätzliche CPU-Last beim Komprimieren, aber es _spart_ auch CPU-Last beim Senden der Daten durch die TCP/IP-Schnittstelle.
Es hängt von der Verteilung der Seitenzugriffe ab, ob das nicht in der Summe sogar zu einer _Entlastung_ des Servers führt.
Und all dies gilt zudem nur, wenn _alle_ Seiten dynamisch komprimiert werden müssen!
Das ist aber nicht der Fall - die komprimierten Seiten können gecached werden (wahlweise in einem Proxy oder in Form vorkomprimierter statischer Parallel-Versionen - beides wird hier im Self-Portal praktiziert) und müssen dann jeweils nur noch ein einziges Mal komprimiert werde, für beliebig viele Lesezugriffe.
'./configure' '--with-mysql=/usr' '--with-zlib'
Wer braucht denn diese zlib? Du weißt, daß das genau die Bibliothek ist, welche eine gzip-Komprimierung durchführen kann?
(Allerdings hat mod_1.3 gzip seine eigene gzip-Implementierung und nutzt die normale zlib nicht.)
Viele Grüße
Michael