Vyhledávání na webu

Jak ukládat obsah do mezipaměti v NGINX


NGINX je konsolidovaný open source, vysoce výkonný webový server, který urychluje poskytování obsahu a aplikací, zvyšuje zabezpečení a zlepšuje škálovatelnost. Jedním z nejčastějších případů použití Nginx je Ukládání obsahu do mezipaměti, což je nejúčinnější způsob, jak zvýšit výkon webu.

Přečtěte si také: 10 nejlepších nástrojů pro ukládání do mezipaměti s otevřeným zdrojovým kódem pro Linux

NGINX můžete použít k urychlení serverů místního původu tím, že jej nakonfigurujete tak, aby ukládal odpovědi z upstreamových serverů do mezipaměti, a také k vytvoření okrajových serverů pro sítě pro doručování obsahu (CDN). NGINX pohání některé z největších CDN.

Když je nakonfigurován jako mezipaměť, NGINX:

  • mezipaměti statického a dynamického obsahu.
  • zlepšit výkon dynamického obsahu pomocí micro-cachingu.
  • zobrazovat zastaralý obsah při opětovném ověřování na pozadí pro lepší výkon.
  • přepsat nebo nastavit hlavičky Cache-Control a další.

V tomto článku se dozvíte, jak nakonfigurovat NGINX jako Ukládání obsahu v Linuxu, aby vaše webové servery běžely co nejefektivněji.

Předpoklady:

Na svém linuxovém serveru byste měli mít nainstalovaný NGINX, pokud ne, nainstalujte Nginx podle následujících pokynů:

  • Jak nainstalovat Nginx na CentOS 8
  • Jak nainstalovat Nginx na CentOS 7

Uložte do mezipaměti statický obsah na Nginx

Statický obsah je obsah webové stránky, který zůstává na všech stránkách stejný (nemění se). Příklady statického obsahu zahrnují soubory, jako jsou obrázky, videa, dokumenty; CSS soubory a soubory JavaScript.

Pokud váš web využívá hodně statického obsahu, můžete jeho výkon optimalizovat povolením ukládání do mezipaměti na straně klienta, kde prohlížeč ukládá kopie statického obsahu pro rychlejší přístup.

Následující ukázková konfigurace je dobrá, stačí nahradit www.example.com adresou URL názvu vašeho webu a podle potřeby upravit další názvy cest.

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

Ukládání dynamického obsahu do mezipaměti na Nginx

NGINX používá trvalou mezipaměť na disku umístěnou někde v místním systému souborů. Začněte tedy vytvořením adresáře místního disku pro ukládání obsahu uloženého v mezipaměti.
# mkdir -p /var/cache/nginx

Dále nastavte příslušné vlastnictví v adresáři mezipaměti. Měl by být vlastněn uživatelem NGINX (nginx) a skupinou (nginx) následujícím způsobem.

chown nginx:nginx /var/cache/nginx

Nyní pokračujte dále a podívejte se, jak povolit dynamický obsah na Nginx v níže uvedené části.

Povolení mezipaměti FastCGI v NGINX

FastCGI (nebo FCGI) je široce používaný protokol pro propojení interaktivních aplikací, jako je PHP, s webovými servery, jako je NGINX silný>. Jedná se o rozšíření CGI (Common Gateway Interface).

Hlavní výhodou FCGI je, že spravuje více požadavků CGI v jednom procesu. Bez toho musí webový server otevřít nový proces (který musí být řízen, zpracovat požadavek a uzavřít) pro každý požadavek klienta na službu.

Ke zpracování skriptů PHP v nasazení zásobníku LEMP používá NGINX FPM (FastCGI Process Manager) nebo PHP-FPM, oblíbená alternativní implementace PHP FastCGI. Jakmile je spuštěn proces PHP-FPM, je NGINX nakonfigurován tak, aby na něj byly zpracovány proxy požadavky. NGINX lze tedy také nakonfigurovat tak, aby ukládal odpovědi z backendového aplikačního serveru PHP-FPM.

V NGINX je mezipaměť obsahu FastCGI deklarována pomocí direktivy nazvané fastcgi_cache_path v http{} nejvyšší úrovně kontextu v rámci konfigurační struktury NGINX. Můžete také přidat fastcgi_cache_key, který definuje klíč (identifikátor požadavku) pro ukládání do mezipaměti.

Kromě toho, chcete-li přečíst stav mezipaměti pro upstream, přidejte do kontextu http{} direktivu add_header X-Cache-Status – to je užitečné pro účely ladění.

