Apache 2.2.14 - Deflate oder GZIP Komprimierung?

[Fred]

Hallo Leute.

Ich würde gerne mal wieder eine Diskussion vom Zaun brechen, was denn nun "besser", schneller ist:

Die Nutzung von mod_deflate oder GZIP?

Liebe Grüße,

Fred

[Alexander (HH)]

Moin Moin!

Ich würde gerne mal wieder eine Diskussion vom Zaun brechen, was denn nun "besser", schneller ist:

"It depends."

Kompression, egal ob deflate oder gzip, funktioniert nicht mit jedem Client, obwohl die Unterstützung zunimmt. Wenn Du *alle* Clients bedienen willst, mußt Du ggf. auf Kompression verzichten. Oder Du verzichtest auf Besucher.

Kompression tauscht Bandbreite gegen Rechenzeit (CPU-Last). Für statische Resourcen kannst Du einmalig vorkomprimieren, für dynamische Resourcen klappt das offensichtlich nicht.

Vorkomprimierte, statische Resourcen auszuliefern spart auf dem Server Bandbreite und Rechenzeit, und bürdet das Auspacken dem Client aus, der meistens genügend Rechenleistung und RAM hat. Willst Du Clients bedienen, die Kompression nicht unterstützen, mußt Du jede Resource doppelt vorhalten, einmal komprimiert, einmal unkomprimiert. Alternativ dazu kannst Du Server-Rechenzeit investieren, um nur eine Variante der Resourcen vorzuhalten und die andere ggf. zu komprimieren oder zu dekomprimieren.

Bei dynamischen Resourcen brauchst Du immer Rechenzeit auf dem Server, um sie zu komprimieren. Damit verlangsamst Du die Auslieferung, sparst aber -- gerade bei schmalbandigen Clients (Modem, GPRS) -- Übertragungszeit.  Bei breitbandigen Clients spart die Auslieferung kaum Übertragungszeit, aber die Antwortzeit wird durch die Kompression erhöht.

Es bleibt also nur: Messen, messen, messen.

Wenn Du Deine Clients (und insbesondere ihre Anbindung ans Internet) nicht kennst, ist keine sinnvolle, eindeutige Aussage möglich, ob Du komprieren solltest oder nicht.

Ob Du nun gzip oder deflate nimmst, hängt hauptsächlich davon ab, was Deine Clients unterstützen und wie viel Arbeit es Deinem Server macht. Deflate ist IMHO geringfügig weniger Aufwand, aber komprimiert nicht ganz so stark wie gzip.

Auch hier ist keine eindeutige Aussage möglich, ob gzip oder deflate zu bevorzugen ist. Es hängt von den Clients und der verfügbaren Rechenleistung des Servers ab.

Alternativ zur Komprimierung wäre auch zu überlegen, Dinge wegzulassen. Google liefert z.B. die meisten Text-Resourcen (HTML, JS, CSS) ohne jeden nicht notwendigen Leerraum aus und verzichtet auf jeden unnötigen Schnickschnack. Das spart pro Aufruf nur ein paar hundert Bytes, aber bei deren Besucherzahlen dürfte das etliche Gigabytes pro Tag sparen.

Alexander

[Fred]

Hi.
Danke für deinen langen Post.

Alternativ zur Komprimierung wäre auch zu überlegen, Dinge wegzulassen. Google liefert z.B. die meisten Text-Resourcen (HTML, JS, CSS) ohne jeden nicht notwendigen Leerraum aus und verzichtet auf jeden unnötigen Schnickschnack. Das spart pro Aufruf nur ein paar hundert Bytes, aber bei deren Besucherzahlen dürfte das etliche Gigabytes pro Tag sparen.

Das ist etwas, was ich nicht verstehe. Wie machen die das, ohne das den Programmierern die Übersichtlichkeit flöten geht?

Gruß, Fred

[Beat]

Alternativ zur Komprimierung wäre auch zu überlegen, Dinge wegzulassen. Google liefert z.B. die meisten Text-Resourcen (HTML, JS, CSS) ohne jeden nicht notwendigen Leerraum aus und verzichtet auf jeden unnötigen Schnickschnack. Das spart pro Aufruf nur ein paar hundert Bytes, aber bei deren Besucherzahlen dürfte das etliche Gigabytes pro Tag sparen.
Das ist etwas, was ich nicht verstehe. Wie machen die das, ohne das den Programmierern die Übersichtlichkeit flöten geht?

Mit Filtern.
Der Produktionscode und der Entwicklercode sind zwei paar Schuhe. Dazwischen stehen dann mehrere Optimierungen.

mfg Beat

[Fred]

Hi Beat.

Mit Filtern.
Der Produktionscode und der Entwicklercode sind zwei paar Schuhe. Dazwischen stehen dann mehrere Optimierungen.

Es wäre superklasse wenn du mir mehr darüber erzählen könntest oder ein paar Links schicken könntest :).

Ich versuche soviel Performance wie möglich herrauszuholen und möchte mich gerne darüber bilden. Leider finde ich nur "guckloch-optimierungen".

Ich verwende PostgreSQL, PHP, XHTML, CSS, JS auf Debian Lenny mit Apache 2.2.14.

Gruß, Fred

[Beat]

Mit Filtern.
Der Produktionscode und der Entwicklercode sind zwei paar Schuhe. Dazwischen stehen dann mehrere Optimierungen.
Es wäre superklasse wenn du mir mehr darüber erzählen könntest oder ein paar Links schicken könntest :).

Ich kenn mich mit der Thematik nicht wirklich aus.
Bei mir kommen Filter zum Zuge, die zum Beispiel sensitive Information aus der Entwicklungsumgebung in anonymisierte Form umbauen.

