gzip_static timecheck

[Gena Makhomed]

On Tuesday, April 7, 2009 at 16:15:45, MZ wrote:

>> другой вариант - в proxy_cache сохранять уже сжатый через gzip контент.
>> тогда не нужно будет делать ручного создания *.gz файлов и не нужно
>> будет заботиться о совпадении mtime у исходного и сжатого файлов.

>> преимущества: кеш на диске будет занимать меньше места,
>> операции дискового ввода/вывода будут занимать меньше времени,
>> не нужно будет заново сжимать файлы из кеша для 80-90% запросов,
>> mtime исходного файла не будет проверяться для каждого запроса.

>> gzip_static - это тот же кеш, только создается и обновляется он вручную.

M> Хороший вариант, но не уверен что это надо микшировать это с proxy_cache.

для proxy_cache от автоматического сжатия содержимого кеша
я вижу одни только преимущества (см. выше), и ни одного недостатка.

M> Может указывать отдельную папку кеша параметром для gzip_static?

сжимать через gzip имеет смысл динамический контент (text/html, text/css),
а статика - файлы png, jpg, iso, avi, и т.п., - обычно отдается as-is.

gzip_static может быть полезен только для раздачи *.html статики
и на винте при этом можно хранить только *.gz файлы, без исходных.

M> Или сразу ввести директиву gzip_cache, в которой можно будет
M> это настроить, в т.ч. и для закешированных проксированых файлов?

если в сжатии кеша нет недостатков и есть только одни преимущества
- зачем эту возможность делать настраиваемой? по крайней мере,
дисковый i/o станет узким местом машины раньше чем процессор.

PS хотя *.css-файлы - это обычно статика, отдается через nginx
напрямую, но с другой стороны - лежит на винте в не-сжатом виде.
в этом случае действительно был бы полезен отдельный gzip_cache.

-- 
Best regards,
 Gena