Kako shraniti vsebino v NGINX


NGINX je konsolidiran odprtokodni, visoko zmogljiv spletni strežnik, ki pospešuje dostavo vsebin in aplikacij, povečuje varnost in izboljšuje razširljivost. Eden najpogostejših primerov uporabe Nginxa je Content Caching, ki je najučinkovitejši način za povečanje učinkovitosti spletnega mesta.

NGINX lahko uporabite za pospeševanje lokalnih izvornih strežnikov, tako da ga konfigurirate za predpomnjenje odzivov strežnikov v zgornjem toku in tudi za ustvarjanje robnih strežnikov za omrežja za dostavo vsebine (CDN). NGINX poganja nekatere največje CDN-je.

Ko je NGINX konfiguriran kot predpomnilnik:

  • predpomni statično in dinamično vsebino.
  • izboljšati zmogljivost dinamične vsebine z mikro-predpomnjenjem.
  • služijo zastareli vsebini, medtem ko se v ozadju ponovno preverja veljavnost za boljše delovanje.
  • preglasite ali nastavite glave Cache-Control in še več.

V tem članku boste izvedeli, kako konfigurirati NGINX kot sistem za predpomnjenje vsebine v Linuxu, da bodo vaši spletni strežniki delovali čim bolj učinkovito.

Na strežniku Linux bi morali imeti nameščen NGINX, če ne, sledite tem navodilom za namestitev Nginxa:

  • Kako namestiti Nginx na CentOS 8
  • Kako namestiti Nginx na CentOS 7

Predpomni statično vsebino v Nginxu

Statična vsebina je vsebina spletnega mesta, ki ostane enaka (se ne spreminja) na straneh. Primeri statične vsebine vključujejo datoteke, kot so slike, video posnetki, dokumenti; Datoteke CSS in datoteke JavaScript.

Če vaše spletno mesto uporablja veliko statične vsebine, lahko njegovo delovanje optimizirate tako, da omogočite predpomnjenje na strani odjemalca, kjer brskalnik shrani kopije statične vsebine za hitrejši dostop.

Naslednja vzorčna konfiguracija je dobra ideja, samo zamenjajte www.example.com z URL-jem imena vašega spletnega mesta in po potrebi spremenite druga imena poti.

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;
    }
}

Predpomni dinamično vsebino v Nginxu

NGINX uporablja trajni predpomnilnik na disku, ki se nahaja nekje v lokalnem datotečnem sistemu. Začnite tako, da ustvarite lokalni imenik diska za shranjevanje predpomnjene vsebine.
# mkdir -p/var/cache/nginx

Nato nastavite ustrezno lastništvo v imeniku predpomnilnika. V lasti naj bo uporabnik NGINX (nginx) in skupina (nginx), kot sledi.

# chown nginx:nginx /var/cache/nginx

Zdaj nadaljujte in poglejte, kako v spodnjem razdelku omogočite dinamično vsebino v Nginxu.

Omogočanje predpomnilnika FastCGI v NGINX

FastCGI (ali FCGI) je široko uporabljen protokol za povezovanje interaktivnih aplikacij, kot je PHP, s spletnimi strežniki, kot je NGINX. Je razširitev CGI (Common Gateway Interface).

Glavna prednost FCGI je, da v enem procesu upravlja več zahtev CGI. Brez tega mora spletni strežnik odpreti nov postopek (ki ga je treba nadzorovati, obdelati zahtevo in zapreti) za vsako zahtevo stranke za storitev.

Za obdelavo PHP skriptov v uvajanju sklada LEMP NGINX uporablja FPM (FastCGI Process Manager) ali PHP-FPM, priljubljeno alternativno izvedbo PHP FastCGI. Ko se postopek PHP-FPM zažene, je NGINX nastavljen tako, da mu posreduje zahteve za obdelavo. Tako je NGINX mogoče konfigurirati tudi za predpomnjenje odzivov iz zalednega strežnika PHP-FPM.

Pod NGINX je predpomnilnik vsebine FastCGI deklariran z uporabo direktive, imenovane fastcgi_cache_path v kontekstu najvišje ravni http {} , v konfiguracijski strukturi NGINX. Dodate lahko tudi fastcgi_cache_key , ki definira ključ (identifikator zahteve) za predpomnjenje.

Poleg tega za branje stanja predpomnilnika v zgornjem toku dodajte direktivo add_header X-Cache-Status v kontekst http {} - to je koristno za namene odpravljanja napak.

Če predpostavimo, da se konfiguracijska datoteka blokovskega strežnika vašega spletnega mesta nahaja na /etc/nginx/conf.d/testapp.conf ali /etc/nginx/sites-available/testapp.conf (pod Ubuntu in njegovimi derivati), odprite datoteko za urejanje in dodajte naslednje vrstice na vrhu datoteke.

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;

