nicht angemeldet
Hi Andreas,
Ich wollte meinen provider auch mal dazu bewegen
das zu installieren, aber er hat entschieden
abgeblockt.
meiner auch - deshalb haben Christian und ich ja gzip_cnc geschrieben ...
zum einen vermute ich das Argument das das Sparen
an Traffic für die Kunden zum einen die Traffic-
Einnahmen schmälert,
Das Gegenteil ist der Fall. Der Provider würde dadurch _mehr_ Geld verdienen - wenn er weiß, was er tut.
zum anderen auf Kosten der Performance geht.
Auch das ist nicht der Fall - wenn man mod_gzip mit Bedacht einsetzt.
Natürlich ist es Unfug, beispielsweise GIF-Dateien zu komprimieren, die dabei kaum kleiner und schlimmstenfalls sogar größer werden könnten. Man muß halt wissen, was man erreichen will.
In unserer Serverfarm werden etwa 40% aller Requests komprimiert - aber diese Dateien machen 85% des gesamten Brutto-Traffic aus.
Ich bin mir allerdings bewußt, daß die aktuelle mod_gzip-Version dem Provider keine sinnvolle Möglichkeit gibt, Dir nur einen Teil der Funktionalität von mod_gzip freizuschalten - es gibt keine Bindung von mod_gzip-Direktiven an irgendwelche Berechtigungskonzepte des Apache, beispielsweise an "Options" oder "AllowOverride". Wenn mod_gzip geladen ist, dann darfst Du alles einschalten, was mod_gzip kann.
Er müßte Dir also vertrauen, daß Du eine sinnvolle Konfiguration dafür schreibst. Oder er müßte bestimmte mod_gzip-Direktiven aus dem Quelltext ausbauen.
Vielleicht müßte man die Verwendung von mod_gzip in .htaccess-Dateien verbieten, so daß der Provider dann nach Deinen Angaben ein paar Direktiven in Deinen Virtual Host eintragen müßte. Dann aber wären die Konfigurationen seiner Kunden nicht mehr identisch ...
zumindest letzteres hat er auch gesagt,
denn der Aoache ist für alle Kunden gleich
konfiguriert,
Das würde auch beim Einsatz von mod_gzip mit Konfiguration via .htaccess so bleiben.
Der Provider halt die Wahl: Entweder volle Kontrolle, oder eigene Arbeit. Oder kein mod_gzip.
und wenn die Seiten alle Kunden durch mod_gzip gehen
Wer hat das behauptet? Das wäre weder notwendig noch sinnvoll.
Sorry, aber wenn Dein Provider zu faul ist, meine Dokumentation zu lesen, dann such Dir einen anderen. (Was ich ohne gzip_cnc auch tun würde.)
sei da schon ein erheblicher Performace-Nachteil,
Das ist in dieser Pauschalität auch nicht wahr.
Ein gut konfiguriertes mod_gzip würde die Maschine _schneller_ machen, nicht langsamer.
den man durch zusätzliche Hardware ausgleichen
müßte,
Siehe oben.
des weitern gäbe es bei dynamischen Seiten mit Hilfe
der Ausgabesteuerung Möglichkeiten das dort zu
erledigen
Der Provider ist also unfähig, Dir einen guten Servive zu bieten, und fordert Dich auf, Deine gesamten Seiten auf dynamisch umzustellen und _dadurch_ massiv (!) zusätzliche Last auf seinen (!) Server zu bringen?
Weiß dieser Provider eigentlich, was er da sagt?
Was immer Du selbst programmieren könntest - so performant wie mod_gzip kriegst Du das nicht hin.
Du kannst natürlich gerne das tun, was er Dir vorschlägt (nämlich gzip_cnc einsetzen) ...
und bei statischen Seiten die Möglichkeit mit
multiview je eine .html.gz und eine .html in einem
Cache-Verzeicnis zu speichern und entsprechend dem
Request-Header auszuliefern.
Ja. Aber genau das kann mod_gzip natürlich auch, und _viel_ besser.
Beispielsweise müßtest Du Deine .gz-Dateien manuell aktualisieren, wenn ihr Inhalt veraltet ist - mod_gzip würde das automatisch erkennen - und mod_gzip 1.3.26.1a würde Deine .gz-Dateien automatisch aktualisieren!
Und außerdem müßtest Du bei normaler Negotiation alle Deine Links anpassen, wie Sven richtig angemerkt hat. mod_gzip würde Dir das ersparen - und gzip_cnc ebenfalls.
Was meinst Du dazu?
RTFM. Am besten beide.
Viele Grüße
Michael