Za předpokladu, že konfigurační soubor bloku serveru vašeho webu je umístěn na adrese /etc/nginx/conf.d/testapp.conf nebo /etc/nginx/sites-available/testapp.conf ( pod Ubuntu a jeho deriváty), otevřete soubor úprav a přidejte následující řádky na začátek souboru.

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 určuje počet parametrů, které jsou:

  • /var/cache/nginx – cesta k adresáři místního disku pro mezipaměť.
  • levels – definuje úrovně hierarchie mezipaměti, nastavuje dvouúrovňovou hierarchii adresářů pod /var/cache/nginx.
  • keys_zone (name:size) – umožňuje vytvoření zóny sdílené paměti, kde jsou uloženy všechny aktivní klíče a informace o datech (meta). Uvědomte si, že uložení klíčů do paměti urychluje proces kontroly tím, že NGINX usnadňuje určení, zda MISS nebo HIT, bez kontroly stavu na disku.
  • neaktivní – určuje dobu, po které budou z mezipaměti smazána data uložená v mezipaměti, ke kterým se během zadané doby nepřistoupí, bez ohledu na jejich aktuálnost. Hodnota 60 m v našem příkladu konfigurace znamená, že soubory, ke kterým se nebude přistupovat po 60, budou z mezipaměti odstraněny.
  • max_size – určuje maximální velikost mezipaměti. Zde můžete použít více parametrů (pro více informací si přečtěte dokumentaci NGINX).

Níže jsou popsány proměnné v direktivě fastcgi_cache_key.

NGINX je používá při výpočtu klíče (identifikátoru) požadavku. Důležité je, že k odeslání odpovědi uložené v mezipaměti klientovi musí mít požadavek stejný klíč jako odpověď uložená v mezipaměti.

  • $scheme – schéma požadavku, HTTP nebo HTTPS.
  • $request_method – metoda požadavku, obvykle „GET “ nebo „POST “.
  • $host – může to být název hostitele z řádku požadavku nebo název hostitele z pole záhlaví požadavku „Host“ nebo název serveru odpovídající požadavku v pořadí priority .
  • $request_uri – znamená úplné URI původního požadavku (s argumenty).

Také proměnná $upstream_cache_status v direktivě add_header X-Cache-Status se vypočítává pro každý požadavek, na který NGINX odpoví, ať už jde o MISS (odpověď nebyla nalezena v mezipaměti, byla získána z aplikačního serveru) nebo HIT (odpověď doručena z mezipaměti) nebo jakákoli jiná podporovaná hodnota.

Dále, v rámci direktivy location, která předává požadavky PHP do PHP-FPM, používá direktivy fastcgi_cache k aktivaci mezipaměti, kterou jste právě definovali výše.

Také nastavte čas ukládání do mezipaměti pro různé odpovědi pomocí direktivy fastcgi_cache_valid, jak je znázorněno.

fastcgi_cache CACHEZONE;
fastcgi_cache_valid  60m;

Pokud je zadán pouze čas ukládání do mezipaměti jako v našem případě, ukládá se do mezipaměti pouze 200, 301 a 302. Ale můžete také určit odpovědi explicitně nebo použít libovolnou (pro jakýkoli kód odpovědi):

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

Jemné vyladění výkonu FastCGI mezipaměti na Nginx

Chcete-li nastavit minimální počet, kolikrát musí být požadavek se stejným klíčem proveden před uložením odpovědi do mezipaměti, zahrňte direktivu fastcgi_cache_min_uses, a to buď v http{} nebo server{} nebo umístění{}.

fastcgi_cache_min_uses  3

Chcete-li povolit opětovné ověření položek mezipaměti s prošlou platností pomocí podmíněných požadavků s poli záhlaví „If-Modified-Since“ a „If-None-Match“, přidejte fastcgi_cache_revalidate v kontextu http{} nebo server{} nebo location{}.

fastcgi_cache_revalidate on;

Můžete také instruovat NGINX, aby doručoval obsah uložený v mezipaměti, když je původní server nebo FCGI server mimo provoz, pomocí direktivy proxy_cache_use_stale v rámci direktivy umístění.

Tato ukázková konfigurace znamená, že když NGINX obdrží chybu, časový limit a některou ze zadaných chyb z nadřazeného serveru a má v mezipaměti zastaralou verzi požadovaného souboru, doručí zastaralý soubor.