Direktiva fastcgi_cache_path določa število parametrov, ki so:

  • /var/cache/nginx - pot do lokalnega direktorija diska za predpomnilnik.
  • ravni - definira ravni hierarhije predpomnilnika, v/var/cache/nginx pa nastavi dvonivojsko hierarhijo imenika.
  • keys_zone (name: size) - omogoča ustvarjanje skupnega pomnilniškega območja, kjer so shranjeni vsi aktivni ključi in podatki o podatkih (meta). Shranjevanje ključev v pomnilnik pospeši postopek preverjanja, tako da NGINX lažje ugotovi, ali gre za MISS ali HIT, ne da bi preveril stanje na disku.
  • neaktiven - določa čas, po katerem se predpomnjeni podatki, do katerih v določenem času ne dostopajo, izbrišejo iz predpomnilnika ne glede na njihovo svežino. Vrednost 60m v našem primeru konfiguracije pomeni, da bodo datoteke, do katerih po 60 letih ne bomo dostopali, odstranjene iz predpomnilnika.
  • max_size - določa največjo velikost predpomnilnika. Tu lahko uporabite več parametrov (za več informacij preberite dokumentacijo NGINX).

Spremenljivke v direktivi fastcgi_cache_key so opisane spodaj.

NGINX jih uporablja pri izračunu ključa (identifikatorja) zahteve. Pomembno je, da mora stranka za pošiljanje predpomnjenega odgovora stranki imeti isti ključ kot predpomnjeni odgovor.

  • $shema - shema zahtev, HTTP ali HTTPS.
  • $request_method - metoda zahteve, običajno\"GET" ali\"POST".
  • $host - to je lahko ime gostitelja iz vrstice za zahtevo, ali ime gostitelja iz polja glave "\" gostitelj "ali ime strežnika, ki ustreza zahtevi, v prednostnem vrstnem redu.
  • $request_uri - pomeni celoten izvirni URI zahteve (z argumenti).

Tudi spremenljivka $upstream_cache_status v direktivi add_header X-Cache-Status se izračuna za vsako zahtevo, na katero se odzove NGINX, ne glede na to, ali gre za MISS (v predpomnilniku ni odgovora, ki ga dobimo s strežnika aplikacij) ali HIT (odgovor iz predpomnilnika) ali katera koli druga podprta vrednost.

Nato znotraj direktive location , ki PHP-zahteve posreduje PHP-FPM, z direktivami fastcgi_cache aktivira predpomnilnik, ki ste ga pravkar definirali zgoraj.

Nastavite tudi čas predpomnjenja za različne odzive z direktivo fastcgi_cache_valid , kot je prikazano.

fastcgi_cache CACHEZONE;
fastcgi_cache_valid  60m;

Če je določen samo čas predpomnjenja, kot v našem primeru, se predpomni le 200, 301 in 302 odzivov. Lahko pa tudi izrecno določite odgovore ali uporabite katerega koli (za katero koli kodo odziva):

fastcgi_cache CACHEZONE;
fastcgi_cache_valid 200  301 203 60m;
fastcgi_cache_valid 404 10m;
OR
fastcgi_cache CACHEZONE;
fastcgi_cache_valid  any 10m;

Natančna nastavitev predpomnjenja FastCGI na Nginxu

Če želite nastaviti najmanjše število zahtevkov z istim ključem, preden je odgovor predpomnjen, vključite direktivo fastcgi_cache_min_uses , bodisi v http {} ali kontekst strežnika {} ali lokacija {} .

fastcgi_cache_min_uses  3

Če želite omogočiti ponovno preverjanje veljavnosti iztečenih elementov predpomnilnika z uporabo pogojnih zahtev s poljima glave\"Če je spremenjeno-od" in\"Če-nobeno-ne", dodajte direktivo fastcgi_cache_revalidate v kodo < > kontekst http {} ali strežnika {} ali location {} .

fastcgi_cache_revalidate on;

NGINX lahko tudi naročite, da dostavi predpomnjeno vsebino, ko izvorni strežnik ali strežnik FCGI ne deluje, z uporabo direktive proxy_cache_use_stale znotraj direktive o lokaciji.

Ta vzorčna konfiguracija pomeni, da ko NGINX od napačnega strežnika prejme napako, časovno omejitev in katero koli od določenih napak in ima v predpomnjeni vsebini zastarelo različico zahtevane datoteke, dostavi zastarelo datoteko.

proxy_cache_use_stale error timeout http_500;

Druga koristna direktiva za natančno uravnavanje zmogljivosti predpomnjenja FCGI je fastcgi_cache_background_update , ki deluje v povezavi z direktivo proxy_cache_use_stale . Ko je vklopljen, NGINX naroči, naj streže zastarelo vsebino, ko odjemalci zahtevajo datoteko, ki je potekla ali je v postopku posodabljanja s strežnika navzgor.

