nginx. Кеширане с fastcgi_cache
Уморен съм от факта, че блогът ми се зарежда много време, но няма време да сменя двигателя отWordpress на нещо друго, а преминаването към нов, по-мощен сървър винаги се забавя и реших да затегна кеширането от страна наNginx. Тъй като блогът работи наfastcgi, ще използвамfastcgi_cache, ако използвате пакета Nginx + Apache, тогава трябва да използватеproxy_cache, доколкото разбирам, няма специални разлики.
Все още трябва да оставя някои блокове извън кеша, така че ще използвамssi.
Имам много хостове на един и същи сървър, но трябва да настроя кеш само за един хост. Нека дефинираме кеша за моя блог вnginx.conf, разделhttp :
- път към директорията на кеша, създайте го предварително.levels= - разделяне на кеш файловете в поддиректории на дадено ниво, тоест "1:2" е така:
или така, ако не посочите LEVEL, тоест оставете нивата празни (levels =):
max_size - максимален размер на кеша.incative - живот на кеша.
Настройка на виртуален хост
Разделям конфигурациите на основни (nginx.conf) и хостове (adw0rd.conf, pyha.conf и т.н.). Сега ще се занимаваме с adw0rd.conf:
Можете да прочетете за всички директиви в офиса. dock Директиви на модула ngx_http_fastcgi_module.
Тестване
И сега виждам в страницата за сортиране дали страницата е кеширана или не.
Вмъкване на динамични блокове със SSI
Редактирайте шаблона на страницата си и поставете нещо подобно:
Сега пренесете файла "/ssi/uncached.php" в следната форма:
Тъй като имаме манипулатор, който работи за /ssi/* и не връща кеширани данни, ще имаме заредена динамика, всичко е просто! :)
Допълнение
Директиваfastcgi_ignore_headers за игнориране на инструкции от FastCGI сървъра
Директивата fastcgi_ignore_headers деактивира обработката на определени заглавни редове от отговор на FastCGI сървър. Директивата може да съдържа низовете "X-Accel-Redirect", "X-Accel-Expires", "Expires" и "Cache-Control".
Тоест казваме на Nginx да кешира страниците така или иначе, независимо от кеширащите заглавки, зададени от FastCGI сървъра.
fastcgi_cache_bypass и fastcgi_no_cache директиви
Директивата задава условията, при коитоотговорът няма да бъде взет от кеша. Ако стойността на поне един от променливите низове не е празна и не е равна на "0", тогава отговорът не се взема от кеша:
Директивата задава условията, при коитоотговорът няма да се съхранява в кеша. Ако стойността на поне един от променливите низове не е празна и не е равна на "0", тогава отговорът няма да бъде записан:
Контролиране на кеширането чрез заглавката X-Accel-Expires
Ние ще управляваме кеширането от PHP:
Принудително актуализиране на кеша
Нека актуализираме нашия байпас, добавете друга променлива за заглавката "X-Update":
Е, сега нека актуализираме кеша:
Полезни материали
Ето кратък списък със статии, които може да намерите за полезни:
Коментари
а тук не е така. кешът не се регенерира, но страницата се отваря "в движение"! :)
неактивен=1d; Кешът, който е по-стар от това време, просто се изтрива, като изчистване
fastcgi_cache_valid 10m; И тук, по искане на потребителя, ако кешът е остарял, тогава данните се получават и поставят в кеша
Благодаря ти! :) Готина си както винаги! Слушай, drupal трябва да лети на такава конфигурация :)
И ако трябва ръчно да актуализирате кеша, как да го направите?
И още един въпрос, в този пример, както разбирам, целият кеш генерира само файла /index.php?
Аако трябва ръчно да актуализирате кеша, как да го направите?
Изчистете директорията и рестартирайте nginx
И още един въпрос, в този пример, както разбирам, целият кеш генерира само файла /index.php?
кеша "генерира" nginx и index.php входна точка за маршрути
Що се отнася до обновяването на кеша, има чистка
>index.php входна точка за маршрути е, това е, този скрипт, както разбирам, дава данни, които след това се кешират от nginx
fastcgi_temp_path и fastcgi_cache_path
Забелязах, че всичко е описано най-отгоре =_
В един от моите проекти забелязах, че кешът не се създава, ако вземете страници чрез wget или apache jmeter. Но ако отворите през браузъра, тогава всичко е наред. Имам параметър proxy_cache_key "$request_method$host$request_uri"; Изпитвали ли сте някога нещо подобно?
Не, не съм го срещал, може би е в заглавията
Случаят е подобен на session_start (), извикването на който автоматично води до връщане на заглавките expires/cache-control/pragma от сървъра, т.к. без стартиране на сесията, при поискване чрез wget, nginx кешира.
Но в моята конфигурация имам proxy_hide_header "Set-Cookie" ; proxy_ignore_headers "Cache-Control" "Изтича";
Остава да разберем защо при стартиране на сесия в браузъра nginx се връща от кеша, но кешът не работи чрез wget.
keys_zone=adw0rd:120m И ако поставите повече време тук, например 120m или дори повече, тогава ако php и базата данни спрат да работят, Nginx пак ще показва статично за 2 часа! След като изминат 120 минути и php и базата данни все още не работят, ще има грешка в базата данни или 502.
keys_zone=име:размер В допълнение, всички активни ключове и информация за данни се съхраняват в споделена зона на паметта, чието име и размер се определят от параметъра keys_zone.Ако няма достъп до данните в кеша за времето, посочено от неактивния параметър, тогава данните се изтриват, независимо от тяхната актуалност. По подразбиране неактивността е 10 минути.
Като цяло трябва да използвате inactive. И прочетете за fastcgi_cache_use_stale
Можете ли да ми помогнете limit_req_zone $server_name zona=one:10m rate=30r/m; необходимо е ограничението да не работи за всички php заявки, а само за php заявки, които все още не са кеширани. Тоест, ако има нови заявки, ги поставяме на опашка 1 заявка за 2 секунди за обработка в php-fpm и ги кешираме, а ако заявката вече е кеширана, ги даваме веднага без лимит. limit_req зона=един пакет=30;
Или нещо трябва да бъде усукано в PHP-FPM, така че да е невъзможно едновременното изпълнение на няколко php наведнъж, не повече от една php заявка за две секунди? Необходимо е да се създаде опашка от php, но не и от кеширани.
Наистина не разбрах защо имате нужда от това, но не заявките се кешират, а отговорите, трябва да помислите върху ключа „fastcgi_cache_key“ и тогава ще се кешира само това, което е необходимо.
така че да не можете да стартирате няколко php едновременно
Какъв проблем решавате? Намаляване на натоварването? Не съм работил с php от 3 години, така че е по-добре да поискате действителни данни в някой форум за php
Тогава не разбирам какво общо има fastcgi_cache с това
За да се отървете от дублиращи се заявки и да кеширате това, което вече е проверено за два дни или повече. Оказа се, че в IIS трябва да отидете в Опции на FastCGI и да зададете максималния брой инстанции на 1 и да добавите sleep(2) в php файла;
// текущо време echo date('h:i:s') . "\н"; // изчакайте 10 секунди sleep(10); // край на чакането echo date('h:i:s') . "\н";
Остава само да конфигурирате pm = static в php-fpm.conf ипозволете да се изпълнява само 1 php-fpm процес и след това го кеширайте в Nginx за два дни и дайте пренасочване на кеша с ужасна скорост!
Вместо да пишете логика на PL, за да получавате и кеширате отговори, вие се занимавате с настройките на Nginx/php-fpm. Добре?
Точно така, разбирам само Nginx/php-fpm, но какво е PL? Може ли да провери размера?