Tartalom gyorsítótárazása az NGINX-ben
Az NGINX egy konszolidált nyílt forráskódú, nagy teljesítményű webszerver, amely felgyorsítja a tartalom és az alkalmazások kézbesítését, növeli a biztonságot és a méretezhetőséget. Az Nginx egyik leggyakoribb használati esete a Tartalom-gyorsítótárazás, amely a webhely teljesítményének növelésének leghatékonyabb módja.
Olvassa el még: 10 legjobb nyílt forráskódú gyorsítótárazó eszköz Linuxhoz
Az NGINX segítségével felgyorsíthatja a helyi eredetű kiszolgálókat azáltal, hogy úgy konfigurálja, hogy gyorsítótárazza a felfelé irányuló szerverek válaszait, valamint szélszervereket hozzon létre a tartalomszolgáltató hálózatokhoz (CDN-ek). Az NGINX biztosítja a legnagyobb CDN-ek némelyikét.
Ha gyorsítótárként van beállítva, az NGINX:
- gyorsítótár statikus és dinamikus tartalom.
- a dinamikus tartalomteljesítmény javítása mikro-gyorsítótárral.
- elavult tartalmat szolgáltasson, miközben a háttérben újraellenőrzi a jobb teljesítmény érdekében.
- felülbírálhatja vagy beállíthatja a Cache-Control fejléceket és így tovább.
Ebből a cikkből megtudhatja, hogyan konfigurálhatja az NGINX-et Tartalom-gyorsítótárazásként Linuxon, hogy webszerverei a lehető leghatékonyabban működjenek.
Előfeltételek:
Az NGINX-nek telepítve kell lennie a Linux-kiszolgálón, ha nem, kövesse az alábbi útmutatókat az Nginx telepítéséhez:
- Az Nginx telepítése a CentOS 8 rendszeren
- Az Nginx telepítése a CentOS 7 rendszeren
Statikus tartalom gyorsítótárazása az Nginx rendszeren
A statikus tartalom egy webhely tartalma, amely változatlan marad (nem változik) az oldalak között. Statikus tartalom például olyan fájlok, mint a képek, videók, dokumentumok; CSS-fájlok és JavaScript-fájlok.
Ha webhelye sok statikus tartalmat használ, akkor optimalizálhatja teljesítményét az ügyféloldali gyorsítótár engedélyezésével, ahol a böngésző a statikus tartalom másolatait tárolja a gyorsabb hozzáférés érdekében.
A következő példakonfiguráció jó megoldás, csak cserélje ki a www.example.com címet webhelye nevének URL-jére, és szükség szerint módosítsa a többi elérési utat.
server {
# substitute your web server's URL for www.example.com
server_name www.example.com;
root /var/www/example.com/htdocs;
index index.php;
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri =404;
include fastcgi_params;
# substitute the socket, or address and port, of your WordPress server
fastcgi_pass unix:/var/run/php5-fpm.sock;
#fastcgi_pass 127.0.0.1:9000;
}
location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
|midi|wav|bmp|rtf)$ {
expires max;
log_not_found off;
access_log off;
}
}
Dinamikus tartalom gyorsítótárazása az Nginxen
Az NGINX egy állandó lemezalapú gyorsítótárat használ, amely valahol a helyi fájlrendszerben található. Kezdje tehát a helyi lemezkönyvtár létrehozásával a gyorsítótárazott tartalom tárolására.
# mkdir -p /var/cache/nginx
Ezután állítsa be a megfelelő tulajdonjogot a gyorsítótár-könyvtárban. A tulajdonosnak az NGINX felhasználónak (nginx) és a csoportnak (nginx) kell lennie, az alábbiak szerint.
chown nginx:nginx /var/cache/nginx
Most folytassa tovább, hogy megtudja, hogyan engedélyezheti a dinamikus tartalmat az Nginx-en az alábbi részben.
A FastCGI gyorsítótár engedélyezése az NGINX-ben
A FastCGI (vagy FCGI) egy széles körben használt protokoll az interaktív alkalmazások, például a PHP és a webszerverek, például az NGINX összekapcsolására.. Ez a CGI (Common Gateway Interface) kiterjesztése.
Az FCGI fő előnye, hogy több CGI-kérést kezel egyetlen folyamatban. Enélkül a webszervernek új folyamatot kell nyitnia (amelyet vezérelni kell, fel kell dolgozni egy kérést és be kell zárni) minden ügyfél szolgáltatás iránti kérésére.
A PHP szkriptek LEMP-veremben történő feldolgozásához az NGINX az FPM (FastCGI Process Manager) vagy az PHP-FPM, egy népszerű alternatív PHP FastCGI implementáció. Miután a PHP-FPM folyamat fut, az NGINX úgy van konfigurálva, hogy proxy kéréseket küldjön hozzá feldolgozás céljából. Így az NGINX úgy is konfigurálható, hogy gyorsítótárazza a válaszokat a PHP-FPM háttéralkalmazásszerverről.
Az NGINX alatt a FastCGI tartalom-gyorsítótár a fastcgi_cache_path nevű direktívával deklarálva van a legfelső szintű http{}-ban. kontextusban, az NGINX konfigurációs struktúráján belül. Hozzáadhatja a fastcgi_cache_key kódot is, amely kulcsot (kérelemazonosítót) határoz meg a gyorsítótárazáshoz.
Emellett az upstream gyorsítótár állapotának olvasásához adja hozzá az add_header X-Cache-Status direktívát a http{} kontextusba – ez hasznos hibakeresési célokra.
Feltéve, hogy webhelye szerverblokk konfigurációs fájlja a /etc/nginx/conf.d/testapp.conf vagy az /etc/nginx/sites-available/testapp.conf címen található ( az Ubuntu és származékai alatt), nyissa meg a szerkesztőfájlt, és adja hozzá a következő sorokat a fájl tetejéhez.
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=CACHEZONE:10m; inactive=60m max_size=40m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
add_header X-Cache $upstream_cache_status;
A fastcgi_cache_path direktíva a következő paraméterek számát határozza meg:
- /var/cache/nginx – a gyorsítótár helyi lemezkönyvtárának elérési útja.
- levelek – meghatározza a gyorsítótár hierarchiaszintjeit, kétszintű könyvtárhierarchiát állít be a /var/cache/nginx alatt.
- keys_zone (név:méret) – lehetővé teszi egy megosztott memóriazóna létrehozását, ahol az összes aktív kulcs és az adatokkal kapcsolatos információ (meta) tárolva van. Vegye figyelembe, hogy a kulcsok memóriában való tárolása felgyorsítja az ellenőrzési folyamatot, mivel megkönnyíti az NGINX számára annak meghatározását, hogy MISS vagy HIT-e, anélkül, hogy ellenőrizné a lemezen lévő állapotot.
- inaktív – megadja, hogy mennyi idő után törlődnek a gyorsítótárból azok a gyorsítótárazott adatok, amelyekhez a megadott időn belül nem fértek hozzá, függetlenül azok frissességétől. Példakonfigurációnkban a 60 m érték azt jelenti, hogy a 60 után nem elért fájlok törlődnek a gyorsítótárból.
- max_size – a gyorsítótár maximális méretét adja meg. Több paraméter is használható itt (további információért olvassa el az NGINX dokumentációját).
A fastcgi_cache_key direktíva változóit az alábbiakban ismertetjük.
Az NGINX ezeket használja a kérés kulcsának (azonosítójának) kiszámításához. Fontos, hogy gyorsítótárazott válasz küldéséhez a kérésnek ugyanazzal a kulccsal kell rendelkeznie, mint a gyorsítótárazott válasznak.
- $scheme – kérési séma, HTTP vagy HTTPS.
- $request_method – kérési mód, általában „GET ” vagy „POST ”.
- $host – ez lehet gazdagépnév a kéréssorban, vagy gazdagépnév a „Host” kérelem fejlécmezőjéből, vagy a kérésnek megfelelő kiszolgálónév prioritási sorrendben .
- $request_uri – a teljes eredeti kérelem URI-t jelenti (argumentumokkal).
Ezenkívül a $upstream_cache_status változót az add_header X-Cache-Status direktívában a rendszer minden olyan kéréshez kiszámítja, amelyre az NGINX válaszol, függetlenül attól, hogy az MISS. > (a válasz nem található a gyorsítótárban, alkalmazásszerverről érkezett) vagy HIT (a gyorsítótárból kiszolgált válasz) vagy bármely más támogatott érték.
Ezután a location direktíván belül, amely a PHP kéréseket továbbítja a PHP-FPM-nek, a fastcgi_cache direktívákat használja a fent definiált gyorsítótár aktiválásához.
A különböző válaszok gyorsítótárazási idejét is beállíthatja a fastcgi_cache_valid direktíva segítségével, az ábrán látható módon.
fastcgi_cache CACHEZONE;
fastcgi_cache_valid 60m;
Ha csak a gyorsítótárazási idő van megadva, mint esetünkben, akkor csak a 200, 301 és 302 válaszok kerülnek gyorsítótárba. De a válaszokat kifejezetten megadhatja, vagy bármelyiket használhatja (bármilyen válaszkódhoz):
fastcgi_cache CACHEZONE;
fastcgi_cache_valid 200 301 203 60m;
fastcgi_cache_valid 404 10m;
OR
fastcgi_cache CACHEZONE;
fastcgi_cache_valid any 10m;
A FastCGI gyorsítótárazási teljesítmény finomhangolása az Nginx rendszeren
Annak beállításához, hogy a válasz gyorsítótárazása előtt hányszor kell egy kérést ugyanazzal a kulccsal elküldeni, adja meg a fastcgi_cache_min_uses direktívát a http{} vagy a kódban. >szerver{} vagy hely{} kontextusban.
fastcgi_cache_min_uses 3
Ha engedélyezni szeretné a lejárt gyorsítótárelemek feltételes kérelmekkel történő újraellenőrzését az „If-Modified-Since” és az „If-None-Match ” fejlécmezőkkel, adja hozzá a http{} vagy szerver{} vagy location{} kontextusban.
fastcgi_cache_revalidate on;
Arra is utasíthatja az NGINX-et, hogy a hely direktíván belül a proxy_cache_use_stale direktíva segítségével kézbesítsen gyorsítótárazott tartalmat, amikor az eredeti szerver vagy az FCGI-szerver nem működik.
Ez a mintakonfiguráció azt jelenti, hogy amikor az NGINX hibát, időtúllépést és a megadott hibák bármelyikét kapja a felfelé irányuló kiszolgálótól, és a kért fájl elavult verziója van a gyorsítótárazott tartalomban, akkor az elavult fájlt kézbesíti.
proxy_cache_use_stale error timeout http_500;
Egy másik hasznos direktíva az FCGI gyorsítótárazási teljesítményének finomhangolásához a fastcgi_cache_background_update, amely a proxy_cache_use_stale direktívával együtt működik. Ha be van kapcsolva, akkor utasítja az NGINX-et az elavult tartalom kiszolgálására, amikor az ügyfelek olyan fájlt kérnek, amely lejárt, vagy éppen frissítés alatt áll a felfelé irányuló kiszolgálóról.
fastcgi_cache_background_update on;
A fastcgi_cache_lock a gyorsítótár teljesítményének finomhangolásához is hasznos, mivel ha több kliens kéri ugyanazt a tartalmat, amely nincs a gyorsítótárban, az NGINX csak az első kérést továbbítja a felfelé irányuló kiszolgálónak, gyorsítótárazva a választ, majd kiszolgálja a többi ügyfél kérését a gyorsítótárból.
fastcgi_cache_lock on;
Miután elvégezte a fenti módosításokat az NGINX konfigurációs fájlban, mentse és zárja be. Ezután az NGINX szolgáltatás újraindítása előtt ellenőrizze a konfigurációs struktúrát, hogy nincsenek-e szintaktikai hibák.
nginx -t
systemctl restart nginx
Ezután tesztelje, hogy a gyorsítótár megfelelően működik-e, és próbálja meg elérni a webalkalmazást vagy webhelyet a következő curl paranccsal (az első alkalommal MISS-et kell jeleznie, de a további kéréseknek HIT-et kell jelezniük a képernyőképen látható módon).
curl -I http://testapp.linux-console.net
Íme egy másik képernyőkép, amelyen az NGINX elavult adatok kiszolgálása látható.
Kivételek hozzáadása a gyorsítótár megkerüléséhez
A fastcgi_cache_bypass direktíva segítségével beállítható olyan feltételek, amelyek mellett az NGINX ne küldjön gyorsítótárazott válaszokat az ügyfeleknek. Ha pedig arra szeretné utasítani az NGINX-et, hogy egyáltalán ne tárolja a válaszokat a felfelé irányuló kiszolgálóról, használja a fastcgi_no_cache parancsot.
Például, ha azt szeretné, hogy a POST kérések és a lekérdezési karakterláncot tartalmazó URL-ek mindig a PHP-hez menjenek. Először deklaráljon egy if utasítást a feltétel beállításához az alábbiak szerint.
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
Ezután aktiválja a fenti kivételt a location direktívában, amely a PHP kéréseket továbbítja a PHP-FPM-nek a fastcgi_cache_bypass és a fastcgi_no_cache használatával. > direktívák.
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
Webhelyének sok más része is előfordulhat, hogy nem szeretné engedélyezni a tartalom gyorsítótárazását. A következő példa egy NGINX-konfigurációt mutat be a WordPress-webhelyek teljesítményének javítására, amely az nginx.com blogon található.
Használatához hajtson végre módosításokat (például a tartományt, az elérési utakat, a fájlneveket stb.), hogy tükrözze a környezetében található elemeket.
fastcgi_cache_path /var/run/NGINX-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
server {
server_name example.com www.example.com;
root /var/www/example.com;
index index.php;
access_log /var/log/NGINX/example.com.access.log;
error_log /var/log/NGINX/example.com.error.log;
set $skip_cache 0;
# POST requests and URLs with a query string should always go to PHP
if ($request_method = POST) {
set $skip_cache 1;
}
if ($query_string != "") {
set $skip_cache 1;
}
# Don't cache URIs containing the following segments
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php |sitemap(_index)?.xml") {
set $skip_cache 1;
}
# Don't use the cache for logged-in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass |wordpress_no_cache|wordpress_logged_in") {
set $skip_cache 1;
}
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri /index.php;
include fastcgi_params;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 60m;
}
location ~ /purge(/.*) {
fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
}
location ~* ^.+.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg |gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi |wav|bmp|rtf)$ {
access_log off;
log_not_found off;
expires max;
}
location = /robots.txt {
access_log off;
log_not_found off;
}
location ~ /. {
deny all;
access_log off;
log_not_found off;
}
}
Proxy-gyorsítótár engedélyezése az NGINX-ben
Az NGINX támogatja a többi proxyszervertől érkező válaszok gyorsítótárazását is (a proxy_pass direktíva határozza meg). Ebben a tesztesetben az NGINX-et fordított proxyként használjuk egy Node.js webalkalmazáshoz, így engedélyezni fogjuk az NGINX-et gyorsítótárként a Node.js alkalmazás számára. Az itt használt összes konfigurációs direktíva hasonló jelentéssel bír, mint az előző szakaszban szereplő FastCGI direktívák, ezért nem magyarázzuk el újra.
A proxyszervertől érkező válaszok gyorsítótárazásának engedélyezéséhez vegye fel a proxy_cache_path direktívát a legfelső szintű http{} kontextusba. A kérések gyorsítótárazásának meghatározásához hozzáadhatja a proxy_cache_key direktívát is az alábbiak szerint.
proxy_cache_path /var/cache/nginx app1 keys_zone=PROXYCACHE:100m inactive=60m max_size=500m;
proxy_cache_key "$scheme$request_method$host$request_uri";
add_header X-Cache-Status $upstream_cache_status;
proxy_cache_min_uses 3;
Ezután aktiválja a gyorsítótárat a hely direktívában.
location / {
proxy_pass http://127.0.0.1:3000;
proxy_cache PROXYCACHE;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
}
Annak meghatározásához, hogy az NGINX ne küldjön gyorsítótárban tárolt tartalmat, és egyáltalán nem gyorsítótárazzon választ az upstream szervertől, adja meg a proxy_cache_bypass és a proxy_no_cache paramétereket.
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment;
proxy_no_cache $http_pragma $http_authorization;
A proxy gyorsítótár teljesítményének finomhangolása
A következő utasítások hasznosak a proxy gyorsítótár teljesítményének finomhangolásához. Ugyanolyan jelentéssel bírnak, mint a FastCGI direktívák.
proxy_cache_min_uses 3;
proxy_cache_revalidate on;
proxy_cache_use_stale error timeout updating http_500;
proxy_cache_background_update on;
proxy_cache_lock on;
További információkért és a gyorsítótárazási konfigurációs direktívákért tekintse meg a két fő modul (ngx_http_fastcgi_module és ngx_http_proxy_module) dokumentációját.
További források: NGINX tartalom gyorsítótár és tippek a WordPress teljesítményének javításához.