proxy_cache_use_stale error timeout http_500;

Další užitečnou direktivou pro doladění výkonu FCGI mezipaměti je fastcgi_cache_background_update, která funguje ve spojení s direktivou proxy_cache_use_stale. Když je nastaveno na on, dá pokyn NGINX, aby obsluhoval zastaralý obsah, když klienti požádají o soubor, jehož platnost vypršela nebo je v procesu aktualizace z upstream serveru.

fastcgi_cache_background_update on;

fastcgi_cache_lock je také užitečný pro jemné doladění výkonu mezipaměti v tom, že pokud více klientů požaduje stejný obsah, který není v mezipaměti, NGINX předá pouze první požadavek na upstream server, ukládá do mezipaměti odpověď a poté obslouží požadavky ostatních klientů z mezipaměti.

fastcgi_cache_lock on;

Po provedení všech výše uvedených změn v konfiguračním souboru NGINX jej uložte a zavřete. Poté před restartováním služby NGINX zkontrolujte konfigurační strukturu, zda neobsahuje nějaké syntaktické chyby.

nginx -t
systemctl restart nginx

Dále otestujte, zda mezipaměť funguje správně, pokuste se získat přístup k vaší webové aplikaci nebo webu pomocí následujícího příkazu curl (poprvé by mělo indikovat MISS, ale následné požadavky by měly indikovat HIT jak je znázorněno na snímku obrazovky).

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

Zde je další snímek obrazovky zobrazující NGINX obsluhující zastaralá data.

Přidání výjimek do vynechání mezipaměti

Pomocí direktivy fastcgi_cache_bypass je možné nastavit podmínky, za kterých by NGINX neměl klientům odesílat odpovědi uložené v mezipaměti. A chcete-li dát NGINX pokyn, aby odpovědi z upstream serveru vůbec neukládal do mezipaměti, použijte fastcgi_no_cache.

Pokud například chcete, aby požadavky POST a adresy URL s řetězcem dotazu vždy šly do PHP. Nejprve deklarujte příkaz if, abyste nastavili podmínku následovně.

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

Poté aktivujte výše uvedenou výjimku v direktivě location, která předává požadavky PHP do PHP-FPM, pomocí fastcgi_cache_bypass a fastcgi_no_cache směrnice.

 
fastcgi_cache_bypass $skip_cache; 
fastcgi_no_cache $skip_cache;

Existuje mnoho dalších částí vašeho webu, pro které možná nebudete chtít povolit ukládání obsahu do mezipaměti. Následuje příklad konfigurace NGINX pro zlepšení výkonu webu WordPress, který je k dispozici na blogu nginx.com.

Chcete-li jej použít, proveďte změny (jako je doména, cesty, názvy souborů atd.), aby odrážely to, co existuje ve vašem prostředí.

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

Povolení mezipaměti proxy v NGINX

NGINX také podporuje ukládání odpovědí z jiných proxy serverů do mezipaměti (definované direktivou proxy_pass). Pro tento testovací případ používáme NGINX jako reverzní proxy pro webovou aplikaci Node.js, takže povolíme NGINX jako mezipaměť pro aplikaci Node.js. Všechny zde použité konfigurační direktivy mají podobný význam jako FastCGI direktivy v předchozí části, takže je nebudeme znovu vysvětlovat.

Chcete-li povolit ukládání odpovědí ze serveru proxy do mezipaměti, zahrňte direktivu proxy_cache_path do kontextu http{} nejvyšší úrovně. Chcete-li určit, jak jsou požadavky ukládány do mezipaměti, můžete také přidat direktivu proxy_cache_key následovně.

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;

Dále aktivujte mezipaměť v direktivě umístění.

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

Chcete-li definovat podmínky, za kterých NGINX neodesílá obsah uložený v mezipaměti a vůbec neukládá do mezipaměti odpověď z upstream serveru, zahrňte proxy_cache_bypass a proxy_no_cache.

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

Jemné ladění výkonu mezipaměti proxy

Následující direktivy jsou užitečné pro jemné doladění výkonu mezipaměti proxy. Mají také stejný význam jako direktivy 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;

Další informace a konfigurační direktivy ukládání do mezipaměti najdete v dokumentaci ke dvěma hlavním modulům ngx_http_fastcgi_module a ngx_http_proxy_module.

Další zdroje: Ukládání obsahu do mezipaměti NGINX a tipy pro zlepšení výkonu WordPress.