Hi Andreas,
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 der Provider den Brutto-Traffic bepreist, dann spart _er_ Geld, der Kunde bezahlt dasselbe, der Gewinn ist also höher, _und_ der Kunde halt schneller ausgelieferte Seiten. Also?
Dies gilt sowohl für das pricing-Modell basierend auf Brutto-Volumen als auch für das pricing-Modell mit hohen, nicht ausgeschöpftem Kontingent des Kunden.
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.
Du legst das falsche pricing-Modell zugrunde.
_So_ funktioniert es in der Tat nicht.
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.
Erstens ist alles rechtlich einwandfrei, was der Kunde unterschrieben hat und nicht sittenwidrig ist.
Zweitens wird nicht jeder DAU denselben Vorteil haben, weil die Komprimierung als Konzept für DAUs nicht einsetzbar ist. Der Kunde _muß_ die Komprimierung selbst konfigurieren - nicht der Provider.
Es werden also definitiv nicht alle Kunden auf komprimierte Auslieferung umstellen. Aber gerade deshalb wird die CPU-Last auf dem Server auch nicht explodieren können.
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!
Richtig. Die angegebenen 50% sind ein geschätzter Mittelwert. Ein HTML-lastiges Angebot kann auch auf 70% oder noch mehr kommen.
jaja, aber damit entgehen ihm vermutlich einige
Kunden, die wenig Ahnung haben!
Wer zwingt den Provider, nur _ein_ Preismodell anzubieten?
Er kann seinem Kunden ja die Wahl lassen zwischen Einsatz mit mod_gzip und zugehörigem pricing-Modell für Netto-Traffic und ohne mod_gzip für Brutto-Traffic.
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 Provider
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 Du das manuelle Umstellen sämtlicher Links in allen Deinen Seiten als gute Lösung ansiehst ... bitte sehr.
Wenn das den so geladen und _nicht_ benutzt wird,
kostet das denn dann überhaupt was?
Kaum. Ein bißchen RAM, natürlich (100 KB oder so). Sonst nichts.
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?
Derjenige, der seine Besucher mit schnellen Seiten bedienen will. Derjenige, dem seine Besucher nicht egal sind. Derjenige, der selbst den Apache konfiguriert, um "Expires:"- und "Cache-Control:"-Header zu senden. Derjenige, der das Gehirn eingeschaltet hat.
Zugegeben - viele sind das nicht. ;-)
Aber gerade die Kunden, die unter dem Limit bleiben, sind es, an denen der Provider (!) sparen kann.
Denen sollte er also sagen, daß sie ihre Seiten schneller ausliefern können, ohne daß sie dafür _zusätzlich_ bezahlen müssen.
Sie bekommen mehr Service ohne Aufpreis - er muß weniger Traffic einkaufen. Beide sind glücklich.
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,
Beides kostet etwas.
Und der TCP/IP-Stack eines Webservers _ist_ ein potentieller Engpaß. Jedes Kilobyte, welches da nicht hindurch muß, entlastet die CPU.
oder komprimiert mod_gzip nicht immer _alles_ zur
Laufzeit? Gibt es da auch einen cache?
Ja - inzwischen kann man das so nennen.
Aber das funktiniert wieder schlecht mit dynamischen
Seiten.
Es funktioniert überhaupt nicht mit dynamischen Seiten.
Aber bei denen könntest auch Du nur zur Laufzeit jedesmal komprimieren - und _das_ kann mod_gzip eben effizienter als Du.
Das ist aber nicht der Fall - die komprimierten
Seiten können gecached werden (wahlweise in einem
Aber das macht mod_gezip doch nicht alleine, oder?
Doch, das macht mod_gzip alleine (bei statischen Dokumenten). RTFM.
Bei dynamischen geht Caching nur, wenn das Konzept der dynamischen Erzeugung des Dokuments _will_, daß das Dokument gecached werden _darf_.
Das ist also eine Entscheidung, die für jedes Dokument einzeln gefällt werden muß - in Form von HTTP-Headern, welche die entsprechende Anwendung selbst generiert.
Viele Grüße
Michael