NGINX is een geconsolideerde open-source, high-performance webserver die de levering van inhoud en toepassingen versnelt, de beveiliging verbetert en de schaalbaarheid verbetert. Een van de meest voorkomende toepassingen van Nginx is Content Caching, wat de meest effectieve manier is om de prestaties van een website te verbeteren.
Lees ook: 10 Top Open Source Caching Tools voor Linux
Je kunt NGINX gebruiken om lokale oorspronkelijke servers te versnellen door deze te configureren om reacties van upstream servers te cachen en ook om edge servers te maken voor content delivery networks (CDNs). NGINX ondersteunt enkele van de grootste CDNs.
Wanneer geconfigureerd als cache, zal NGINX:
- statische en dynamische inhoud cachen.
- de prestaties van dynamische inhoud verbeteren met micro-caching.
- verouderde inhoud serveren terwijl deze op de achtergrond wordt gevalideerd voor betere prestaties.
- Cache-Control headers overschrijven of instellen, en meer.
In dit artikel leer je hoe je NGINX configureert als Content Caching in Linux om je webservers zo efficiënt mogelijk te laten draaien.
Vereisten:
Je moet NGINX geïnstalleerd hebben op je Linux server, zo niet volg dan deze handleidingen om Nginx te installeren:
Cache Statische Inhoud op Nginx
Statische inhoud is inhoud van een website die hetzelfde blijft (niet verandert) over pagina’s heen. Voorbeelden van statische inhoud zijn bestanden zoals afbeeldingen, video’s, documenten; CSS-bestanden en JavaScript-bestanden.
Als uw website veel statische inhoud gebruikt, kunt u de prestaties optimaliseren door client-side caching in te schakelen waarbij de browser kopieën van statische inhoud opslaat voor snellere toegang.
De volgende voorbeeldconfiguratie is een goede start, vervang gewoon www.example.com door de URL van uw websitenaam en maak aanpassingen aan andere paden indien nodig.
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 op schijf gebaseerde cache ergens in het lokale bestandssysteem. Begin dus met het maken van de lokale schijfmap voor het opslaan van gecachte inhoud.
# mkdir -p /var/cache/nginx
Vervolgens stelt u de juiste eigenaar in voor de cache-map. Deze moet eigendom zijn van de NGINX-gebruiker (nginx) en groep (nginx) zoals hieronder weergegeven.
# chown nginx:nginx /var/cache/nginx
Ga nu verder om te zien hoe u dynamische inhoud op Nginx kunt inschakelen in de onderstaande sectie.
Het inschakelen van FastCGI-cache in NGINX;
FastCGI (of FCGI) is een veelgebruikt protocol voor het koppelen van interactieve toepassingen zoals PHP met webservers zoals NGINX. 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 voor elke clientaanvraag voor een service een nieuw proces openen (dat moet worden gecontroleerd, een verzoek verwerken en worden gesloten).
Om PHP-scripts te verwerken in een LEMP stack-implementatie, gebruikt NGINX FPM (FastCGI Process Manager) of PHP-FPM, een populaire alternatieve PHP FastCGI-implementatie. Zodra het PHP-FPM-proces actief is, is NGINX geconfigureerd om verzoeken door te sturen naar dit proces voor verwerking. Zo kan NGINX ook worden geconfigureerd om reacties van de PHP-FPM-backendtoepassingsserver te cachen.
Onder NGINX wordt de FastCGI-inhoudscache gedeclareerd met behulp van een directive genaamd fastcgi_cache_path in de top-level http{}-context, binnen de NGINX-configuratiestructuur. Je kunt ook de fastcgi_cache_key toevoegen, die een sleutel (aanvraagidentificator) voor caching definieert.
Bovendien, om de status van de upstream cache te lezen, voegt u de add_header X-Cache-Status directive toe binnen de http{} context – dit is handig voor debugdoeleinden.
Als uw serverblokconfiguratiebestand van de site zich bevindt op /etc/nginx/conf.d/testapp.conf of /etc/nginx/sites-available/testapp.conf (onder Ubuntu en zijn derivaten), open dan het bestand ter bewerking en voeg de volgende regels toe aan het begin van het bestand.
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 directive specificeert het aantal parameters, namelijk:
- /var/cache/nginx – het pad naar de lokale schijfmap voor de cache.
- levels – definieert de hiërarchieniveaus van een cache, het stelt een hiërarchie van twee niveaus in onder /var/cache/nginx.
- keys_zone (naam:grootte) – maakt de creatie van een gedeeld geheugenzone mogelijk waarin alle actieve sleutels en informatie over gegevens (meta) worden opgeslagen. Let 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.
- inactive – specificeert de hoeveelheid tijd na welke gecachte gegevens die gedurende de gespecificeerde tijd niet zijn benaderd, worden verwijderd uit de cache, ongeacht hun versheid. Een waarde van 60m in ons voorbeeldconfiguratie betekent dat bestanden die na 60 niet zijn benaderd, uit de cache worden verwijderd.
- max_grootte – specificeert de maximale grootte van de cache. Hier zijn meer parameters die je 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 (identificatie) van een verzoek. Belangrijk is dat om een gecachte respons naar de client te sturen, het verzoek dezelfde sleutel moet hebben als een gecachte respons.
- $scheme – verzoekschema, HTTP of HTTPS.
- $request_method – verzoekmethode, meestal “GET” of “POST”.
- $host – dit kan de hostnaam zijn van de verzoekregel, of de hostnaam van het “Host” verzoekkopveld, of de servernaam die overeenkomt met een verzoek, in de volgorde van voorrang.
- $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, of het nu een MISS is (respons niet gevonden in de cache, verkregen van de toepassingsserver) of een HIT (respons geserveerd uit cache) of een van de andere ondersteunde waarden.
Vervolgens, binnen de location richtlijn die PHP-verzoeken doorstuurt naar PHP-FPM, gebruikt de fastcgi_cache richtlijnen om de cache te activeren die je zojuist hebt gedefinieerd.
Stel ook de cachingtijd in voor verschillende antwoorden met behulp van de fastcgi_cache_valid richtlijn zoals getoond.
fastcgi_cache CACHEZONE; fastcgi_cache_valid 60m;
Als alleen de cachingtijd wordt gespecificeerd, zoals in ons geval, worden alleen 200, 301 en 302 reacties gecachet. Maar je kunt ook de reacties expliciet specificeren of elk (voor elke reactie):
fastcgi_cache CACHEZONE; fastcgi_cache_valid 200 301 203 60m; fastcgi_cache_valid 404 10m; OR fastcgi_cache CACHEZONE; fastcgi_cache_valid any 10m;
Optimalisatie van de FastCGI-cachingprestaties op Nginx
Om het minimumaantal keren in te stellen dat een verzoek met dezelfde sleutel moet worden gedaan voordat de reactie wordt gecachet, voeg de fastcgi_cache_min_uses directive toe, ofwel in de http{} of server{} of location{} context.
fastcgi_cache_min_uses 3
Om hervalidatie van verlopen cache-items mogelijk te maken met conditionele verzoeken met de “If-Modified-Since” en “If-None-Match” header velden, voeg de fastcgi_cache_revalidate directive toe, binnen de http{} of server{} of location{} context.
fastcgi_cache_revalidate on;
Je kunt ook NGINX instrueren om gecachte inhoud te leveren wanneer de oorspronkelijke server of FCGI-server niet beschikbaar is, met behulp van de proxy_cache_use_stale directive, binnen de locatie directive.
Deze voorbeeldconfiguratie betekent dat wanneer NGINX een fout, time-out en een van de gespecificeerde fouten van de upstream server ontvangt en een verouderde versie van het aangevraagde bestand in de gecachte inhoud heeft, levert het het verouderde bestand.
proxy_cache_use_stale error timeout http_500;
Een andere nuttige richtlijn om de prestaties van FCGI-caching te verfijnen is fastcgi_cache_background_update, die samenwerkt met de proxy_cache_use_stale-richtlijn. Wanneer deze is ingesteld op ‘aan’, instrueert het NGINX om verouderde inhoud te serveren wanneer clients een bestand aanvragen dat is verlopen of wordt bijgewerkt vanaf de upstream-server.
fastcgi_cache_background_update on;
De fastcgi_cache_lock is ook handig voor het fine-tunen van de cache-prestaties, omdat als meerdere clients dezelfde inhoud aanvragen die niet in de cache staat, NGINX alleen het eerste verzoek doorstuurt naar de upstream-server, het antwoord in de cache plaatst en vervolgens de andere clientverzoeken vanuit de cache bedient.
fastcgi_cache_lock on;
Na het maken van al deze wijzigingen in het NGINX-configuratiebestand, 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
Vervolgens test u of de cache goed werkt door toegang te proberen te krijgen tot uw webtoepassing of site met behulp van de volgende curl-opdracht (de eerste keer zou een MISS moeten aangeven, maar daaropvolgende verzoeken zouden een HIT moeten aangeven zoals weergegeven in de schermafbeelding).
# curl -I http://testapp.tecmint.com
Hier is nog een schermafbeelding waarop te zien is dat NGINX verouderde gegevens serveert.
Toevoegen van uitzonderingen om de cache te omzeilen
Het is mogelijk om voorwaarden in te stellen waaronder NGINX geen gecachte antwoorden naar clients moet sturen, met behulp van de fastcgi_cache_bypass directive. En om NGINX te instrueren om helemaal geen antwoorden van de upstream server te cachen, gebruik de fastcgi_no_cache.
Bijvoorbeeld, als je wilt dat POST verzoeken en URL’s met een query string altijd naar PHP gaan. Declareer eerst een if statement 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 directive die PHP verzoeken doorstuurt naar PHP-FPM, met behulp van de fastcgi_cache_bypass en fastcgi_no_cache directives.
fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache;
Er zijn veel andere delen van je site waarvoor je mogelijk geen content caching wilt inschakelen. Het volgende is een voorbeeld NGINX-configuratie voor het verbeteren van de prestaties van een WordPress-site, verstrekt op de nginx.com blog.
Om het te gebruiken, maak wijzigingen (zoals het domein, paden, bestandsnamen, enz.) om overeen te komen met wat er in jouw 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;
}
}
Het inschakelen van Proxy Cache in NGINX
NGINX ondersteunt ook het cachen van antwoorden van andere geproxiede servers (gedefinieerd door de proxy_pass directive). Voor dit testgeval gebruiken we NGINX als een reverse proxy voor een Node.js webapplicatie, dus zullen we NGINX inschakelen als cache voor de Node.js applicatie. Alle configuratie directives die hier worden gebruikt hebben vergelijkbare betekenissen als de FastCGI directives in de vorige sectie, dus zullen we ze niet opnieuw uitleggen.
Om het cachen van reacties van een geproxiede server mogelijk te maken, voeg de proxy_cache_path directive toe in de top-level http{} context. Om te specificeren hoe verzoeken worden gecachet, kunt u ook de proxy_cache_key directive toevoegen zoals volgt.
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;
Vervolgens activeert u de cache in de location directive.
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 gecachte inhoud verzendt en helemaal geen reactie cacht van de upstream server, voeg de proxy_cache_bypass en proxy_no_cache toe.
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment; proxy_no_cache $http_pragma $http_authorization;
Optimalisatie van de Prestaties van de Proxy Cache
De volgende directives zijn nuttig voor het afstemmen van de prestaties van de proxy cache. Ze hebben ook dezelfde betekenissen als de FastCGI directives.
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 configuratie directives, zie de documentatie voor de twee belangrijkste modules ngx_http_fastcgi_module en ngx_http_proxy_module.
Extra Bronnen: NGINX Content Caching en Tips voor het Verbeteren van de Prestaties van WordPress.