On Mon, 11 Oct 2004, Nick S. Knutov wrote:
> Смотрю пример конфигурации.
>
> gzip_min_length 1300;
>
> Почему именно эта цифра?
Цифра должна быть на самом деле 1100. Исправлю.
Логика тут такая. При сжатии расходуется достаточно много памяти -
при стандартных настройках около 260К. Если для ответа известна
Content-Length, и она в районе 8K-16K, то 120K. Для 4K-8K - 60K.
1100 байт тела + примерно 360 байт заголовка, как правило, помещаются
в один IP-пакет (~1460 байт на эзернете), то есть, и сжатый, и несжатый
ответ уйдут в одном пакете.
> gzip_buffers 4 8k;
>
> Что означает первая и вторая цифра?
Для сжатия будут использоваться до 4 буферов по 8К каждый.
Буфера выделяются только по мере необходимости.
> gzip_types text/plain;
>
> А это что означает? То, что надо сжимать, или что? Т.е. при такой
> конфигурации не будет сжиматься text/html например?
text/html сжимается всегда, независимо от настройки gzip_types.
gzip_types позволяет добавить ещё типов.
> client_max_body_size 10m;
> Это размер максимального ответа? Т.е. если у меня должны
> отдаваться файлики по 700 метров то должно быть соответсвующее
> исправление?
Нет, это размер того, что клиент может влить в POSTе.
Больше будет ошибка 416.
> Есть ли ограничения на максимальный размер отдаваемых файликов?
Ограничения нет. Единственно, на Линуксе без sendfile64, но с поддержкой
файлов больше 2G не будут отдаваться файлы больше 2G.
> Да, кстати, как оно реагирует в том случае, если включено сжатие,
> а у апача стоит mod_deflate и он тоже сжимает. Что будет в этом
> случае?
Сейчас тоже сжимает. Будет исправлено. Единственно, почему может работать
с включённым mod_deflate на бэкенде - если mod_deflate сжимает только HTTP/1.1.
nginx пока ходит к бэкенду по HTTP/1.0.
Игорь Сысоев