Würde ich vor der Aufgabe stehen, ein performantes Netz zu erstellen, so würde ich eine Policy aufstellen, dass

• alle Variablennamen in JS
• alle Klassennamen in XHTML
• alle Ids in XHTML

zuerst in einer Datenbank angemeldet werden mit
-Entwicklername
-Produktionsame

bevor sie überhaupt in JS HTML CSS verwendet werden dürfen.
Ausgenommen sind variablen in einem eingeschränkten Scope.

Dadurch ist es dann möglich, den Datenbankgesteuerten Filter zu verwenden.

Vorteil:Lange sprechende Namen der Entwicklerversion
Kurze aber eindeutige Namen Domainweit in der Produktionsversion

mfg Beat

[Alexander (HH)]

Moin Moin!

Alternativ zur Komprimierung wäre auch zu überlegen, Dinge wegzulassen. Google liefert z.B. die meisten Text-Resourcen (HTML, JS, CSS) ohne jeden nicht notwendigen Leerraum aus und verzichtet auf jeden unnötigen Schnickschnack. Das spart pro Aufruf nur ein paar hundert Bytes, aber bei deren Besucherzahlen dürfte das etliche Gigabytes pro Tag sparen.

Das ist etwas, was ich nicht verstehe. Wie machen die das, ohne das den Programmierern die Übersichtlichkeit flöten geht?

Mit Scripten, die aus übersichtlichem Quelltext den unnützen Kram (Leerzeichen, Kommentare, ...) rauswerfen, bevor der Quelltext auf den Webserver kommt.

Siehe z.B. http://dean.edwards.name/packer/ für die grundlegende Technik.

Alexander

[Fred]

Mit Scripten, die aus übersichtlichem Quelltext den unnützen Kram (Leerzeichen, Kommentare, ...) rauswerfen, bevor der Quelltext auf den Webserver kommt.

Siehe z.B. http://dean.edwards.name/packer/ für die grundlegende Technik.

JS und CSS optimierer kenne ich. Allerdings wird das meiste dynamisch per PHP erzeugt.
Und da ein Programm zu finden das 100%ig keine Fehler verursacht und dem ich wenn es geht ein Verzeichnis angebe und es dann alle Dateien darin un Unterverzeichnisse durchsucht und dessen Files optimiert, ist schwer.
Kennst du da eines?

JS und CSS optimiert, das mach ich gnaz zackig über das PageSpeed Plugin von Google für Firefox+Firebug.

Gruß, Fred

[Alexander (HH)]

Moin Moin!

JS und CSS optimierer kenne ich. Allerdings wird das meiste dynamisch per PHP erzeugt.

... und das jedes Mal wieder, für jeden einzelnen Request, obwohl das Ergebnis immer das selbe ist. Es wäre viel sinnvoller, das Zeug einmal vorzuberechnen und dann direkt vom Webserver ausliefern zu lassen, ohne das PHP erst lange daran herumrechnet. Bei einer idealen Kombination von Webserver, Betriebssystem und Konfiguration beider kommt das vollkommen ohne Herumkopiererei der Daten im Speicher aus (zero copy), die Datei wird einmal von der Platte in den Buffer Cache gelesen und von dort direkt, ohne weiteres Theater, vom Betriebssystemkern zur Netzwerkkarte geschaufelt.

Und da ein Programm zu finden das 100%ig keine Fehler verursacht und dem ich wenn es geht ein Verzeichnis angebe und es dann alle Dateien darin un Unterverzeichnisse durchsucht und dessen Files optimiert, ist schwer.

Sauberer Code macht schonmal wesentlich weniger Probleme als wüst zusammenkopiertes und durchverdautes Gerümpel. Verzichtet man dann noch auf haarsträubende Konstrukte im Code, die Browser-Bugs ausnutzen, machen die wenigsten "Diät"-Programme Probleme.

Was das Abarbeiten eines Verzeichnisbaums angeht, das muß das Programm nicht können, dafür gibt es Tools wie find und xargs:

find /some/where -type f -name '*.js' -print0 | xargs -0 js-optimizer

oder, wenn das Programm nur eine Datei zur Zeit kann:

find /some/where -type f -name '*.js' -exec js-optimizer '{}' ;

Kennst du da eines?

Spontan das verlinkte von Dean Edwards und eines, dessen Ausgabe mit der typischen Signator "var p,a,c,k,e,r" beginnt. Google kennt noch einige mehr.

JS und CSS optimiert, das mach ich gnaz zackig über das PageSpeed Plugin von Google für Firefox+Firebug.

Wie wäre es mit Weglassen?

Vergleich mal Googles Startseite (3,5 kBytes HTML/JS/CSS + ein GIF von 8,4 kBytes) z.B. mit der von Metager (25 kBytes HTML + 8 Bilder mit zusammen rund 8 kBytes), ask.com (5,5 kBytes + ca. 8 kBytes Bilder) oder als Gegenbeispiele chip.de (26 kBytes HTML + 65 Bilder mit 250 kBytes + jede Menge JS) und bahn.de (106,5 kBytes HTML + 35 Bilder mit 216 kBytes + jede Menge JS). Von den typischen Anfänger-Webseiten, deren Autoren gerade Javascript, Flash, Java und animierte GIFs im Dreamweaver oder in Frontpage entdeckt haben, will ich jetzt keine an den Pranger stellen, die kennen wir alle zur Genüge, und insbesondere deren Ladezeiten, nicht zuletzt dank clientseitig runterskalierten 10-Megapixel-Fotos.

Alexander