Bei der HTTP-Komprimierung gibt es einen niedrigen Schwellenwert, bei dem empfohlen wird, keine Komprimierung durchzuführen?
Offensichtlich für 100 Bytes würden Sie nicht komprimieren und für 1 MB würden Sie. Aber gibt es eine generelle Empfehlung zu einem bestimmten niedrigen Schwellenwert?
IBM hat einen Vergleich , der auch ein graph . Demnach gibt es auch einen Vorteil für die Komprimierung kleiner Dateien. Noch ein , obwohl der alte Artikel die gzip-Leistung als gut beschreibt, abgesehen von lokalen Dateiübertragungen. Obwohl beide Artikel Komprimierungen in der Einwahlumgebung überprüfen,
Ich denke, die Frage ist relevanter bezüglich was zu komprimieren ist, anstatt wie viele Bytes . Gzip (deflate) ist normalerweise gut für Textdateien (html, xml, js, etc.), auch wenn sie nur 256 Bytes groß sind, aber nutzlos beim Komprimieren von Mediendateien oder Dateien, die bereits komprimiert wurden (wie png , jar-s, docx / odt-s usw.)
Wenn Sie wirklich daran interessiert sind, sollten Sie die Größenunterschiede zwischen gezippten und unkomprimierten echten Dateien in Ihrer Anwendung vergleichen. Testen Sie die kleinsten Dateien, die Sie bedienen zunehmende Größen. Sehen Sie, wo die gezippte Größe kleiner ist als die unkomprimierte und setzen Sie diese auf den Schwellenwert.
Es sei denn, Sie sind Google, 1 aber es macht einfach keinen großen Unterschied. Wählen Sie einen vernünftigen Wert. Wie klingen 256 Kilobyte?
1 Okay, okay ... O(Google)
Es ist nicht viel schaden, kurze HTTP-Antworten zu komprimieren. Sie werden nicht viel größer werden, wenn überhaupt. Ich denke, der CPU-Aufwand lohnt sich immer, wenn er Bandbreite spart.
Die bessere Sorge ist der Typ der Daten. Der Versuch, binäre Dateitypen wie moderne Bild- und Videoformate zu komprimieren, ist eine totale Verschwendung von Aufwand, während sie für alle Textinhalte effektiv ist.
Tags und Links http compression