Hvordan bufre innhold i NGINX
NGINX er en konsolidert åpen kildekode, høyytelses webserver som øker hastigheten på innhold og applikasjonslevering, øker sikkerheten og forbedrer skalerbarheten. En av de vanligste brukstilfellene av Nginx er en Content Caching, som er den mest effektive måten å øke ytelsen til et nettsted.
Du kan bruke NGINX til å akselerere lokale opprinnelsesservere ved å konfigurere den til å bufre svar fra oppstrømsservere og også for å lage edge-servere for innholdsleveringsnettverk (CDN). NGINX driver noen av de største CDN-ene.
Når den er konfigurert som en cache, vil NGINX:
- buffer statisk og dynamisk innhold.
- forbedre ytelsen til dynamisk innhold med mikrobufring.
- vis gammelt innhold mens du revaliderer i bakgrunnen for bedre ytelse.
- overstyr eller angi Cache-Control-overskrifter og mer.
I denne artikkelen vil du lære hvordan du konfigurerer NGINX som innholdsbufring i Linux for å få webserverne til å kjøre så effektivt som mulig.
Du bør ha NGINX installert på Linux-serveren din, hvis ikke følg disse veiledningene for å installere Nginx:
- Hvordan installerer du Nginx på CentOS 8
- Hvordan installerer du Nginx på CentOS 7
Buffer statisk innhold på Nginx
Statisk innhold er innhold på et nettsted som forblir det samme (endres ikke) på tvers av sider. Eksempler på statisk innhold inkluderer filer som bilder, videoer, dokumenter; CSS-filer og JavaScript-filer.
Hvis nettstedet ditt bruker mye statisk innhold, kan du optimere ytelsen ved å aktivere hurtigbufring på klientsiden der nettleseren lagrer kopier av statisk innhold for raskere tilgang.
Følgende eksempelkonfigurasjon er et godt valg, bare erstatt www.example.com med URL-en til nettstedets navn og foreta endringer i andre banenavn etter behov.
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;
}
}
Buffer dynamisk innhold på Nginx
NGINX bruker en vedvarende diskbasert cache plassert et sted i det lokale filsystemet. Så start med å lage den lokale diskkatalogen for lagring av bufret innhold.
# mkdir -p /var/cache/nginx
Deretter setter du riktig eierskap på cache-katalogen. Den skal eies av NGINX-brukeren (nginx) og gruppen (nginx) som følger.
# chown nginx:nginx /var/cache/nginx
Fortsett nå videre for å se hvordan du aktiverer dynamisk innhold på Nginx i delen nedenfor.
Aktiverer FastCGI Cache i NGINX
FastCGI (eller FCGI) er en mye brukt protokoll for å koble interaktive applikasjoner som PHP med webservere som NGINX. Det er en utvidelse av CGI (Common Gateway Interface).
Hovedfordelen med FCGI er at den administrerer flere CGI-forespørsler i en enkelt prosess. Uten den må webserveren åpne en ny prosess (som må kontrolleres, behandle en forespørsel og lukkes) for hver klientforespørsel om en tjeneste.
For å behandle PHP-skript i en LEMP-stack-distribusjon, bruker NGINX FPM (FastCGI Process Manager) eller PHP-FPM, et populært alternativ for PHP FastCGI-implementering. Når PHP-FPM-prosessen kjører, er NGINX konfigurert til proxy-forespørsler til den for behandling. Dermed kan NGINX også konfigureres til å cache svar fra PHP-FPM-backend-applikasjonsserveren.
Under NGINX er FastCGI-innholdsbufferen erklært ved å bruke et direktiv kalt fastcgi_cache_path i toppnivå http{}-konteksten, innenfor NGINX-konfigurasjonsstrukturen. Du kan også legge til fastcgi_cache_key som definerer en nøkkel (forespørselsidentifikator) for caching.
Dessuten, for å lese oppstrøms cache-status, legg til add_header X-Cache-Status-direktivet innenfor http{}-konteksten – dette er nyttig for feilsøkingsformål.
Forutsatt at nettstedets serverblokkkonfigurasjonsfil er plassert på /etc/nginx/conf.d/testapp.conf eller /etc/nginx/sites-available/testapp.conf (under Ubuntu og dens derivater), åpner du redigeringsfilen og legger til følgende linjer øverst i filen.
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;
fastcgi_cache_path-direktivet spesifiserer antall parametere som er:
- /var/cache/nginx – banen til den lokale diskkatalogen for cachen.
- nivåer – definerer hierarkinivåene til en cache, den setter opp et to-nivå kataloghierarki under /var/cache/nginx.
- nøkler_sone (navn:størrelse) – gjør det mulig å opprette en delt minnesone der alle aktive nøkler og informasjon om data (meta) er lagret. Merk at lagring av nøklene i minnet øker hastigheten på kontrollprosessen, ved å gjøre det enklere for NGINX å finne ut om det er en MISS eller HIT, uten å sjekke statusen på disken.
- inaktiv – spesifiserer hvor lenge bufrede data som ikke er åpnet i løpet av den angitte tiden blir slettet fra hurtigbufferen uavhengig av hvor oppdatert de er. En verdi på 60 m i eksempelkonfigurasjonen betyr at filer som ikke er åpnet etter 60, vil bli fjernet fra hurtigbufferen.
- max_size – spesifiserer maksimal størrelse på hurtigbufferen. Det er flere parametere du kan bruke her (les NGINX-dokumentasjonen for mer informasjon).
Variablene i fastcgi_cache_key-direktivet er beskrevet nedenfor.
NGINX bruker dem til å beregne nøkkelen (identifikatoren) til en forespørsel. Viktigere, for å sende et bufret svar til klienten, må forespørselen ha samme nøkkel som et bufret svar.
- $schema – forespørselsskjema, HTTP eller HTTPS.
- $request_method – forespørselsmetode, vanligvis \GET\ eller \POST.
- $host – dette kan være vertsnavn fra forespørselslinjen, eller vertsnavn fra «Vert»-forespørselshodefeltet, eller servernavnet som samsvarer med en forespørsel, i prioritetsrekkefølge.
- $request_uri – betyr den fullstendige originale forespørsels-URI (med argumenter).
Også $upstream_cache_status-variabelen i add_header X-Cache-Status-direktivet beregnes for hver forespørsel som NGINX svarer på, enten det er en MISS (svar ikke funnet i hurtigbufferen, hentet fra applikasjonsserveren) eller en HIT (svar servert fra cache) eller noen av de andre støttede verdiene.
Deretter, innenfor location-direktivet som sender PHP-forespørsler til PHP-FPM, bruker fastcgi_cache-direktivene for å aktivere cachen du nettopp har definert ovenfor.
Angi også hurtigbuffertid for forskjellige svar ved å bruke fastcgi_cache_valid-direktivet som vist.
fastcgi_cache CACHEZONE; fastcgi_cache_valid 60m;
Hvis bare hurtigbuffertid er spesifisert som i vårt tilfelle, bufres bare 200, 301 og 302 svar. Men du kan også spesifisere svarene eksplisitt eller bruke noen (for enhver svarkode):
fastcgi_cache CACHEZONE; fastcgi_cache_valid 200 301 203 60m; fastcgi_cache_valid 404 10m; OR fastcgi_cache CACHEZONE; fastcgi_cache_valid any 10m;
Finjuster FastCGI Caching-ytelse på Nginx
For å angi minimum antall ganger en forespørsel med samme nøkkel må gjøres før svaret bufres, inkluderer fastcgi_cache_min_uses-direktivet, enten i http{} eller >server{} eller location{} kontekst.
fastcgi_cache_min_uses 3
For å aktivere revalidering av utløpte hurtigbufferelementer ved bruk av betingede forespørsler med «If-Modified-Since»- og «If-None-Match»-overskriftsfeltene, legg til fastcgi_cache_revalidate-direktivet i >http{} eller server{} eller location{} kontekst.
fastcgi_cache_revalidate on;
Du kan også instruere NGINX om å levere bufret innhold når opprinnelsesserveren eller FCGI-serveren er nede, ved å bruke proxy_cache_use_stale-direktivet, innenfor lokasjonsdirektivet.
Denne eksempelkonfigurasjonen betyr at når NGINX mottar en feil, tidsavbrudd og noen av de spesifiserte feilene fra oppstrømsserveren og har en gammel versjon av den forespurte filen i det bufrede innholdet, leverer den den foreldede filen.
proxy_cache_use_stale error timeout http_500;
Et annet nyttig direktiv for å finjustere FCGI-bufringsytelsen er fastcgi_cache_background_update som fungerer sammen med proxy_cache_use_stale-direktivet. Når den er satt til på, instruerer den NGINX om å vise gammelt innhold når klienter ber om en fil som er utløpt eller er i ferd med å bli oppdatert fra oppstrømsserveren.
fastcgi_cache_background_update on;
fastcgi_cache_lock er også nyttig for finjustering av cache-ytelse ved at hvis flere klienter ber om det samme innholdet som ikke er i cachen, vil NGINX kun videresende den første forespørselen til oppstrømsserveren, cache svar serverer deretter de andre klientforespørslene fra hurtigbufferen.
fastcgi_cache_lock on;
Etter å ha gjort alle endringene ovenfor i NGINX-konfigurasjonsfilen, lagre og lukk den. Sjekk deretter konfigurasjonsstrukturen for eventuelle syntaksfeil før du starter NGINX-tjenesten på nytt.
# nginx -t # systemctl restart nginx
Deretter tester du om hurtigbufferen fungerer som den skal, prøv å få tilgang til nettapplikasjonen eller nettstedet ditt ved å bruke følgende curl-kommando (første gang skal indikere en MISS, men påfølgende forespørsler skal indikere et HIT som vist på skjermbildet).
# curl -I http://testapp.linux-console.net
Her er et annet skjermbilde som viser NGINX som serverer foreldede data.
Legger til unntak til omgå buffer
Det er mulig å sette betingelser for at NGINX ikke skal sende bufrede svar til klienter, ved å bruke fastcgi_cache_bypass-direktivet. Og for å instruere NGINX om ikke å bufre svar fra oppstrømsserveren i det hele tatt, bruk fastcgi_no_cache.
For eksempel, hvis du vil at POST-forespørsler og URL-er med en spørringsstreng alltid skal gå til PHP. Først erklærer du en if-setning for å angi betingelsen som følger.
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
Aktiver deretter unntaket ovenfor i location-direktivet som sender PHP-forespørsler til PHP-FPM, ved å bruke fastcgi_cache_bypass- og fastcgi_no_cache-direktivene.
fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache;
Det er mange andre deler av nettstedet ditt som du kanskje ikke vil aktivere innholdsbufring for. Følgende er et eksempel på NGINX-konfigurasjon for å forbedre ytelsen til et WordPress-nettsted, gitt på nginx.com-bloggen.
For å bruke det, gjør endringer (som domenet, stier, filnavn osv.) for å gjenspeile det som eksisterer i miljøet ditt.
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;
}
}
Aktivering av proxy-buffer i NGINX
NGINX støtter også bufring av svar fra andre proxy-servere (definert av proxy_pass-direktivet). For dette testtilfellet bruker vi NGINX som en omvendt proxy for en Node.js-nettapplikasjon, så vi vil aktivere NGINX som en hurtigbuffer for Node.js-applikasjonen. Alle konfigurasjonsdirektivene som brukes her har lignende betydninger som FastCGI-direktivene i forrige seksjon, så vi vil ikke forklare dem igjen.
For å aktivere bufring av svar fra en proxy-server, inkluderer proxy_cache_path-direktivet i http{}-konteksten på toppnivå. For å spesifisere hvordan forespørsler bufres, kan du også legge til proxy_cache_key-direktivet som følger.
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;
Deretter aktiverer du hurtigbufferen i lokasjonsdirektivet.
location / {
proxy_pass http://127.0.0.1:3000;
proxy_cache PROXYCACHE;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
}
For å definere forhold under hvilke NGINX ikke sender bufret innhold og ikke hurtigbuffer et svar i det hele tatt fra oppstrømsserveren, inkluderer du proxy_cache_bypass og proxy_no_cache.
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment; proxy_no_cache $http_pragma $http_authorization;
Finjustering av proxy-bufferytelse
Følgende direktiver er nyttige for å finjustere ytelsen til proxy-bufferen. De har også samme betydning som FastCGI-direktivene.
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;
For mer informasjon og caching-konfigurasjonsdirektiver, se dokumentasjonen for de to hovedmodulene ngx_http_proxy_module.
Ytterligere ressurser: Tips for å forbedre WordPress-ytelsen.