Для инвалидации кеша, мы планировали использовать такую схему:
fastcgi_cache_valid 200 … 1s;
fastcgi_cache_use_stale error updating http_503;
По истечения 1 секунды, запрос будет идти на бекенд, на котором РНР скрипт
определяет изменились данные в БД которые использовались в данном URI с
момента
Можно где-то подробней почитать, про новые возможности для инвалидации
кеша?
If-Modified-Since - работает по дате, это хорошо, но для полноты
возможностей, нужна поддержка ETag, но все равно спасибо вам, приятно видеть
что идет прогресс в этом направлении.
Posted at Nginx Forum:
Отличия ETag от Last-Modified, в формате значений, в ETag произвольный
формат и многие разработчики это используют для передачи хеш состояний
ответа, некоторые даже используют значения ETag для передачи серелизированой
строки в которой хранится состояния ответа.
Это удобный и гибкий способ,
Если в нашей дискуссии есть практический смысл (реализация Etag в ближайших
версия).
Я могу много рассказать про невозможность использовать Last-Modified для
ревалидации.
Реальный пример из жизни, у нас есть страница товара, ниже выводим
комментарии пользователей, хедер страницы Last-Modified –
Проблем с HTTP/1.0 не будет в принципе, бекенд не работает на прямую с
клиентом по HTTP/1.0, бекенд работает с Nginx, который в свою очередь должен
передать HTTP_IF_NONE_MATCH взятым из файла кеша Nginx, бекенд проведет
ревалидацию и ответит 304 или 200 с контентом страницы, клиент получит ответ
Есть досадные мелочи, которые хотелось бы исправить, при включении
fastcgi_cache_revalidate on, параметр HTTP_IF_MODIFIED_SINCE, всегда
отправляется на сервер, даже если кеша нет, бекенду будет отправлен
параметр с пустым значением.
По стандартам HTTP при отсутствии кеша, клиент не должен
А use case какой? С учётом характерных времён доступа по http -
запрет кеширования даже на 1 секунду выглядит странно.
Есть смысл в кешировании с max-age=0, на страницах где недопустима задержка
даже в 1 сек, в отображении актуальных данных, по этому есть смысл кешить,
это нормальная
use case и о происхождении требования о недопустимости кеширования
даже на 1 секунду. Возможно, это позволило бы пересмотреть
существующее поведение при max-age=0, благо в Cache-Control есть и
другие способы запрета кеширования.
use case продиктован нашей бизнес логикой, мы кешируем все
Уточнения, там где контент совсем статичный мы кешируем его на долго без
ревалидации.
Постоянная ревалидация нам нужна только на динамичном контенте, все
написанное выше имеет отношения только к динамичному контенту.
Posted at Nginx Forum:
- Добавлять комментарий без перезагрузки страницы javascript'ом,
отправлять на сервер - через ajax. Так, насколько я понимаю,
сейчас делают чуть менее, чем все, в том числе упоминаемый вами же
facebook.
Я же написал, что мы знаем как можно работать с задержками, но зачем это всё
Извините что вклиниваюсь, но это полная победа разума над логикой.
А идти вразрез с логикой правильно только в алгоритмах защиты, дабы
спутать
врага.
Я же не настаиваю на этом решении, это уже вам решать.
Если интересно как юзается max-age=0 для кеширования, далеко ходить не надо,
Google в
Роман Москвитин Wrote:
---
Кому как, мне вот только что ответил двухсоткой. Несколько раз.
Различный
контент пошел уже с 304, но там и max-age далеко не ноль.
Про использование кук и прочих ETag я ничего не говорил, но
кеширование при
SEO по общему использованию кукисов на двух разных бакэндах при общем
главном домене.
На главном домене, отдавайте куки с параметром domain .example.com
Тогда куки будут видны всем подоменам *.example.com
С аяксом тоже есть решения
Просто на отдельном домене у вас будут полностью развязаны руки
если ревалидация не проходит - элемент кеша не будет
удалён/заменён, а будет продолжать использоваться для других
пользователей.
Если у клиента нет прав доступа, он получает статус 403, если есть
права получает – 200 или 304.
Если бекенд не отвечает, Nginx отдает 504, никаких
# Ключ по которому сохраняются и берутся
данные из кеша
proxy_cache_key
$request_method|$http_if_modified_since|$http_if_none_match|$host|$re
quest_uri;
Стоит подумать про оптимизацию proxy_cache_key, у вас в ключе есть лишние
переменные -
Вам правильно ответили, в первую очередь нужно читать документацию.
Возможно вы удивитесь но ваш конфиг по кешированию может и должен выглядить
намного короче, как-то так
fastcgi_cache_lock on;
fastcgi_cache_revalidate on;
fastcgi_cache_methods GET HEAD;
fastcgi_cache_valid 200 301 302 0s;
Заметили очень неприятный баг, в результате которого, клиенты получали
пустую страницу.
Конфиг кеширования:
fastcgi_cache_path cache levels=1:2 keys_zone=cache:256m inactive=1d;
fastcgi_cache cache;
fastcgi_cache_lock on;
fastcgi_cache_revalidate on;
fastcgi_cache_methods GET HEAD;
В принципе можно сделать чтобы бекенд на публичный кеш (public) не отдавал
ETag, на приватный кеш (private) отдавать хедер ETag, чтобы можно было по
нему ревалидировать.
По идеи это временное решения, когда Nginx сделает поддержку ETag можно
будет снова его в включить в публичный кеш.
Posted at
поддержка E-Tag в Nginx была всегда, как минимум в виде трансляции
заголовка с бэк-енда. С версии 1.3.3 Nginx научился ее
включать/выключать
http://nginx.org/en/docs/http/ngx_http_core_module.html#etag
Не забывайте, что еще есть разница между weak/strong E-Tag,
согласно RFC
Если вы хотите, чтобы оно работало так, то надо включить в ключ
кеширования заголовок If-None-Match - т.к. от него зависит ответ
бекенда.
Нет, так делать не надо, потому что на один uri может быть только один
актуальный ETag, новые значения ETag означают обязательную инвалидацию всех
Тогда возвращаемся к ответу Максима. Все - то есть, абсолютно -
параметры, от которых зависит или может зависеть ответ бекенда,
должны быть включены в ключ кеша.
Я не понимаю, как добавления в ключ кеша хедера if_none_match, может решить
проблему, автоматического удаления из запроса к бекенду
О рассинхронизации клиентского кеша и кеша nginx. У клиентов файл в
кеше, в nginx кеше его нет - и мы имеем 304 закешированным (потому,
что специально разрешили кешировать 304).
А как ведет себя fastcgi_cache_valid 0s
Вот кофиг
fastcgi_cache cache;
fastcgi_cache_lock on;
блоги на каком движке написаны?
Блоги - это один из модулей, нашего самописного фреймворка.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,245951,246034#msg-246034
___
nginx-ru mailing list
nginx-ru@nginx.org
fastcgi_cache_key $host$uri$is_args$args;
Это ни разу ни баг - это вы недонастроили.
Добавьте в ключ кеширования параметр
$http_if_modified_since
и наступит вам счастье.
Я наверно не доступно объяснию суть проблемы.
Попробую объяснить на пальцах :)
Есть uri
/user/bar
Отдает контент
передавать на backend заголовки If-Modified-Since и If-None-Match
или нет - это тоже можно настроить по разному для разных location`ов.
Да, согласен, но этот вариант очень не хочется реализовывать, довольно
большой перечень location придется указывать в конфиге Nginx, это уже
жесткий хардкор,
перечитал RFC, к числу hop-by-hop хедеров они не относятся,
получается, их надо всегда передавать на бекенд?
Да, эти заголовков при прозрачном проксировании передаются без изменений, к
сожалению Nginx самостоятельно удаляет эти заговолки при включенном Nginx
кешировании, я понимаю почему он
так что Ваш вариант
fastcgi_cache_methods GET HEAD;
fastcgi_cache_key $host$uri$is_args$args;
не оптимален, включает $uri$is_args$args вместо $request_uri
и даже ошибочен, потому что не включает в себя $request_method.
HEAD кэширует ответ с телом, отдаёт - без.
Не хотел обидеть автора
Отдает контент с заголовками
Cache-Control: private, max-age=0
если было бы Cache-Control: private, вроде как было бы то же самое,
нет ? на 10 символов короче.
Можно не указывать max-age=0, по спецификации если не указан max-age он
равен нулю, но есть такие клиенты как Opera, у неё
Торг здесь не уместен. Можно написать статью и без ревалидации по
ETag.
Как реализовать ревалидацию по ETag, если его просто не будет у части
клиентов. В кеше ведь всегда находится только один вариант контента -
или сжатый gzip, или uncompressed. А в кешах у клиентов - в общем
случае
Кстати, похоже, что есть вариант еще проще, используя директиву
fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match
и выставляя в ответе заголовок X-Accel-Expires: 0
если статус ответа backend`а будет 304.
Да, у меня крутился в голове вариант, использовать куки для
Gena Makhomed Wrote:
---
возможно имеет смысл дефолтовые настройки сделать такими,
чтобы они были безопасными по-умолчанию для всех пользователей?
т.е. $host вместо $proxy_host ?
Поддержу данную мысль, это добавило бы безопасности дефолтного
0 строчек кода - это невозможно.
Все возможно, я выше писал, как я решил эту проблему.
В конфиге по прежнему для работы с клиент кешем, установлена передача все
нужных заголовком.
fastcgi_param HTTP_IF_NONE_MATCH $http_if_none_match if_not_empty;
fastcgi_param HTTP_IF_MODIFIED_SINCE
Коллизии возможны только в одном случае: программист не проверяет
данные,
получаемые от клиента, и такому программисту никаким костылями не
поможешь.
Проверять на бекенде значения Host не рационально, если в конфигурации
server указан только один домен.
Если следовать вашей логике тогда,
Хочу уточнить, я не предлагаю полную аналогию с UseCanonicalName, я имел
виду использовать значения переменной $host, при условии что host из
absoluteURI отличается от значения клиентского заголовка Host.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,246086,246275#msg-246275
Для убедительности, приведу ещё такой пример.
Есть бекенд приложения, которое обслуживает множество хостов, всех этих
хостах fastcgi_pass одинаковы, роутинг внутри приложения осуществляется по
HTTP_HOST, дело в том, что использовать для роутинга SERVER_NAME, часто
невозможно по ряду причин.
Проблема в том, что периодически, раз в 10-20 секунд nginx подгружает
диск записью на 2-5 секунды, изза этого случается лаг и например ответ
от веб сервера можно ждать несколько секунд.
Возможно это результат процесса “cache manager” и/или cache loader
Почитать можно здесь
Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не
препятствовало основному проксированию ответа
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,246604,246613#msg-246613
proxy_cache_key $host$uri;
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,247093,247095#msg-247095
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Стесняюсь спросить, в какой версии планируется реализацию ревалидации по
ETag? :)
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,247148,247171#msg-247171
___
nginx-ru mailing list
nginx-ru@nginx.org
Вы прислали FCGI_END_REQUEST, ничего не вернув клиенту, о чём
nginx и плачет. Единственное, что он в данном случае может
сделать - это вернуть клиенту ошибку.
Это происходит только при выключенном fastcgi_keep_conn и keepalive,
если их
выключить Nginx отлично отдает 200 статус
Gena Makhomed Wrote:
---
и да, отвечать с 400 статусом тут даже более логично,
потому что если authority component в строке запроса
и в заголовке Host: разные - это явно попытка взлома.
Я так же считаю, что 400 статус в этом случаи должен
Maxim Dounin Wrote:
---
Какая-либо проблема появляется тогда и только
тогда, когда администратор начинает писать в конфиге $http_host,
не думая о последствиях. Есть мнение, что совсем простое решение
этой проблемы - не делать так (c)
Maxim Dounin Wrote:
---
Какая-либо проблема появляется тогда и только
тогда, когда администратор начинает писать в конфиге $http_host,
не думая о последствиях. Есть мнение, что совсем простое решение
этой проблемы - не делать
Илья Шипицин Wrote:
---
а расскажите на примерах, как эту уязвимость можно эксплуатировать?
Вариантов эксплойтов очень много:
1. SQL иньекции, когда содержимое HTTP_HOST без экранирования используется в
SQL запросах.
2. Хаки в include path,
Илья Шипицин Wrote:
---
а чем опасен пункт 3) ?
мне почему-то кажется, что масштаб бедствия в районе нуля, шум из-за
ничего.
ну ок, в nginx сработал конфиг для одного значения Host, на бекенд
улетело другое, что в этом случае может
Maxim Dounin Wrote:
---
Возможно, когда-нибудь мы и придём к тому, что в таких ситуациях
будет возвращаться 400. Но это ни коим образом не избавляет от
необходимости исправить приложение.
Приведенный мной пример немного утрирован, но взят
Илья Шипицин Wrote:
---
пока что все озвученные сценарии для пользователя приведут к
400/404/200, ну то есть назло маме отморожу уши.
ну ок, пользователь специально сконструировал такой запрос, чтобы он
попал в другой хост. ему там ответили
Валентин Бартенев Wrote:
---
Как уже неоднократно в этой ветке говорилось, nginx в параметрах
HTTP_* пишет
ровно то, что от него требуется: заголовки, пришедшие от клиента, в
том виде,
в котором они получены.
Nginx так и должен делать, если
Валентин Бартенев Wrote:
---
Вы подменяете понятия. Пока ещё никто из дискутирующих не смог
привести
аргументов за то, что такие запросы не являются валидными.
Я никогда не утверждал, что инвалидность этих запросов определяется
стандартом
Сегодня, Максим опубликовал патчи которые реализуют указанный функционал,
это очень хорошая новость.
http://forum.nginx.org/read.php?29,251168
Я так понимаю это финальный код, который войдет в версию Nginx 1.7.3?
Так же добавлена возможность использовать не строгие ETag, что тоже очень
хорошо...
Добавление: ревалидация элементов кэша теперь, если это возможно,
использует заголовок If-None-Match.
Отлично, спасибо!
Когда появится данная версия в ваших пакетах для CentOS 6?
В http://nginx.org/packages/mainline/centos/6/ её ещё нет.
Кстати можно уже создавать новую папку
proxy_storeon;
Может, лучше сделать через кеширования а не дублирования контента?
Вот что вам нужно
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_valid
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251675,251680#msg-251680
но картинки так кэшировать не
получилось.
У вас картинки, хранятся в файлах на том же винте где работает Nginx?
Если да, тогда нет смысла их сохранять в локал файлы, по сути будет тоже
самое.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251675,251683#msg-251683
proxy_cache, полностью сохраняет HTTP ответ от проксированого сервера, в
локал файл и следующие запросы отдает из этого локал файла.
Но если у вас картинки и так лежат на том же винте в той же файл системе,
тогда нет никакого смысла их копировать в другую папку, потому что скорость
отдачи будет
Но если у вас картинки и так лежат на том же винте в той же файл
системе, тогда нет никакого смысла их копировать в другую папку,
Это я понимаю, просто нет возможности отдавать их напрямую nginx.
proxy_cache даст такую же скорость, как и proxy_store ?
Просто мне ещё нужно будет выборочно
Спасибо за советы, а как это будет происходить?
Если я например поменял только один файл js. То как nginx узнает, что
нужно его обновить в кэше?
Получается, что nginx постоянно будет делать запрос к проксированному
серверу и спрашивать его заголовки If-Modified-Since” и
“If-None-Match”?
Если я правильно понял, то придёт запрос на статику к nginx он его
отправит к Apache, Apache сделает запрос заголовка Last-Modified,
добавит к нему max-age=1 и тогда nginx будет повторять эту цепочку
каждую секунду.
По-моему слишком закручено, для такой задачи.
Nginx, будет делать запрос к
Статика находится в самом приложении и достать в отдельную директорию
её нельзя. Поэтому ищу решения с кэшем nginx.
Тогда все нормально, вам просто нужно настроить механизм кеширования в
Nginx, если ваше приложения общается с Nginx по HTTP тогда Apache конечно
ненужен.
Posted at Nginx Forum:
Заголовки запроса не так интересны, вы напишите здесь, HTTP заголовки ответа
от вашего приложения.
И назначите такой ключ для кеша
proxy_cache_key $host$uri$is_args$args
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251675,251701#msg-251701
Budulianin Wrote:
---
Ваш ключ недопустим, поставил такой proxy_cache_key
$scheme$proxy_host$uri$is_args$args;
Страно, у меня fastcgi_cache_key стоит $host$uri$is_args$args и все норм
Ответ:
Cache-Control:max-age=5184000
Спрятать Pragma:no-cache, можно директивой proxy_hide_header
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_hide_header
Так с кешем все нормально, все что нужно кешится?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251675,251705#msg-251705
В итоге без этой строчки не работает proxy_ignore_headers
Cache-Control;
Похоже, приложение говорит так nginx не кешить и он не кэшит.
А эта строчка игнорирует заголовок и nginx кэшит.
Да, так и есть.
А как проверить, что именно из кэша отдаётся статика, а не к
приложению идёт запрос?
Поставил, вырубил приложение, на главной странице 502, а статика
отдаётся, прикольно.
Так может быть, есть смысл и все остальные страницы кешировать, опыт у вас
уже есть.
Мне ещё нужно рассмотреть вариант хранения кэша в памяти.
Если я каталог в который nginx пишет, просто монтирую в память,
Просто я пока не знаю других способов, кроме как монтировать в память,
но может они есть?
Если у вас SSD, или отдача статика происходит за 5-15ms, смысла забирать
память под статику я особо не вижу, лучше её отдать приложению и/или БД, но
опять же проведите нагрузочное тестирования с макс
Если приложения отдает заголовок Last-Modified, он сохраняется в кеше, его
значения можно получить в заголовке If-Modified-Since или в конфиге Nginx
переменная $upstream_cache_last_modified.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251724,251726#msg-251726
Да, это дата модификации контента, она может и не быть равна дате создания
кеша, зачем вам именно дата создания кеша?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251724,251729#msg-251729
___
nginx-ru mailing list
nginx-ru@nginx.org
Cache-Control: max-age=сколько секунд, кеш считается валидным, после
истечения этого времени проводится ревалидации
Expires: GMT дата, после истечения этой даты проводится ревалидации
Pragma - это костыльный заголовок который вообще не стоит использовать для
кеширования
Материал для обучения
Budulianin Wrote:
---
Pragma - это костыльный заголовок который вообще не стоит
использовать для кеширования
Он для HTTP 1.0
Костыльность Pragma, заключается в том что это заголовок запроса а не
ответа, потом его начали использовать как
Nginx 1.7.3, отличная версия, в ней полностью решен вопрос с ETag.
Но есть мелочи которых очень не хватает, их всего две )
1. Нельзя получить от клиента валидаторы (“If-Modified-Since” и
“If-None-Match”) если файла кеша нет, эта ситуация возникает когда бекенд
отдавал заголовки Cache-Control:
Я хочу принять ответ от uwsgi,
добавить в него пару заголовков и отдать клиенту.
Фактически добавить заголовки в ответ nginx.
Я таким образом хочу управлять кэшем.
Вы таким образом сможете управлять только кешем браузера, если хотите
управлять кешем Nginx, нужно чтобы ваше приложения отдавала
Да, директивы uwsgi_cache_valid для этого и придумали, чтобы управлять
кешированием, если бекенд приложения не может самостоятельно отправить
правильные заголовки.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251763,251788#msg-251788
___
Budulianin Wrote:
---
Зачем вы выбрали такое значения Cache-Control: max-age=600 no-cache?
Этой строчкой я хотел сказать браузеру: держи у себя кэш 600 секунд,
но при каждом запросе отправляй заголовки(видимо If-modified-since)
Потому что
Нет, на протяжении 600 секунд, браузер НЕ БУДЕТ делать запрос к серверу
вообще, потому что вы ему сказали, что кеш можно использовать без
ревалидации на протяжении 600 секунд.
После истечения 600 секунд, браузер сделает запрос к серверу, передаст ему
If-Modified-Since, Nginx сравнит значения
Budulianin Wrote:
---
В этом случаи приложения должно уметь очень быстро проверять
If-Modified-Since с текущим Last-Modified, если они равны отдавать
304, если нет отдавать новый контент и статус 200.
Под это нужно специально готовить
Budulianin Wrote:
---
Нет, на протяжении 600 секунд, браузер НЕ БУДЕТ делать запрос к
серверу вообще, потому что вы ему сказали, что кеш можно использовать
без ревалидации на протяжении 600 секунд.
А у меня запросы идут к nginx, те
Эта схема защитит ваше приложения от нагрузки, но она никак не сможет
актуализировать кеш быстрей чем это указанно в max-age.
Я же сказал, что мы можем чистить кэш nginx когда нам это нужно.
Если у вас есть сторонний процесс который чистит кеш, тогда конечно можно
использовать эту схему.
Значит моя схема вполне жизнеспособна и не выглядит нормально? Кладём
основную нагрузку на nginx и немного на браузер.
Я думаю да, но лучше проконсультироватся у разработчиков Nginx, как
реагирует Nginx если кеш файлы исчезают, без его ведома, я думаю он
нормально реагирует, но мало ли какие
те кто обновляет страницу в ручную будут получать 304 статус без
контента,
Только если в запросе, который должен закэшироваться, был
заголовок-валидатор(ETag, Last-Modified) иначе нечего будет
сравнивать.
У меня сейчас нет их и nginx отдаёт 200.
С этого и надо было начинать, они нужны
Budulianin Wrote:
---
Это понятно, ревалидировать кеш на в приложении - это стиль RestFull
приложений,
НЕ в приложении?
Я имел виду, ревалидация В приложении это - RESTful стиль.
Posted at Nginx Forum:
Я имел виду, ревалидация В приложении это - RESTful стиль.
Не знал, насколько я знаю, обычно REST преподносят, как набор
методов(действий), которые можно выполнить с объектом и путь к этому
объекту.
Да, но не только, основная идея в том, что клиент и сервер могут полностью
описать своё
С этого и надо было начинать, они нужны обязательно если вы хотите
клиенту отдавать 304 без контента.
А можно ли создавать ETag и Last-Modified на стороне nginx и для
статики и для динамики?
есть директива etag on; но написано что она только для статики
автоматом вычисляет его.
Можно
Но все эти детали лучше не говорить тем кто только начинает изучать
механизмы кеширования в Nginx )
Почему?
Чтобы не пугать, раньше времени )
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251763,251837#msg-251837
___
nginx-ru mailing
Если я правильно понял этот поток текста, то на выходе вы хотите
получить что-то вроде The stale-if-error Cache-Control
Extension, http://tools.ietf.org/html/rfc5861#section-4. Т.е.
возможность задать в заголовках ответа - можно ли этот ответ в
дальнейшем использовать при ошибках.
Да,
Наверно стоит объяснить почему логику кеширования мы вынесли на бекенд и
минимально используем конфиг Nginx.
Нашим бекендом, пользуются не только браузеры но и мобил приложения, у них
логика кеширования очень продвинутая, там учитывается временное пропадания
online, в этом случаи клиентское
Пакеты для CentOS 7 доступны.
http://nginx.org/en/linux_packages.html#mainline
Да, спасибо!
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,251548,251862#msg-251862
___
nginx-ru mailing list
nginx-ru@nginx.org
Есть один способ:
http://www.lexa.ru/nginx-ru/msg30320.html
И второй способ: просто не включать кеширование
на стороне nginx в тех location`ах, где оно не нужно.
Есть и третий способ
if ($upstream_status = 304) {
set no_cache = 1;
}
fastcgi_no_cache $no_cache;
Ещё как вариант, Nginx
В результате: минимальный overhead, максимальная производительность.
В целом я с вами согласен.
С удалением валидаторов, можно мирится, ради производительности.
Так же можно настроить в конфиге все нужные location в которых нужно
выключать кеширования, я тоже знаю как это делать.
Просто мне
Всегда их включать? Они так постоянно будут уходить к клиенту.
Или только, когда нужно, добавлять в конфиг.
Включать всегда их не нужно.
Включать нужно только на стадии разработки, для удобства дебага.
Так удобней и не придется заглядывать в логи Nginx и в логи приложения,
чтобы определить
Пакеты для CentOS 7 доступны.
http://nginx.org/en/linux_packages.html#mainline
После, выхода EPEL репозитория для CentOS 7, наблюдается проблема с
обновлением Nginx.
http://ftp.tlk-l.net/pub/mirrors/fedora-epel/7/x86_64/repoview/epel-release.html
yum update - постоянно пытается обновить
2. с помощью плагина yum-plugin-priorities настроить приоритеты
репозиториев таким образом, чтобы у EPEL был более низкий приоритет.
это в любом случае полезно настроить для всех используемых
репозиториев
Спасибо, так и сделали.
3. попросить мантейреров пакета из nginx.org чтобы они
Надо только - чтобы Epoch у пакетов из репозиториев nginx.org был выше
чем у пакета nginx из репозитория EPEL и других сторонних
репозиториев.
Потому что EPEL содержит много полезных пакетов и его очень часто
подключают к CentOS - в том числе и вместе с репозиторием от nginx.org
Согласен.
В документации не нашел, описания как включить ревалидацию по ETag, для
модуля SSI, аналог SSIETag в Apache .
В Nginx, ssi_etag уже есть, или пока что в разработке?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,253455,253455#msg-253455
___
В nginx 1.7.3+ при включении ssi_last_modified не удаляются weak
entity tags (а strong преобразуются в weak), что позволяет
ревалидировать SSI-ответы по ETag в том числе.
Ok, спасибо
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,253455,253464#msg-253464
Вы указываете временную дельту равной 1 секунде, относительно от последнего
запроса к РНР бекенду.
Возможно вам больше подойдет вариант указывать абсолютный unix time.
Как-то так
header('X-Accel-Expires: @'.time() + 1);
Posted at Nginx Forum:
Евгений Удовихин Wrote:
---
В общем разобрался, просто в header функция time в принципе
некорректно
себя ведет, если вывести time()+1 в отдельную переменную и
подставлять, то
тогда все работает. Спасибо всем.
Сори, я не ставил скобки в
Изменения в nginx 1.7.7
28.10.2014
*) Изменение: теперь nginx учитывает при кэшировании строку Vary
в
заголовке ответа бэкенда.
Где можно почитать подробности влияния Vary, на кеширования в Nginx?
Posted at Nginx Forum:
Михаил Монашёв Wrote:
---
Здравствуйте, Maxim.
*) Изменение: теперь строки If-Modified-Since, If-Range и им
подобные в заголовке запроса клиента передаются бэкенду при
включённом кэшировании, если nginx заранее знает,
Валентин Бартенев Wrote:
---
nginx - это такой веб-сервер, с помощью которого можно измерить
производительность ab, но не наоборот.
:)
Вот по этому, компрессию лучше производить в Nginx, в кеше сохранять сжатый
ответ.
Posted at Nginx Forum:
Валентин Бартенев Wrote:
---
Конечно, у задачи сжатия перед кэшированиям тоже есть свои юзкейсы, но
её реализация не так проста, как может показаться. Скорее всего для
этого
придется переписать весь механизм кэширования или добавлять еще
При кешировании ответов бекенда, нужно научить Nginx предварительно сжимать
ответ бекенда, если данный ответ соответствует указанному gzip_types.
Раньше это было сложно по многим причинам, не было модуля gunzip и не было
weak ETag, но сейчас есть все необходимое чтобы использовать gzip до
Результаты 1 - 100 из 235 matches
Mail list logo
