Zoeken op website

Hoe inhoud in NGINX in de cache te plaatsen


NGINX is een geconsolideerde open-source, krachtige webserver die de levering van inhoud en applicaties versnelt, de beveiliging verbetert en de schaalbaarheid verbetert. Een van de meest voorkomende gebruiksscenario's van Nginx is Content Caching, wat de meest effectieve manier is om de prestaties van een website te verbeteren.

Lees ook: 10 beste open source cachingtools voor Linux

U kunt NGINX gebruiken om lokale oorsprongsservers te versnellen door het te configureren om reacties van upstream-servers in de cache op te slaan en ook om edge-servers te maken voor netwerken voor inhoudslevering (CDN's). NGINX beheert enkele van de grootste CDN’s.

Indien geconfigureerd als cache, zal NGINX:

  • cache statische en dynamische inhoud.
  • verbeter de prestaties van dynamische inhoud met micro-caching.
  • serveer verouderde inhoud terwijl deze op de achtergrond opnieuw wordt gevalideerd voor betere prestaties.
  • overschrijf of stel Cache-Control-headers in, en meer.

In dit artikel leert u hoe u NGINX configureert als Content Caching in Linux om uw webservers zo efficiënt mogelijk te laten werken.

Vereisten:

Je zou NGINX geïnstalleerd moeten hebben op je Linux-server. Zo niet, volg dan deze handleidingen om Nginx te installeren:

  • Hoe Nginx op CentOS 8 te installeren
  • Hoe Nginx op CentOS 7 te installeren

Cache statische inhoud op Nginx

Statische inhoud is inhoud van een website die op alle pagina's hetzelfde blijft (niet verandert). Voorbeelden van statische inhoud zijn bestanden zoals afbeeldingen, video's en documenten; CSS-bestanden en JavaScript-bestanden.

Als uw website veel statische inhoud gebruikt, kunt u de prestaties ervan optimaliseren door caching aan de clientzijde in te schakelen, waarbij de browser kopieën van statische inhoud opslaat voor snellere toegang.

De volgende voorbeeldconfiguratie is een goed idee. Vervang gewoon www.example.com door de URL van uw websitenaam en breng indien nodig wijzigingen aan in andere padnamen.

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 dynamische inhoud op Nginx

NGINX gebruikt een persistente schijfgebaseerde cache die zich ergens in het lokale bestandssysteem bevindt. Begin dus met het maken van de lokale schijfmap voor het opslaan van inhoud in de cache.
# mkdir -p /var/cache/nginx

Stel vervolgens het juiste eigendom in voor de cachemap. Het moet als volgt eigendom zijn van de NGINX gebruiker (nginx) en groep (nginx).

chown nginx:nginx /var/cache/nginx

Ga nu verder om te zien hoe u dynamische inhoud op Nginx inschakelt in de onderstaande sectie.

FastCGI-cache inschakelen in NGINX

FastCGI (of FCGI) is een veelgebruikt protocol voor het communiceren van interactieve applicaties zoals PHP met webservers zoals NGINX sterk>. Het is een uitbreiding van de CGI (Common Gateway Interface).

Het belangrijkste voordeel van FCGI is dat het meerdere CGI-verzoeken in één proces beheert. Zonder dit moet de webserver een nieuw proces openen (dat moet worden gecontroleerd, een verzoek moet verwerken en moet worden gesloten) voor elk klantverzoek om een dienst.

Om PHP-scripts in een LEMP-stackimplementatie te verwerken, gebruikt NGINX FPM (FastCGI Process Manager) of PHP-FPM, een populaire alternatieve PHP FastCGI-implementatie. Zodra het PHP-FPM-proces actief is, wordt NGINX geconfigureerd om verzoeken ernaar te sturen voor verwerking. NGINX kan dus ook worden geconfigureerd om antwoorden van de PHP-FPM backend-applicatieserver in de cache op te slaan.

Onder NGINX wordt de inhoudscache van FastCGI gedeclareerd met behulp van een richtlijn met de naam fastcgi_cache_path in http{} op het hoogste niveau context, binnen de NGINX-configuratiestructuur. U kunt ook de fastcgi_cache_key toevoegen, die een sleutel (request identifier) voor caching definieert.

Om de upstream cachestatus te lezen, voegt u bovendien de add_header X-Cache-Status richtlijn toe binnen de http{} context – dit is handig voor foutopsporingsdoeleinden.

Ervan uitgaande dat het serverblokconfiguratiebestand van uw site zich bevindt op /etc/nginx/conf.d/testapp.conf of /etc/nginx/sites-available/testapp.conf ( onder Ubuntu en zijn derivaten), open het bewerkingsbestand en voeg de volgende regels bovenaan het bestand toe.

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;

De fastcgi_cache_path richtlijn specificeert het aantal parameters:

  • /var/cache/nginx – het pad naar de lokale schijfmap voor de cache.
  • levels – definieert de hiërarchieniveaus van een cache, het zet een maphiërarchie op twee niveaus op onder /var/cache/nginx.
  • keys_zone (naam:grootte) – maakt het mogelijk een gedeelde geheugenzone te creëren waar alle actieve sleutels en informatie over gegevens (meta) worden opgeslagen. Merk op dat het opslaan van de sleutels in het geheugen het controleproces versnelt, doordat het voor NGINX gemakkelijker wordt om te bepalen of het een MISS of HIT is, zonder de status op schijf te controleren.
  • inactief – specificeert de hoeveelheid tijd waarna in de cache opgeslagen gegevens die niet toegankelijk zijn gedurende de opgegeven tijd, uit de cache worden verwijderd, ongeacht hun versheid. Een waarde van 60m in onze voorbeeldconfiguratie betekent dat bestanden die na 60 niet worden geopend, uit de cache worden verwijderd.
  • max_size – specificeert de maximale grootte van de cache. Er zijn meer parameters die u hier kunt gebruiken (lees de NGINX-documentatie voor meer informatie).

De variabelen in de fastcgi_cache_key richtlijn worden hieronder beschreven.

NGINX gebruikt ze bij het berekenen van de sleutel (identifier) van een verzoek. Belangrijk is dat als u een in de cache opgeslagen antwoord naar de client wilt verzenden, de aanvraag dezelfde sleutel moet hebben als een in de cache opgeslagen antwoord.

  • $scheme – verzoekschema, HTTP of HTTPS.
  • $request_method – verzoekmethode, meestal “GET ” of “POST”.
  • $host – dit kan de hostnaam zijn uit de verzoekregel, of de hostnaam uit het “Host” verzoekheaderveld, of de servernaam die overeenkomt met een verzoek, in volgorde van prioriteit .
  • $request_uri – betekent de volledige oorspronkelijke verzoek-URI (met argumenten).

Ook wordt de $upstream_cache_status variabele in de add_header X-Cache-Status richtlijn berekend voor elk verzoek waarop NGINX reageert, ongeacht of het een MISS is > (antwoord niet gevonden in de cache, ontvangen van applicatieserver) of een HIT (antwoord geleverd vanuit cache) of een van de andere ondersteunde waarden.

Vervolgens gebruikt de location richtlijn, die PHP-verzoeken doorgeeft aan PHP-FPM, de fastcgi_cache richtlijnen om de cache te activeren die u zojuist hierboven hebt gedefinieerd.

Stel ook de cachetijd in voor verschillende reacties met behulp van de fastcgi_cache_valid richtlijn, zoals weergegeven.

fastcgi_cache CACHEZONE;
fastcgi_cache_valid  60m;

Als alleen de cachetijd is opgegeven, zoals in ons geval, worden alleen 200, 301 en 302 reacties in de cache opgeslagen. Maar u kunt de antwoorden ook expliciet specificeren of een willekeurige (voor elke antwoordcode) gebruiken:

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

Verfijning van FastCGI-cachingprestaties op Nginx

Om het minimumaantal keren in te stellen dat een verzoek met dezelfde sleutel moet worden gedaan voordat het antwoord in de cache wordt opgeslagen, neemt u de fastcgi_cache_min_uses richtlijn op, hetzij in de http{} of server{} of locatie{} context.

fastcgi_cache_min_uses  3

Voeg de fastcgi_cache_revalidate richtlijn, binnen de http{} of server{} of locatie{} context.

fastcgi_cache_revalidate on;

U kunt NGINX ook opdracht geven om in de cache opgeslagen inhoud te leveren wanneer de oorspronkelijke server of FCGI-server niet beschikbaar is, met behulp van de proxy_cache_use_stale richtlijn, binnen de locatierichtlijn.

Deze voorbeeldconfiguratie betekent dat wanneer NGINX een fout, time-out en een van de gespecificeerde fouten ontvangt van de upstream-server en een verouderde versie van het aangevraagde bestand in de cacheinhoud heeft, het verouderde bestand aflevert.

proxy_cache_use_stale error timeout http_500;

Een andere nuttige richtlijn om de cachingprestaties van FCGI te verfijnen is fastcgi_cache_background_update, die samenwerkt met de proxy_cache_use_stale richtlijn. Als dit is ingeschakeld, instrueert het NGINX om verouderde inhoud weer te geven wanneer clients vragen om een bestand dat is verlopen of wordt bijgewerkt vanaf de upstream-server.

fastcgi_cache_background_update on;

De fastcgi_cache_lock is ook handig voor het afstemmen van de cacheprestaties, omdat als meerdere clients dezelfde inhoud aanvragen die niet in de cache staat, NGINX alleen het eerste verzoek doorstuurt naar de upstream-server, de antwoord en voer vervolgens de andere clientverzoeken uit de cache uit.

fastcgi_cache_lock on;

Nadat u alle bovenstaande wijzigingen in het NGINX-configuratiebestand hebt aangebracht, slaat u het op en sluit u het. Controleer vervolgens de configuratiestructuur op eventuele syntaxisfouten voordat u de NGINX-service opnieuw start.

nginx -t
systemctl restart nginx

Test vervolgens of de cache goed functioneert en probeer toegang te krijgen tot uw webapplicatie of site via de volgende curl-opdracht (de eerste keer moet een MISS aangeven, maar daaropvolgende verzoeken moeten een HIT aangeven zoals weergegeven in de schermafbeelding).

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

Hier is nog een screenshot waarin NGINX oude gegevens weergeeft.

Uitzonderingen toevoegen om cache te omzeilen

Het is mogelijk om voorwaarden in te stellen waaronder NGINX geen gecachte antwoorden naar clients mag sturen, met behulp van de fastcgi_cache_bypass richtlijn. En om NGINX te instrueren om helemaal geen antwoorden van de upstream-server in de cache op te slaan, gebruikt u de fastcgi_no_cache.

Als u bijvoorbeeld wilt dat POST-verzoeken en URL's met een queryreeks altijd naar PHP gaan. Declareer eerst een if-instructie om de voorwaarde als volgt in te stellen.

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

Activeer vervolgens de bovenstaande uitzondering in de location richtlijn die PHP-verzoeken doorgeeft aan PHP-FPM, met behulp van de fastcgi_cache_bypass en fastcgi_no_cache richtlijnen.

 
fastcgi_cache_bypass $skip_cache; 
fastcgi_no_cache $skip_cache;

Er zijn veel andere delen van uw site waarvoor u het cachen van inhoud mogelijk niet wilt inschakelen. Het volgende is een voorbeeld van een NGINX-configuratie voor het verbeteren van de prestaties van een WordPress-site, aangeboden op de nginx.com blog.

Om het te gebruiken, brengt u wijzigingen aan (zoals het domein, de paden, de bestandsnamen, enz.) om weer te geven wat er in uw omgeving bestaat.

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

Proxycache inschakelen in NGINX

NGINX ondersteunt ook het cachen van antwoorden van andere proxyservers (gedefinieerd door de proxy_pass richtlijn). Voor deze testcase gebruiken we NGINX als een reverse proxy voor een Node.js-webapplicatie, dus we zullen NGINX inschakelen als cache voor de Node.js-applicatie. Alle hier gebruikte configuratierichtlijnen hebben dezelfde betekenis als de FastCGI-richtlijnen in de vorige sectie, dus we zullen ze niet nog een keer uitleggen.

Om het cachen van antwoorden van een proxyserver mogelijk te maken, neemt u de proxy_cache_path-instructie op in de http{}-context op het hoogste niveau. Om te specificeren hoe verzoeken in de cache worden opgeslagen, kunt u ook als volgt de proxy_cache_key richtlijn toevoegen.

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;

Activeer vervolgens de cache in de locatierichtlijn.

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

Om voorwaarden te definiëren waaronder NGINX geen inhoud in de cache verzendt en helemaal geen antwoord van de upstream-server in de cache opslaat, neemt u de proxy_cache_bypass en proxy_no_cache op.

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

Proxy-cacheprestaties nauwkeurig afstemmen

De volgende richtlijnen zijn nuttig voor het afstemmen van de prestaties van de proxycache. Ze hebben ook dezelfde betekenis als de FastCGI-richtlijnen.

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;

Voor meer informatie en caching-configuratierichtlijnen, zie de documentatie voor de twee hoofdmodules ngx_http_fastcgi_module en ngx_http_proxy_module.

Aanvullende bronnen: NGINX-inhoudcaching en tips voor het verbeteren van WordPress-prestaties.