Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gzip и ETag
Если Expire уже правильный, то для динамического контента вы все равно
сгенерируете страницу (независимо от ETag-ов), а за статическим
контентом браузер второй раз не придет.
то есть проблем нет вообще никаких. наличие ETag-а (или его
отсутствие) роли не играют.
да, компоновщиков статики много. и они делают примерно одно и то же.
делают весьма хорошо.
8 мая 2013 г., 17:58 пользователь Anatoly Mikhailov <anatoly@xxxxxxxxx> написал:
>
> On May 8, 2013, at 12:50 PM, Илья Шипицин <chipitsine@xxxxxxxxx> wrote:
>
>> это бред, бред и еще сто раз бред.
>
> ответ в пустоту, не забывайте указывать контекст
>
>>
>> если вы точно уверены, что контент кешируемый, добавляете на него
>> Expire (или max-age, как нравится) и у браузера уже есть копия
>> контента, про которую он точно знает, что она актуальна. в этом случае
>> браузер начинает отрисовывать страницу сразу же.
>>
>> если вы знаете, что контент неизменяемый, но не отдали Expire, то у
>> браузера есть некая копия контента, про которую он не уверен. Он
>> сделает ЛИШНИЙ запрос (это время) с заголовком
>> If-Modified-Since/If-None-Match и только после этого начнет
>> отрисовывать страницу.
>>
>> и в каком месте здесь "UI responsiveness" ?
>>
>>
>> чем гоняться за ETag-ами, лучше сделать правильный Expire.
>>
>
> Expire уже везде правильный
>
>>
>>
>> генерация уникальных имен для CSS делается на стороне приложения. это
>> проработанная тема, если у вас Ruby On Rails, например, вот так
>> http://code.google.com/p/bundle-fu/
>
> Assets Pipeline делает тоже самое
>
>>
>>
>> да, идея простая - уменьшить количество запросов и сделать уникальный
>> хеш для статических сборок.
>>
>>
>> необязательно вообще всё навешивать на nginx.
>>
>>
>>
>> 8 мая 2013 г., 17:21 пользователь Anatoly Mikhailov <anatoly@xxxxxxxxx>
>> написал:
>>>
>>> On May 8, 2013, at 11:49 AM, Илья Шипицин <chipitsine@xxxxxxxxx> wrote:
>>>
>>>> расскажите более подробно про сценарии, когда необходим именно ETag ?
>>>>
>>>
>>> ETag необходим тогда, когда вы точно уверены, что ответ от сервера кэшируем
>>> и нет необходимости генерить его заново, когда ваш бэкэнд уверен в этом
>>>
>>>> по моим наблюдениям большинство браузеров используют
>>>> If-Not-Modified-Since, и небольшая часть - одновременно
>>>> If-Not-Modified-Since и ETag.
>>>
>>> эти вещи не жестко связаны, вы можете использовать либо то, либо другое,
>>> либо оба вместе, наипростейшая схема работы описана здесь
>>> http://www.youtube.com/watch?v=Eq3E6ahEk4k
>>>
>>>>
>>>> с другой стороны, если контент заведомо статический, отдаем его с
>>>> "Cache-Control: max-age=много-много" и избавляемся от 304-х кодов
>>>> почти полностью.
>>>
>>> для статики это лучший вариант, для динамики - на усмотрение
>>>
>>>>
>>>> какой великий смысл в том, чтобы отдать статику, не указав при этом
>>>> длинный Expire (или max-age), чтобы браузер делал лишний запрос "не
>>>> обновилась ли картинка/стиль/скрипт" ?
>>>
>>> никакого, статика вся должна ложиться в браузерный кэш и не привлекать
>>> эвристический анализ
>>>
>>>>
>>>> если вы добиваетесь именно "UI responsiveness", логично вообще
>>>> избавляться от If-None-Match/If-Not-Modified-Since запросов, благо это
>>>> не так сложно.
>>>
>>> это не так, ответ 304 избавляет бразузер от рендеринга, если вы точно
>>> уверены,
>>> что ничего нового нет
>>>
>>>>
>>>> 8 мая 2013 г., 16:18 пользователь Anatoly Mikhailov <anatoly@xxxxxxxxx>
>>>> написал:
>>>>>
>>>>> On May 8, 2013, at 10:34 AM, Maxim Dounin <mdounin@xxxxxxxxxx> wrote:
>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote:
>>>>>>
>>>>>>>
>>>>>>> On May 8, 2013, at 12:23 AM, Maxim Dounin <mdounin@xxxxxxxxxx> wrote:
>>>>>>>
>>>>>>>> Hello!
>>>>>>>>
>>>>>>>> On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote:
>>>>>>>>
>>>>>>>>> Меня настораживает интересная закономерность, включая/отключая gzip в
>>>>>>>>> конфигурации Nginx,
>>>>>>>>> ETag заголовок пропадает/появляется соответственно в прокированном
>>>>>>>>> ответе от бэкэнда (Unicorn).
>>>>>>>>> Проще говоря, при gzip off ответ всегда приходит с ETag, все
>>>>>>>>> остальные параметры на это не влияют.
>>>>>>>>>
>>>>>>>>> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет
>>>>>>>>> заголовок ETag к каждому ответу,
>>>>>>>>> и чтобы проксировать ETag заголовок через upstream приходится
>>>>>>>>> выключать gzip.
>>>>>>>>> Если я правильно понимаю, то сжатый ответ не может содержать
>>>>>>>>> некоторые заголовки?
>>>>>>>>
>>>>>>>> При любых изменениях тела ответа, в том числе - модулем gzip,
>>>>>>>> ETag'и из ответа убираются. Это сделано, т.к. стандарт требует,
>>>>>>>> чтобы strong etags у ответов совпадали тогда и только тогда, когда
>>>>>>>> ответы совпадают до байта. (А если ответы будет не совпадать при
>>>>>>>> одинаковых ETag'ах - это в свою очередь чревато получением
>>>>>>>> неверного суммарного ответа при комбинировании нескольких ответов
>>>>>>>> на range-запросы.) Почитать подробности можно тут (и далее по
>>>>>>>> ссылкам):
>>>>>>>>
>>>>>>>> http://tools.ietf.org/html/rfc2616#section-3.11
>>>>>>>>
>>>>>>>
>>>>>>> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять
>>>>>>> ETag, пришедший от бэкэнда,
>>>>>>> может в сочетании с Last-Modified?
>>>>>>
>>>>>> В чём цель?
>>>>>
>>>>> Цель всегда одна - UI responsiveness, чем быстрее пользователь получит
>>>>> данные (идеально - из браузерного кэша),
>>>>> тем меньше нагрузки будет на рендеринг в браузере и можно отдать пустое
>>>>> тело запроса от бэкэнда (fresh_when/stale в Rack)
>>>>>
>>>>> E-Tag, Last-Modified - весьма удобные инструменты, которые неожиданно
>>>>> перестали работать как раз после Nginx 1.3.3 :)
>>>>>
>>>>>>
>>>>>>> Кстати, до реализации SPDY все было точно так же (ETag не проксировался
>>>>>>> при Gzip)?
>>>>>>
>>>>>> Поддержка entity tags не имеет отношения к spdy, и появилась в
>>>>>> nginx 1.3.3. До этого nginx не знал про заголовок ETag и ничего с
>>>>>> ним не делал.
>>>>>>
>>>>>> --
>>>>>> Maxim Dounin
>>>>>> http://nginx.org/en/donation.html
>>>>>>
>>>>>> _______________________________________________
>>>>>> nginx-ru mailing list
>>>>>> nginx-ru@xxxxxxxxx
>>>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>>>
>>>>> _______________________________________________
>>>>> nginx-ru mailing list
>>>>> nginx-ru@xxxxxxxxx
>>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>> _______________________________________________
>>>> nginx-ru mailing list
>>>> nginx-ru@xxxxxxxxx
>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru@xxxxxxxxx
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru@xxxxxxxxx
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|
