nicht angemeldet
Hi!
vorab: Sorry für die vielen Tippfehler, ich gelobe Besserung ;-)
(Fast) kein Provider besitzt ein eigenes Internet-Backbone. Sie müssen also die Auffahrt zur Daten-Autobahn einkaufen.
klar!
Es wäre für jeden Provider _dringend_ zu empfehlen, komprimierte Daten auszuliefern.
naja, aber nur wenn es tatsächlich so gut wie keine
Mehrbelastung ist. Denn die geben die Kosten für den traffic ja nicht 1:1 an die Kunden weiter, wenn die für ein GB 10 Cent bezahlen, bezahlt der Kunde vermutlich 20 oder 25 oder noch mehr(habe keine Ahnung von den Preisen).
Wenn denn jetzt 70% Traffic eingespart wid, ist das ja wirklich prima für die Kunden, aber dem provider entgehen 70% der Einnahmen aus der Weiterverkauf der Bandbreite. Das sind rein wirtschaftliche Interessen. Ich weiß auch nicht ob Den pricing-System rechtlich so einwandfrei ist, denn Du berechnest ja eigentlich zu viel Traffic, da werden sich wohl diejenigen die das eh so gemacht hätten beschweren, denn jetzt haben alle DAUs denselben Vorteil.
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.
Wobei mir gerade einfällt, 70% war wohl übertrieben, man muß ja sehen das ein großer Teil der Daten ja kleine html-Dateien sind und vor allem Bilder! Und die kann man so gut wie nicht komprimieren!
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.
jaja, aber damit entgehen ihm vermutlich einige Kunden, die wenig Ahnung haben!
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.
Genau das ist es was ich wollte, aber der Provier meinte halt es gäbe bereits gute Lösungen(multiview/Ausgabesteuerung), so dass dies wieder nur einen Performance-Verlust zur Folge hätte für nichts und wieder nichts. Wenn das den so geladen und _nicht_ benutzt wird, kostet das denn dann überhaut was?
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!
ja aber wenn das alles so einfach wäre, warum macht das keiner? Ich denke Du hast das Problem genannt, das sollte Sache der Kunden sein, und welcher Kunde der unter dem Limit bleibt schert sich um sowas?
Und "nebenbei" hat er auch noch zufriedenere Kunden, weil deren Seiten schnellere Antwortzeiten haben.
das ist ein Argument
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.
Meinst Du wirklich? Das senden kostet doch nun wirklich nicht viel, komprimieren ist doch ganz was anderes, oder komprimiert mod_gzip nicht immer _alles_ zur Laufzeit? Gibt es da auch einen cache? Aber das funktiniert wieder schlecht mit dynamischen Seiten.
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.
Aber das macht mod_gezip doch nicht alleine, oder? Dazu braucht es doch noch entsprechende Software!
'./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?
Sehr wohl, habe ich letzte Woche exzessiv betrieben ;-) Aber das ist halt nur das PHP-Modul welches einkompiliert wurde, das hat mit dem Apachen ja nichts zu tun!
Grüße
Andreas