Re: Cache Revalidate
Hello! On Tue, Nov 26, 2013 at 09:07:51PM -0500, S.A.N wrote: Есть досадные мелочи, которые хотелось бы исправить, при включении fastcgi_cache_revalidate on, параметр HTTP_IF_MODIFIED_SINCE, всегда отправляется на сервер, даже если кеша нет, бекенду будет отправлен параметр с пустым значением. По стандартам HTTP при отсутствии кеша, клиент не должен отправлять заголовок If-Modified-Since. Более правильно если Nginx так же как и браузеры, при отсутствии кеша не будет передавать в бекенд пустой хедер If-Modified-Since, т.е нет кеша нет хедера, сейчас приходится в конфиге писать fastcgi_param HTTP_IF_MODIFIED_SINCE $upstream_cache_last_modified if_not_empty; чтобы пустой хедер не приходил, как этого требует стандарт. Да, это имеет смысл поправить. В proxy-то всё нормально, а вот в fastcgi/scgi/uwsgi из-за необходимости местами посылать пустые параметры - теперь уходит пустое значение в HTTP_IF_MODIFIED_SINCE. Патч какой-то такой: # HG changeset patch # User Maxim Dounin mdou...@mdounin.ru # Date 1385558623 -14400 # Wed Nov 27 17:23:43 2013 +0400 # Node ID ca0cde10bf45b5a1d7c0574a1752dcde01b04061 # Parent 19afb15852d2b4c5354a24a2de25a33d5fa77364 Upstream: skip empty cache headers. Notably this fixes HTTP_IF_MODIFIED_SINCE which was always sent with cache enabled in fastcgi/scgi/uwsgi after 43ccaf8e8728. diff --git a/src/http/modules/ngx_http_fastcgi_module.c b/src/http/modules/ngx_http_fastcgi_module.c --- a/src/http/modules/ngx_http_fastcgi_module.c +++ b/src/http/modules/ngx_http_fastcgi_module.c @@ -2796,7 +2796,7 @@ ngx_http_fastcgi_merge_params(ngx_conf_t s-key = h-key; s-value = h-value; -s-skip_empty = 0; +s-skip_empty = 1; next: diff --git a/src/http/modules/ngx_http_scgi_module.c b/src/http/modules/ngx_http_scgi_module.c --- a/src/http/modules/ngx_http_scgi_module.c +++ b/src/http/modules/ngx_http_scgi_module.c @@ -1506,7 +1506,7 @@ ngx_http_scgi_merge_params(ngx_conf_t *c s-key = h-key; s-value = h-value; -s-skip_empty = 0; +s-skip_empty = 1; next: diff --git a/src/http/modules/ngx_http_uwsgi_module.c b/src/http/modules/ngx_http_uwsgi_module.c --- a/src/http/modules/ngx_http_uwsgi_module.c +++ b/src/http/modules/ngx_http_uwsgi_module.c @@ -1670,7 +1670,7 @@ ngx_http_uwsgi_merge_params(ngx_conf_t * s-key = h-key; s-value = h-value; -s-skip_empty = 0; +s-skip_empty = 1; next: Настроить subsecond ревалидацию в Nginx по стандартам HTTP тоже невозможно. Если бекенд отдает заголовок Cache-Control: max-age=0 и/или Expires: -1 Nginx воспринимает их как указания не кешировать ответ, но по стандартам эти заголовки не запрещают кешировать они указывают клиенту что ответ сервера можно кешировать, но он сразу же устаревает и следущий запрос должен пройти ревалидацию, т.е клиент должен каждый запрос отправлять с хедерем If-Modified-Since. Мы нашли способ, как заставить Nginx кешировать такие ответы, отправить ему хедер X-Accel-Expires: @$time-1 Тогда Nginx ведет себя правильно, т.е. так же как браузеры, которым достаточно отправить Cache-Control: max-age=0 Если, есть более красивое решения вместо X-Accel-Expires: @$time-1, хотелось бы его узнать. А use case какой? С учётом характерных времён доступа по http - запрет кеширования даже на 1 секунду выглядит странно. Вообще я склонен думать, что тот факт, что X-Accel-Expires в таком виде работает - это скорее баг. Впрочем, можно его таким и оставить. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Cache Revalidate
27.11.2013 18:06, Maxim Dounin пишет: Вообще я склонен думать, что тот факт, что X-Accel-Expires в таком виде работает - это скорее баг. Впрочем, можно его таким и оставить. ...это скорее баг. Поправим в следующей версии. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Cache Revalidate
А use case какой? С учётом характерных времён доступа по http - запрет кеширования даже на 1 секунду выглядит странно. Есть смысл в кешировании с max-age=0, на страницах где недопустима задержка даже в 1 сек, в отображении актуальных данных, по этому есть смысл кешить, это нормальная практика, вот цифры. Бекенд, генерит страницу за 0,8 сек, проведения ревалидации кеша на бекенде и ответ с кодом 304 занимает по времени 0.01 сек, разница как видите огромная. Если средний rps не меньше хотя бы 10, тогда есть смысл в кешировании таких страниц с постоянной ревалидацией. Если нет других способов заставить Nginx, кешировать как этого требует HTTP стандарты, тогда нужно оставить способ с X-Accel-Expires, даже если это баг :) Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245011#msg-245011 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Cache Revalidate
Hello! On Wed, Nov 27, 2013 at 01:22:46PM -0500, S.A.N wrote: А use case какой? С учётом характерных времён доступа по http - запрет кеширования даже на 1 секунду выглядит странно. Есть смысл в кешировании с max-age=0, на страницах где недопустима задержка даже в 1 сек, в отображении актуальных данных, по этому есть смысл кешить, это нормальная практика, вот цифры. Бекенд, генерит страницу за 0,8 сек, проведения ревалидации кеша на бекенде и ответ с кодом 304 занимает по времени 0.01 сек, разница как видите огромная. Если средний rps не меньше хотя бы 10, тогда есть смысл в кешировании таких страниц с постоянной ревалидацией. Вот и я о том же - если страница генерится 0.8 секунд, то как может быть недопустимым кешировать её на 1 секунду? Откуда взялось требование о недопустимости? Если нет других способов заставить Nginx, кешировать как этого требует HTTP стандарты, тогда нужно оставить способ с X-Accel-Expires, даже если это баг :) У вас какие-то странные представления о http-стандартах. Они вообще ничего не требуют кешировать. Кеш - дело сугубо добровольное. ;) -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
output_buffers по дефолту
Здравствуйте! Ни в документации нив вики не нашел, по дефолту чему равно output_buffers, работает ли директива без aio и directio для линукс? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: output_buffers по дефолту
Hello! On Wed, Nov 27, 2013 at 08:43:24PM +0200, Андрей Василишин wrote: Здравствуйте! Ни в документации нив вики не нашел, по дефолту чему равно output_buffers, работает ли директива без aio и directio для линукс? Default - 1 буфер размером 32k. Директива работает всегда, когда нужно прочитать ответ с диска. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Cache Revalidate
Hello! On Wed, Nov 27, 2013 at 02:30:01PM -0500, S.A.N wrote: Они вообще ничего не требуют кешировать. Кеш - дело сугубо добровольное. ;) max-age=0 не требует кешировать ответ, смысл в том что он не запрещает кешировать ответ, в Nginx max-age=0 запрещает кеширования, в этом и есть не соответвия Nginx с спецификацией HTTP. Повторюсь: несоответствия тут нет, кеш - дело сугубо добровольное. В подавляющем большинстве случаев max-age=0 означает, что кешировать ответ смысла нет, и nginx не тратит лишних ресурсов на то, чтобы этим заниматься. Жаль, что вы с таким упорством отказываетесь рассказать про ваш use case и о происхождении требования о недопустимости кеширования даже на 1 секунду. Возможно, это позволило бы пересмотреть существующее поведение при max-age=0, благо в Cache-Control есть и другие способы запрета кеширования. -- Maxim Dounin http://nginx.org/en/donation.html ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Cache Revalidate
use case и о происхождении требования о недопустимости кеширования даже на 1 секунду. Возможно, это позволило бы пересмотреть существующее поведение при max-age=0, благо в Cache-Control есть и другие способы запрета кеширования. use case продиктован нашей бизнес логикой, мы кешируем все даже страницы для залогиненых пользователей (персонал данные подтягиваются через ajax с использованием клиентского кэширования браузера), в этом есть смысл, цифры я уже писал, разница скорости в генерации страницы и в ревалидации отличается в десятки раз, в пользу ревалидации. Есть сайт с хорошей посещаемостью, залогиненые пользователи имеют возможность общатся, создавать свой контент, редактировать, удалять, есть так же платные сервисы. Наши клиенты не хотят и не должны ждать, даже если это одна секунда, ну например, клиент написал комментарий на сайте, POST ушел на сервер, если у нас кеширования на 1 секунду, мы клиенту не можем сразуже показать новую страницу, должны сделать задержку на 1 сек потом обновить его страницу или как на Хабре все комментарии видны с задержкой и люди это терпят. Конечно мы тоже можем так сделать, но зачем, если скорость ревалидации нам позволяет убрать необходимость в задержках и клиент будет доволен и работать все будет стабильно, главное это сделать совсем не сложно. Сейчас мы это делаем на уровне кеше браузера, с применением ETag, но если Nginx сделает возможность в постоянной ревалидации по ETag, тогда этот алгоритм кеширования который проверен и отлично работает на клиенском кеше браузера мы сможем перенести на кеш Nginx, что во многом увеличит повторное использования кеша, особенно для незалогиненых юзеров. Нам не интересно делать задержки в кеше, представте если бы Facebook делал задержки в отображении, даже если бы на этом форуме были задержки в отображении написанных постов, все бы конечно смерились но это совсем не круто. Есть другой вариант обычно так и делают, не кешируют страницы которые критичны к задержкам и часто обновляются, но это тоже не круто, такие запросы будут нагружать бекенд, время отклика будет падать, очередь запросов к FastCGI будет расти, так до таймаутов осталось не долго. В общем, мы знаем как можно обойтись без постоянной ревалидации, но так же мы знаем как все будет круто, если реализовать постоянную ревалидацию. Почему бы и нет? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245024#msg-245024 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Cache Revalidate
Уточнения, там где контент совсем статичный мы кешируем его на долго без ревалидации. Постоянная ревалидация нам нужна только на динамичном контенте, все написанное выше имеет отношения только к динамичному контенту. Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245025#msg-245025 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Cache Revalidate
А что вам мешает организовать кеш в мемкеше или другом подобном хранилище? Мы у себя так сделали, кеш (на nginx) выключили вообще за ненадобностью. 2013/11/27 S.A.N nginx-fo...@nginx.us use case и о происхождении требования о недопустимости кеширования даже на 1 секунду. Возможно, это позволило бы пересмотреть существующее поведение при max-age=0, благо в Cache-Control есть и другие способы запрета кеширования. use case продиктован нашей бизнес логикой, мы кешируем все даже страницы для залогиненых пользователей (персонал данные подтягиваются через ajax с использованием клиентского кэширования браузера), в этом есть смысл, цифры я уже писал, разница скорости в генерации страницы и в ревалидации отличается в десятки раз, в пользу ревалидации. Есть сайт с хорошей посещаемостью, залогиненые пользователи имеют возможность общатся, создавать свой контент, редактировать, удалять, есть так же платные сервисы. Наши клиенты не хотят и не должны ждать, даже если это одна секунда, ну например, клиент написал комментарий на сайте, POST ушел на сервер, если у нас кеширования на 1 секунду, мы клиенту не можем сразуже показать новую страницу, должны сделать задержку на 1 сек потом обновить его страницу или как на Хабре все комментарии видны с задержкой и люди это терпят. Конечно мы тоже можем так сделать, но зачем, если скорость ревалидации нам позволяет убрать необходимость в задержках и клиент будет доволен и работать все будет стабильно, главное это сделать совсем не сложно. Сейчас мы это делаем на уровне кеше браузера, с применением ETag, но если Nginx сделает возможность в постоянной ревалидации по ETag, тогда этот алгоритм кеширования который проверен и отлично работает на клиенском кеше браузера мы сможем перенести на кеш Nginx, что во многом увеличит повторное использования кеша, особенно для незалогиненых юзеров. Нам не интересно делать задержки в кеше, представте если бы Facebook делал задержки в отображении, даже если бы на этом форуме были задержки в отображении написанных постов, все бы конечно смерились но это совсем не круто. Есть другой вариант обычно так и делают, не кешируют страницы которые критичны к задержкам и часто обновляются, но это тоже не круто, такие запросы будут нагружать бекенд, время отклика будет падать, очередь запросов к FastCGI будет расти, так до таймаутов осталось не долго. В общем, мы знаем как можно обойтись без постоянной ревалидации, но так же мы знаем как все будет круто, если реализовать постоянную ревалидацию. Почему бы и нет? Posted at Nginx Forum: http://forum.nginx.org/read.php?21,244991,245024#msg-245024 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
