Sådan cachelagres indhold i NGINX
NGINX er en konsolideret open source, højtydende webserver, der fremskynder levering af indhold og applikationer, forbedrer sikkerheden og forbedrer skalerbarheden. Et af de mest almindelige brugssager af Nginx er en Content Caching, som er den mest effektive måde at øge ydeevnen på et websted på.
Du kan bruge NGINX til at fremskynde lokale oprindelsesservere ved at konfigurere det til cache-svar fra upstream-servere og også til at oprette kantservere til indholdsleveringsnetværk (CDN'er). NGINX driver nogle af de største CDN'er.
Når den er konfigureret som en cache, vil NGINX:
- cache-statisk og dynamisk indhold.
- forbedre dynamisk indholdsydelse med mikro-caching.
- server uaktuelt indhold, mens du forlænger i baggrunden for at opnå bedre ydeevne.
- tilsidesætter eller indstiller Cache-Control-overskrifter og mere.
I denne artikel lærer du, hvordan du konfigurerer NGINX som en Content Caching i Linux, så dine webservere kører så effektivt som muligt.
Du skulle have NGINX installeret på din Linux-server, hvis ikke følg disse vejledninger for at installere Nginx:
- Sådan installeres Nginx på CentOS 8
- Sådan installeres Nginx på CentOS 7
Cache-statisk indhold på Nginx
Statisk indhold er indholdet på et websted, der forbliver det samme (ændres ikke) på tværs af sider. Eksempler på statisk indhold inkluderer filer som billeder, videoer, dokumenter; CSS-filer og JavaScript-filer.
Hvis dit websted bruger meget statisk indhold, kan du optimere dets ydeevne ved at aktivere caching på klientsiden, hvor browseren gemmer kopier af statisk indhold for hurtigere adgang.
Følgende eksempelkonfiguration er en god chance, bare udskift www.example.com med webadressen på dit webstedsnavn og foretag ændringer af andre pathnames efter 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;
}
}
Cache-dynamisk indhold på Nginx
NGINX bruger en vedvarende diskbaseret cache placeret et eller andet sted i det lokale filsystem. Så start med at oprette den lokale diskmappe til lagring af cachelagret indhold.
# mkdir -p/var/cache/nginx
Indstil derefter det relevante ejerskab i cache-biblioteket. Det skal ejes af NGINX-brugeren (nginx) og gruppen (nginx) som følger.
# chown nginx:nginx /var/cache/nginx
Fortsæt nu videre for at se, hvordan du aktiverer dynamisk indhold på Nginx i nedenstående afsnit.
Aktivering af FastCGI-cache i NGINX
FastCGI (eller FCGI) er en udbredt protokol til interfacering af interaktive applikationer såsom PHP med webservere som NGINX. Det er en udvidelse af CGI (Common Gateway Interface).
Den største fordel ved FCGI er, at den administrerer flere CGI-anmodninger i en enkelt proces. Uden det skal webserveren åbne en ny proces (der skal styres, behandle en anmodning og blive lukket) for hver klientanmodning om en tjeneste.
For at behandle PHP-scripts i en LEMP-stack-implementering bruger NGINX FPM (FastCGI Process Manager) eller PHP-FPM, et populært alternativ PHP FastCGI-implementering. Når PHP-FPM-processen kører, er NGINX konfigureret til proxyanmodninger til den til behandling. Således kan NGINX også konfigureres til at cache svar fra PHP-FPM-backend-applikationsserveren.
Under NGINX erklæres FastCGI-indholdscachen ved hjælp af et direktiv kaldet fastcgi_cache_path i topniveau http {} -kontekst inden for NGINX-konfigurationsstrukturen. Du kan også tilføje fastcgi_cache_key , der definerer en nøgle (anmodningsidentifikator) til cache.
For at læse upstream-cache-status skal du tilføje add_header X-Cache-Status-direktivet inden for http {} -konteksten - dette er nyttigt til fejlfindingsformål.
Forudsat at dit websteds serverblokkonfigurationsfil findes på /etc/nginx/conf.d/testapp.conf eller /etc/nginx/sites-available/testapp.conf (under Ubuntu og dets derivater), skal du åbne redigeringsfilen og tilføje de 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;
Direktivet fastcgi_cache_path specificerer antallet af parametre, der er:
- /var/cache/nginx - stien til den lokale diskmappe for cachen.
- niveauer - definerer hierarkiniveauerne for en cache, den opretter et to-niveau kataloghierarki under/var/cache/nginx.
- keys_zone (navn: størrelse) - muliggør oprettelse af en delt hukommelseszone, hvor alle aktive nøgler og information om data (meta) er gemt. Bemærk, at lagring af tasterne i hukommelsen fremskynder kontrolprocessen ved at gøre det lettere for NGINX at afgøre, om det er en MISS eller HIT, uden at kontrollere status på disken.
- inaktiv - angiver det tidsrum, hvorefter cachelagrede data, der ikke er adgang til i løbet af den angivne tid, slettes fra cachen uanset deres friskhed. En værdi på 60 m i vores eksempelkonfiguration betyder, at filer, der ikke er adgang til efter 60, fjernes fra cachen.
- max_size - angiver cacheens maksimale størrelse. Der er flere parametre, du kan bruge her (læs NGINX-dokumentationen for mere information).
Variablerne i fastcgi_cache_key direktivet er beskrevet nedenfor.
NGINX bruger dem til at beregne nøglen (identifikator) for en anmodning. Det er vigtigt, at for at sende et cachelagret svar til klienten skal anmodningen have den samme nøgle som et cachelagret svar.
- $-skema - anmodningsskema, HTTP eller HTTPS.
- $ request_method - anmodningsmetode, normalt "GET" eller "POST".
- $ host - dette kan være værtsnavn fra anmodningslinjen eller værtsnavn fra "Host" -anmodningens headerfelt eller servernavnet, der matcher en anmodning, i rækkefølgen af forrang.
- $ request_uri - betyder den fulde oprindelige anmodning URI (med argumenter).
Variablen $ upstream_cache_status i add_header X-Cache-Status-direktivet beregnes også for hver anmodning, som NGINX reagerer på, uanset om det er et MISS (svar ikke fundet i cachen, hentet fra applikationsserveren) eller et HIT (svar serveret fra cache) eller nogen af de andre understøttede værdier.
Dernæst bruger direktivet location , der sender PHP-anmodninger til PHP-FPM, direktiverne fastcgi_cache til at aktivere den cache, du lige har defineret ovenfor.
Indstil også cachetid for forskellige svar ved hjælp af fastcgi_cache_valid direktivet som vist.
fastcgi_cache CACHEZONE; fastcgi_cache_valid 60m;
Hvis kun cachetiden er angivet som i vores tilfælde, cachelagres kun 200, 301 og 302 svar. Men du kan også angive svarene eksplicit eller bruge en hvilken som helst (til 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;
Finjustering af FastCGI caching-ydeevne på Nginx
For at indstille det mindste antal gange, der skal foretages en anmodning med den samme nøgle, før svaret caches, skal du medtage fastcgi_cache_min_uses -direktivet, enten i http {} eller kontekst for server {} eller placering {} .
fastcgi_cache_min_uses 3
For at aktivere re-validering af udløbne cacheelementer ved hjælp af betingede anmodninger med "If-Modified-Since" og "If-None-Match" headerfelterne skal du tilføje fastcgi_cache_revalidate direktivet inden for http {} eller server {} eller placering {} kontekst.
fastcgi_cache_revalidate on;
Du kan også instruere NGINX om at levere cachelagret indhold, når originalserveren eller FCGI-serveren er nede ved hjælp af proxy_cache_use_stale -direktivet inden for placeringsdirektivet.
Denne eksempelkonfiguration betyder, at når NGINX modtager en fejl, timeout og en af de angivne fejl fra upstream-serveren og har en uaktuel version af den anmodede fil i det cachelagrede indhold, leverer den den uaktuelle fil.
proxy_cache_use_stale error timeout http_500;
Et andet nyttigt direktiv til finjustering af FCGI-cache-ydeevne er fastcgi_cache_background_update , der fungerer i forbindelse med proxy_cache_use_stale -direktivet. Når den er slået til, instruerer den NGINX om at servere uaktuelt indhold, når klienter anmoder om en fil, der er udløbet eller er ved at blive opdateret fra upstream-serveren.
fastcgi_cache_background_update on;
fastcgi_cache_lock er også nyttigt til finjustering af cacheydelse, at hvis flere klienter anmoder om det samme indhold, der ikke er i cachen, videresender NGINX kun den første anmodning til upstream-serveren, cache svar derefter betjene de andre klientanmodninger fra cachen.
fastcgi_cache_lock on;
Når du har foretaget alle ovennævnte ændringer i NGINX-konfigurationsfilen, skal du gemme og lukke den. Kontroller derefter konfigurationsstrukturen for syntaksfejl, inden du genstarter NGINX-tjenesten.
# nginx -t # systemctl restart nginx
Test derefter, om cachen fungerer korrekt, prøv at få adgang til din webapplikation eller dit websted ved hjælp af følgende curl-kommando (første gang skal angive en MISS, men efterfølgende anmodninger skal angive et HIT som vist på skærmbilledet).
# curl -I http://testapp.linux-console.net
Her er et andet skærmbillede, der viser NGINX, der serverer uaktuelle data.
Tilføjelse af undtagelser til Bypass-cache
Det er muligt at indstille betingelser, hvorunder NGINX ikke skal sende cachelagrede svar til klienter ved hjælp af fastcgi_cache_bypass direktivet. Og for at instruere NGINX om ikke at cache svar fra upstream-serveren overhovedet skal du bruge fastcgi_no_cache .
For eksempel, hvis du altid vil have POST-anmodninger og URL'er med en forespørgselsstreng til PHP. Angiv først en if-erklæring for at indstille betingelsen som følger.
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
Aktiver derefter ovenstående undtagelse i placering -direktivet, som sender PHP-anmodninger til PHP-FPM ved hjælp af fastcgi_cache_bypass og fastcgi_no_cache direktiverne.
fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache;
Der er mange andre dele af dit websted, som du måske ikke vil aktivere caching af indhold for. Følgende er et eksempel på NGINX-konfiguration til forbedring af ydelsen på et WordPress-websted, der findes på bloggen nginx.com.
For at bruge det skal du foretage ændringer (såsom domænet, stier, filnavne osv.) For at afspejle det, der findes i dit miljø.
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 af proxycache i NGINX
NGINX understøtter også caching af svar fra andre proxyservere (defineret af proxy_pass -direktivet). I denne test sag bruger vi NGINX som en omvendt proxy til en Node.js webapplikation, så vi vil aktivere NGINX som en cache for Node.js applikationen. Alle konfigurationsdirektiver, der er brugt her, har samme betydninger som FastCGI-direktiverne i det foregående afsnit, så vi forklarer dem ikke igen.
For at aktivere caching af svar fra en proxyserver skal du inkludere proxy_cache_path -direktivet i den øverste niveau http {} -kontekst. For at specificere, hvordan anmodninger cachelagres, kan du også tilføje 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;
Derefter skal du aktivere cachen i placeringsdirektivet.
location / {
proxy_pass http://127.0.0.1:3000;
proxy_cache PROXYCACHE;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
}
For at definere betingelser, hvorunder NGINX ikke sender cachelagret indhold og slet ikke cache et svar fra upstream-serveren, skal du inkludere proxy_cache_bypass og proxy_no_cache .
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment; proxy_no_cache $http_pragma $http_authorization;
Finjustering af proxy-cache-ydeevne
Følgende direktiver er nyttige til finjustering af ydeevnen for proxy-cachen. De har også de samme betydninger som FastCGI-direktiverne.
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 yderligere information og cache-konfigurationsdirektiver, se dokumentationen til de to hovedmoduler ngx_http_fastcgi_module og ngx_http_proxy_module.
Yderligere ressourcer: NGINX Content Caching og tip til forbedring af WordPress-ydeevne.