Comments 5
Интересно было бы увидеть оценку реального влияния на скорость.
При размере меньше 1KB сжатие дает минимальный эффект, так что лучше сразу выставить min_length на уровне размера MTU. А дальше уже считать время сжатия на сервере и разжатия на клиенте при разных настройках и изменение в количестве передаваемых пакетов. При компрессии выше 6 уже практически не будет разницы по скорости передачи, а затраты на сжатие/расжатие будут расти сильнее.
Подгонять min_length строго под размер MTU - не имеет смысла, т.к. ответ состоит не только из самих сжимаемых данных, но и служебных данных от разного рода протокольных оберток, как тех же HTTP-заголовков, фрейминга, чанков и TLS-записей. В случае с HTTP/2 - все ещё гораздо сложнее, т.к. в один пакет могут паковаться данные сразу от нескольких ответов на разные запросы, а потому там в принципе чем меньше ответы - тем лучше, тем больше их поместится разом.
Скорости компрессии и декомпрессии сильно зависят от вычислительных мощностей на сервере и клиенте, а скорость передачи от пропускной способности канала. Тут нет универсальных решений.
Имелось в виду "min_length ~1KB с учетом размера MTU", что примерно соответствует MTU минус IP/TCP/TLS/HTTP заголовки, т.к. там в сумме набегает ~500B. Что касается HTTP/2, то каждый ресурс сжимается независимо от другого, а агрегация происходит на уровне стрима, так что если ваш ресурс меньше 1KB вы просто потратите процессорное время, а данные будут пересылаться так же как и без сжатия.
В случае с zstd компрессия занимает в разы больше времени чем декомпрессия, что в случае с сервером вполне можно померить, как и пропускную способность. Общий посыл комментария был в том что если уж включать сжатие, то ориентируясь на реальные настройки и показатели конкретного сайта, а не на общие цифры о степени сжатия.
MTU минус IP/TCP/TLS/HTTP заголовки, т.к. там в сумме набегает ~500B.
Открыл `google.com` - он мне выдал заголовков на 1,4 КБ, не даром же сжатие для них начали делать в HTTP/2. У некоторых на сайтах только одних кук на несколько килобайт набирается, какие уж там 500 байт...
каждый ресурс сжимается независимо от другого, а агрегация происходит на уровне стрима, так что если ваш ресурс меньше 1KB вы просто потратите процессорное время, а данные будут пересылаться так же как и без сжатия.
Не очень понял мысль этого заявления. Предположим, что у нас в пакет помещается с учетом всех оберток около 1200 байт ответов. Если каждый ответ по 1Кб в несжатом виде и около 600 Байт в сжатом, то при запросе двух ресурсов - оба они могут поместиться в 1 пакет в сжатом виде или в 2 пакета в несжатом. Поэтому всё же нет, не так же.
Здесь стоит уточнить, что вы говорите только про динамический режим сжатия. При статике чем выше компрессия - тем лучше. Скорость распаковки от степени сжатия практически не зависит. Для динамического сжатия, как и сказано в статье высокие степени (более 6) ставить не следует.
По небольшим файлам (до 1КБ, SVG, JS) сжатие brotli 11 даёт компрессию в 1,5-2 раза, так что эффективность не плохая.
Сжатие текста в Angie: статика, динамика, производительность