fastcgi_cache_background_update on;

Tudi fastcgi_cache_lock je uporaben za natančno uravnavanje zmogljivosti predpomnilnika, saj bo NGINX, če več odjemalcev zahteva isto vsebino, ki ni v predpomnilniku, poslal zgolj prvo zahtevo na strežnik v zgornjem toku, predpomnilnik odziv nato postrežejo druge zahteve strank iz predpomnilnika.

fastcgi_cache_lock on;

Po izvedbi vseh zgornjih sprememb v konfiguracijski datoteki NGINX jo shranite in zaprite. Nato pred vnovičnim zagonom storitve NGINX preverite v konfiguracijski strukturi morebitne sintaksne napake.

# nginx -t
# systemctl restart nginx

Nato preizkusite, ali predpomnilnik deluje pravilno, poskusite dostopati do svoje spletne aplikacije ali spletnega mesta z uporabo naslednjega ukaza curl (prvič mora navesti MISS, poznejše zahteve pa HIT, kot je prikazano na posnetku zaslona).

# curl -I http://testapp.linux-console.net

Tu je še posnetek zaslona, ki prikazuje zastarele podatke NGINX.

Dodajanje izjem v Bypass Cache

Možno je nastaviti pogoje, pod katerimi NGINX ne sme pošiljati predpomnjenih odgovorov odjemalcem z uporabo fastcgi_cache_bypass direktive. Če želite NGINX naročiti, da odzivov s strežnika navzgor sploh ne predpomni, uporabite fastcgi_no_cache .

Če na primer želite, da zahteve POST in URL-ji z nizom poizvedbe vedno gredo v PHP. Najprej prijavite izjavo if, da nastavite pogoj, kot sledi.

set $skip_cache 0; 
if ($request_method = POST) { 
	set $skip_cache 1; 
} 

Nato aktivirajte zgornjo izjemo v direktivi location , ki PHP-zahteve posreduje PHP-FPM, z uporabo direktiv fastcgi_cache_bypass in fastcgi_no_cache .

 
fastcgi_cache_bypass $skip_cache; 
fastcgi_no_cache $skip_cache;

Obstaja veliko drugih delov vašega spletnega mesta, za katere morda ne želite omogočiti predpomnjenja vsebine. Sledi primer konfiguracije NGINX za izboljšanje delovanja spletnega mesta WordPress, ki je na voljo v spletnem dnevniku nginx.com.

Če jo želite uporabiti, naredite spremembe (kot so domena, poti, imena datotek itd.), Da bodo odražale, kaj obstaja v vašem okolju.

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; 
	} 
}

Omogočanje predpomnilnika proxy v NGINX

NGINX podpira tudi predpomnjenje odgovorov z drugih posredniških strežnikov (opredeljenih z direktivo proxy_pass ). V tem testnem primeru uporabljamo NGINX kot obratni proxy za spletno aplikacijo Node.js, zato bomo omogočili NGINX kot predpomnilnik za aplikacijo Node.js. Vse tukaj uporabljene konfiguracijske direktive imajo podoben pomen kot direktive FastCGI v prejšnjem poglavju, zato jih ne bomo več razlagali.

Če želite omogočiti predpomnjenje odzivov s strežnika proxy, vključite direktivo proxy_cache_path v kontekst http {} na najvišji ravni. Če želite določiti, kako se zahteve shranjujejo v predpomnilnik, lahko dodate tudi direktivo proxy_cache_key , kot sledi.

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;

Nato aktivirajte predpomnilnik v direktivi o lokaciji.

location / {
	proxy_pass http://127.0.0.1:3000;
	proxy_cache        PROXYCACHE;
	proxy_cache_valid 200 302 10m;
	proxy_cache_valid 404      1m;
}

Če želite določiti pogoje, pod katerimi NGINX ne pošilja predpomnjene vsebine in sploh ne predpomni odgovora s strežnika navzgor, vključite proxy_cache_bypass in proxy_no_cache .

 
proxy_cache_bypass  $cookie_nocache $arg_nocache$arg_comment;
proxy_no_cache        $http_pragma $http_authorization;

Fina nastavitev zmogljivosti predpomnilnika proxy

Naslednje smernice so koristne za natančno uravnavanje delovanja predpomnilnika proxy. Imajo tudi enak pomen kot direktive FastCGI.

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;

Za več informacij in konfiguracijske smernice predpomnjenja glejte dokumentacijo za dva glavna modula ngx_http_proxy_module.

Dodatni viri: Nasveti za izboljšanje učinkovitosti WordPressa.