Каков нижний порог, чтобы не выполнять сжатие http?

Question

При выполнении http-сжатия существует ли низкий порог, когда рекомендуется не выполнять сжатие?

Очевидно, что для 100 байтов вы не будете сжимать, а для 1 МБ -. Но есть ли общие рекомендации по конкретному низкому порогу?

Answer 1

IBM имеет сравнение , которое также включает график .В соответствии с этим есть также преимущество для сжатия небольших файлов. Другая , хотя в старой статье производительность gzip описывается как хорошая, за исключением локальной передачи файлов.Хотя обе статьи проверяют сжатия в «коммутируемой» среде,

Я думаю, что вопрос более актуален для что сжимать, а не сколько байтов ,Gzip (deflate) обычно подходит для текстовых файлов (html, xml, js и т. Д.), Даже если они размером всего 256 байт, но практически бесполезен при сжатии медиа-файлов или уже сжатых файлов (например, png, jar-s, docx / odt-s и т. д.)

Answer 2

Нет большого вреда в сжатии коротких HTTP-ответов.Они не собираются становиться намного больше, если вообще.Я бы посчитал, что усилия ЦП всегда стоят того, если они экономят полосу пропускания.

Лучшее беспокойство вызывает тип данных.Попытка сжать сжатые двоичные типы файлов, такие как современные форматы изображений и видео, - это пустая трата усилий, тогда как для всего текстового контента это эффективно.

Answer 3

Если вы действительно заботитесь об этом, вам следует сравнить различия в размерах между сжатыми и распакованными реальными файлами в вашем приложении. Начните тестировать самые маленькие файлы, которые вы обслуживаете, и тестировать увеличивающиеся размеры,Посмотрите, где сжатый размер меньше, чем несжатый, и установите его на порог.

Если вы не Google, ¹ , однако, это просто не имеет большого значения.Выберите вменяемое значение.Как звучит 256 килобайт?

---

_{¹ Хорошо, хорошо ... O(Google)}