Комментарии 38
У всех видимо новый год, а я тут такими делами занимаюсь… ух...)
НЛО прилетело и опубликовало эту надпись здесь
if ($request_method = POST ) — не нужно, пост не кешируется автоматически.
Не нужно использовать старый nginx, лучше использовать новый nginx. Он лучше, в нем меньше багов и больше функционала.
Конфиги заключайте в
Не нужно использовать старый nginx, лучше использовать новый nginx. Он лучше, в нем меньше багов и больше функционала.
Конфиги заключайте в
< code >, меня это спасало. <зануда> В конфиге куча повторяющихся мест. proxy_add_header лучше вынести на уровень server или вынести вместе с proxy_pass в отдельный файл, подключаемый через include. Получается намного удобнее, честно :) </зануда>
Парсер — лох, съел < рrе > как тег :(
Правильно — так:
if ($request_method = POST ) — не нужно, пост не кешируется автоматически.
Не нужно использовать старый nginx, лучше использовать новый nginx. Он лучше, в нем меньше багов и больше функционала.
Конфиги заключайте в <рrе> < соdе >, меня это спасало.
<зануда> В конфиге куча повторяющихся мест. proxy_add_header лучше вынести на уровень server или вынести вместе с proxy_pass в отдельный файл, подключаемый через include. Получается намного удобнее, честно :) </зануда>
Правильно — так:
if ($request_method = POST ) — не нужно, пост не кешируется автоматически.
Не нужно использовать старый nginx, лучше использовать новый nginx. Он лучше, в нем меньше багов и больше функционала.
Конфиги заключайте в <рrе> < соdе >, меня это спасало.
<зануда> В конфиге куча повторяющихся мест. proxy_add_header лучше вынести на уровень server или вынести вместе с proxy_pass в отдельный файл, подключаемый через include. Получается намного удобнее, честно :) </зануда>
Попводу Post не согласен, если бы не кеширвоалось то я бы не стал добавлять эту проверку, ибо почти все писал опытным путем.
Это баг, от использования старого nginx :-P
sysoev.ru/nginx/changes.html — 0.7.48,
Исправление: теперь nginx кэширует только ответы на запросы GET.
К слову, в дальнейших версиях очень многое по кешированию было исправлено.
sysoev.ru/nginx/changes.html — 0.7.48,
Исправление: теперь nginx кэширует только ответы на запросы GET.
К слову, в дальнейших версиях очень многое по кешированию было исправлено.
На сервер используется веб панель для работы с клиентами, она почти весь конфиг генерит. Вот и приходится…
Попробовал использовать
, не работает, он переносить на новую строку данные.
я предпочитаю вообще апач не ставить на серверы…
nginx прекрасно и с php и с cgi скриптами справляется.
единственное неудобство для массового хостинга — несовместимость формата описания реврайтов и необходимость прописывать их напрямую в конфиг
nginx прекрасно и с php и с cgi скриптами справляется.
единственное неудобство для массового хостинга — несовместимость формата описания реврайтов и необходимость прописывать их напрямую в конфиг
а в чём смысл
?
достаточно dle_user_id смотреть, если кто-то куки выборочно удалял, то он сам себе злобный буратино
if ($cookie_dle_user_id) { return 412; }
if ($cookie_dle_password) { return 412; }
?
достаточно dle_user_id смотреть, если кто-то куки выборочно удалял, то он сам себе злобный буратино
блог «как я настроил nginx на своём сервере».
А в чем фишка хостить 200+ сайтов на таком железе? Они что все абсолютно не коммерческие?
У вас конфиг неправильный — http секция рано закрывается. Так работать не будет.
sysoev.ru/nginx/docs/http/ngx_http_core_module.html#server
Директива server должна быть внутри http.
Дальше не читал.
sysoev.ru/nginx/docs/http/ngx_http_core_module.html#server
Директива server должна быть внутри http.
Дальше не читал.
интересен расчет кеша в 5 минут…
тоисть зависимость длины кеша от количества сайтов.
получается если в 5 минут больше 300 запросов по всем сайтам — тогда кеш еффективен, если меньше — тогда он избыточен… (натянутый расчет, но в принципе правильный, если учесть лавинообразность обращений)
Рассматривался ли вариант разделения кеширования по статике и динамике?
Большинство проблем ведь не изза скриптов, а изза наличия на странице сотен елементов ака картинки — каждая из которых — дополнительный запрос к серверу.
Почему спрашиваю? да потому, что множетсво кеширования делает сам dle — минуя запуск длинных скриптов — он отдает статические обьекты-страницы.
Случаются ли наложения кеширования CMS на кеширование на уровне nginx? если dle — 5 минут + nginx — 5 минут — ето уже 10, а 10 минут иногда могут тем же анонимусам причинить неудобство в виде пропажи комментария либо наличия на сайте старого контента…
тоисть зависимость длины кеша от количества сайтов.
получается если в 5 минут больше 300 запросов по всем сайтам — тогда кеш еффективен, если меньше — тогда он избыточен… (натянутый расчет, но в принципе правильный, если учесть лавинообразность обращений)
Рассматривался ли вариант разделения кеширования по статике и динамике?
Большинство проблем ведь не изза скриптов, а изза наличия на странице сотен елементов ака картинки — каждая из которых — дополнительный запрос к серверу.
Почему спрашиваю? да потому, что множетсво кеширования делает сам dle — минуя запуск длинных скриптов — он отдает статические обьекты-страницы.
Случаются ли наложения кеширования CMS на кеширование на уровне nginx? если dle — 5 минут + nginx — 5 минут — ето уже 10, а 10 минут иногда могут тем же анонимусам причинить неудобство в виде пропажи комментария либо наличия на сайте старого контента…
упс… увидел в конфиге «статику»
Кеширование включено только на одном сайте, ибо только один сайт дает почти все нагрзку на сервер. Вот именно для него и делалось кеширование.
Там нет никаких обиженных анонимусов. На таких сайтах анонимусы — это поисковики и случайно забредшие по ошибке. Они просто закрывают браузер через 3 секунды.
Чёт не ясно зачем @fallback при наличии @nocached
Как быть с капчей на DLE?
Как оставить ее без кеширования? Ибо она не меняется
/engine/modules/antibot/antibot.php
Как оставить ее без кеширования? Ибо она не меняется
Добавить location с правильным адресом, который будет обрабатываться на бэкенде, и не попадать в кеш
Я понимаю что нужно так добавить, если не затруднит напишите как.
Нужно по крайней мере 2 адреса, это
Не кешировать только капчу по идее не выйдет. Я так понимаю гостю отдается кеш всей страницы?
Конфиг выше действительно сильно снимает нагрузку отдавая гостям кеш, но те же гости испытывают трудности при регистрации
Нужно по крайней мере 2 адреса, это
/index.php?do=register
и /index.php?do=feedback
Не кешировать только капчу по идее не выйдет. Я так понимаю гостю отдается кеш всей страницы?
Конфиг выше действительно сильно снимает нагрузку отдавая гостям кеш, но те же гости испытывают трудности при регистрации
<a href="/antibot.php?__randomString__">капча</a>
то есть <img src="/antibot.php?__randomString__">
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
nginx + apache. Кеширование