Jak buforować zawartość w NGINX
NGINX to skonsolidowany, wysokowydajny serwer internetowy typu open source, który przyspiesza dostarczanie treści i aplikacji, zwiększa bezpieczeństwo i poprawia skalowalność. Jednym z najczęstszych przypadków użycia Nginx jest Buforowanie treści, które jest najskuteczniejszym sposobem na zwiększenie wydajności witryny internetowej.
Przeczytaj także: 10 najlepszych narzędzi do buforowania typu open source dla systemu Linux
Możesz użyć NGINX do przyspieszenia lokalnych serwerów pochodzenia, konfigurując go do buforowania odpowiedzi z serwerów nadrzędnych, a także do tworzenia serwerów brzegowych dla sieci dostarczania treści (CDN). NGINX obsługuje niektóre z największych sieci CDN.
Po skonfigurowaniu jako pamięć podręczna NGINX:
- buforuj zawartość statyczną i dynamiczną.
- poprawić wydajność zawartości dynamicznej dzięki mikro-cachingowi.
- udostępniaj nieaktualne treści podczas ponownego sprawdzania poprawności w tle w celu uzyskania lepszej wydajności.
- zastąpić lub ustawić nagłówki Cache-Control i nie tylko.
W tym artykule dowiesz się, jak skonfigurować NGINX jako buforowanie treści w systemie Linux, aby Twoje serwery internetowe działały tak wydajnie, jak to możliwe.
Warunki wstępne:
Powinieneś mieć zainstalowany NGINX na swoim serwerze Linux, jeśli nie, postępuj zgodnie z tymi przewodnikami, aby zainstalować Nginx:
- Jak zainstalować Nginx na CentOS 8
- Jak zainstalować Nginx na CentOS 7
Buforuj zawartość statyczną w Nginx
Treść statyczna to treść witryny internetowej, która pozostaje taka sama (nie zmienia się) na wszystkich stronach. Przykłady treści statycznych obejmują pliki takie jak obrazy, filmy i dokumenty; Pliki CSS i pliki JavaScript.
Jeśli Twoja witryna korzysta z dużej ilości treści statycznych, możesz zoptymalizować jej działanie, włączając buforowanie po stronie klienta, w którym przeglądarka przechowuje kopie treści statycznych w celu szybszego dostępu.
Poniższa przykładowa konfiguracja jest dobrym rozwiązaniem. Wystarczy zastąpić www.example.com adresem URL nazwy swojej witryny i odpowiednio zmodyfikować inne nazwy ścieżek.
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;
}
}
Buforuj zawartość dynamiczną w Nginx
NGINX używa trwałej pamięci podręcznej na dysku, zlokalizowanej gdzieś w lokalnym systemie plików. Zacznij więc od utworzenia katalogu na dysku lokalnym do przechowywania zawartości w pamięci podręcznej.
# mkdir -p /var/cache/nginx
Następnie ustaw odpowiednią własność katalogu pamięci podręcznej. Powinien być własnością użytkownika NGINX (nginx) i grupy (nginx) w następujący sposób.
chown nginx:nginx /var/cache/nginx
Teraz przejdź dalej, aby zobaczyć, jak włączyć dynamiczną zawartość w Nginx w poniższej sekcji.
Włączanie pamięci podręcznej FastCGI w NGINX
FastCGI (lub FCGI) to szeroko stosowany protokół do łączenia aplikacji interaktywnych, takich jak PHP, z serwerami internetowymi, takimi jak NGINX mocny>. Jest rozszerzeniem CGI (Common Gateway Interface).
Główną zaletą FCGI jest to, że zarządza wieloma żądaniami CGI w jednym procesie. Bez tego serwer WWW musi otwierać nowy proces (który należy kontrolować, przetwarzać żądanie i zamykać) dla każdego żądania klienta dotyczącego usługi.
Do przetwarzania skryptów PHP we wdrożeniu stosu LEMP, NGINX używa FPM (FastCGI Process Manager) lub PHP-FPM, popularna alternatywna implementacja PHP FastCGI. Po uruchomieniu procesu PHP-FPM, NGINX jest skonfigurowany tak, aby przesyłał do niego żądania proxy w celu przetworzenia. W ten sposób NGINX można również skonfigurować tak, aby buforował odpowiedzi z serwera aplikacji backendu PHP-FPM.
W NGINX pamięć podręczna zawartości FastCGI jest deklarowana przy użyciu dyrektywy o nazwie fastcgi_cache_path w http{} najwyższego poziomu kontekście, w strukturze konfiguracji NGINX. Możesz także dodać fastcgi_cache_key, który definiuje klucz (identyfikator żądania) dla buforowania.
Poza tym, aby odczytać stan nadrzędnej pamięci podręcznej, dodaj dyrektywę add_header X-Cache-Status w kontekście http{} – jest to przydatne do celów debugowania.
Zakładając, że plik konfiguracyjny bloku serwera Twojej witryny znajduje się w /etc/nginx/conf.d/testapp.conf lub /etc/nginx/sites-available/testapp.conf ( w Ubuntu i jego pochodnych), otwórz plik edycji i dodaj następujące wiersze na górze pliku.
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;
Dyrektywa fastcgi_cache_path określa liczbę parametrów, którymi są:
- /var/cache/nginx – ścieżka do katalogu na dysku lokalnym, w którym znajduje się pamięć podręczna.
- levels – definiuje poziomy hierarchii pamięci podręcznej, ustawia dwupoziomową hierarchię katalogów w /var/cache/nginx.
- keys_zone (name:size) – umożliwia utworzenie strefy pamięci współdzielonej, w której przechowywane są wszystkie aktywne klucze oraz informacje o danych (meta). Pamiętaj, że przechowywanie kluczy w pamięci przyspiesza proces sprawdzania, ułatwiając NGINX określenie, czy jest to Błąd, czy HIT, bez sprawdzania stanu na dysku.
- nieaktywne – określa czas, po jakim buforowane dane, do których nie uzyskano dostępu w określonym czasie, zostaną usunięte z pamięci podręcznej niezależnie od ich aktualności. Wartość 60m w naszej przykładowej konfiguracji oznacza, że pliki, do których nie uzyskano dostępu po 60, zostaną usunięte z pamięci podręcznej.
- max_size – określa maksymalny rozmiar pamięci podręcznej. Jest tu więcej parametrów, których możesz użyć (przeczytaj dokumentację NGINX, aby uzyskać więcej informacji).
Zmienne w dyrektywie fastcgi_cache_key opisano poniżej.
NGINX wykorzystuje je do obliczania klucza (identyfikatora) żądania. Co ważne, aby wysłać do klienta odpowiedź z pamięci podręcznej, żądanie musi mieć ten sam klucz, co odpowiedź z pamięci podręcznej.
- $scheme – schemat żądania, HTTP lub HTTPS.
- $request_method – metoda żądania, zwykle „GET” lub „POST”.
- $host – może to być nazwa hosta z linii żądania, nazwa hosta z pola nagłówka żądania „Host” lub nazwa serwera odpowiadająca żądaniu, w kolejności pierwszeństwa .
- $request_uri – oznacza pełny oryginalny URI żądania (wraz z argumentami).
Ponadto zmienna $upstream_cache_status w dyrektywie add_header X-Cache-Status jest obliczana dla każdego żądania, na które odpowiada NGINX, niezależnie od tego, czy jest to MISS (odpowiedź nie znaleziona w pamięci podręcznej, otrzymana z serwera aplikacji) lub HIT (odpowiedź dostarczona z pamięci podręcznej) lub dowolna inna obsługiwana wartość.
Następnie, w ramach dyrektywy location, która przekazuje żądania PHP do PHP-FPM, używa dyrektyw fastcgi_cache do aktywacji pamięci podręcznej, którą właśnie zdefiniowałeś powyżej.
Ustaw także czas buforowania dla różnych odpowiedzi za pomocą dyrektywy fastcgi_cache_valid, jak pokazano.
fastcgi_cache CACHEZONE;
fastcgi_cache_valid 60m;
Jeśli określony zostanie tylko czas buforowania, tak jak w naszym przypadku, buforowane będą tylko odpowiedzi 200, 301 i 302. Ale możesz także określić odpowiedzi jawnie lub użyć dowolnego (dla dowolnego kodu odpowiedzi):
fastcgi_cache CACHEZONE;
fastcgi_cache_valid 200 301 203 60m;
fastcgi_cache_valid 404 10m;
OR
fastcgi_cache CACHEZONE;
fastcgi_cache_valid any 10m;
Dostosowywanie wydajności buforowania FastCGI w Nginx
Aby ustawić minimalną liczbę żądań z tym samym kluczem, zanim odpowiedź zostanie zapisana w pamięci podręcznej, dołącz dyrektywę fastcgi_cache_min_uses w pliku http{} lub serwera{} lub lokalizacji{}.
fastcgi_cache_min_uses 3
Aby włączyć ponowną weryfikację wygasłych elementów pamięci podręcznej przy użyciu żądań warunkowych z polami nagłówka „If-Modified-Since” i „If-None-Match”, dodaj fastcgi_cache_revalidate w kontekście http{}, serwera{} lub lokalizacji{}.
fastcgi_cache_revalidate on;
Możesz także poinstruować firmę NGINX, aby dostarczała zawartość z pamięci podręcznej, gdy serwer pochodzenia lub serwer FCGI nie działa, używając dyrektywy proxy_cache_use_stale w ramach dyrektywy lokalizacji.
Ta przykładowa konfiguracja oznacza, że gdy NGINX odbierze błąd, przekroczenie limitu czasu lub którykolwiek z określonych błędów z serwera nadrzędnego i będzie miał nieaktualną wersję żądanego pliku w treści buforowanej, dostarczy nieaktualny plik.
proxy_cache_use_stale error timeout http_500;
Inną przydatną dyrektywą do dostrojenia wydajności buforowania FCGI jest fastcgi_cache_background_update, która działa w połączeniu z dyrektywą proxy_cache_use_stale. Po włączeniu tej opcji instruuje NGINX, aby udostępniał nieaktualną zawartość, gdy klienci żądają pliku, który wygasł lub jest w trakcie aktualizacji z serwera nadrzędnego.
fastcgi_cache_background_update on;
Blokada fastcgi_cache_lock jest również przydatna do dostrajania wydajności pamięci podręcznej, ponieważ jeśli wielu klientów zażąda tej samej treści, której nie ma w pamięci podręcznej, NGINX przekaże tylko pierwsze żądanie do serwera nadrzędnego, buforuje odpowiedzi, a następnie obsłuż inne żądania klientów z pamięci podręcznej.
fastcgi_cache_lock on;
Po dokonaniu wszystkich powyższych zmian w pliku konfiguracyjnym NGINX zapisz go i zamknij. Następnie sprawdź strukturę konfiguracji pod kątem błędów składniowych przed ponownym uruchomieniem usługi NGINX.
nginx -t
systemctl restart nginx
Następnie sprawdź, czy pamięć podręczna działa poprawnie, spróbuj uzyskać dostęp do swojej aplikacji internetowej lub witryny za pomocą następującego polecenia curl (pierwszy raz powinien wskazywać MISS, ale kolejne żądania powinny wskazywać HIT jak pokazano na zrzucie ekranu).
curl -I http://testapp.linux-console.net
Oto kolejny zrzut ekranu przedstawiający NGINX obsługujący nieaktualne dane.
Dodawanie wyjątków do pomijania pamięci podręcznej
Możliwe jest ustawienie warunków, w których NGINX nie powinno wysyłać odpowiedzi do klientów w pamięci podręcznej, korzystając z dyrektywy fastcgi_cache_bypass. Aby poinstruować NGINX, aby w ogóle nie buforował odpowiedzi z serwera nadrzędnego, użyj fastcgi_no_cache.
Na przykład, jeśli chcesz, aby żądania POST i adresy URL z ciągiem zapytania zawsze trafiały do PHP. Najpierw zadeklaruj instrukcję if, aby ustawić warunek w następujący sposób.
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
Następnie aktywuj powyższy wyjątek w dyrektywie location, który przekazuje żądania PHP do PHP-FPM, używając fastcgi_cache_bypass i fastcgi_no_cache dyrektywy.
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
Istnieje wiele innych części Twojej witryny, dla których możesz nie chcieć włączać buforowania treści. Poniżej znajduje się przykładowa konfiguracja NGINX poprawiająca wydajność witryny WordPress, podana na blogu nginx.com.
Aby z niego skorzystać, wprowadź zmiany (takie jak domena, ścieżki, nazwy plików itp.), aby odzwierciedlić to, co istnieje w Twoim środowisku.
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;
}
}
Włączanie pamięci podręcznej proxy w NGINX
NGINX obsługuje także buforowanie odpowiedzi z innych serwerów proxy (zdefiniowanych w dyrektywie proxy_pass). W tym przypadku testowym używamy NGINX jako odwrotnego proxy dla aplikacji internetowej Node.js, dlatego włączymy NGINX jako pamięć podręczną dla aplikacji Node.js. Wszystkie użyte tutaj dyrektywy konfiguracyjne mają podobne znaczenie jak dyrektywy FastCGI w poprzedniej sekcji, więc nie będziemy ich ponownie wyjaśniać.
Aby włączyć buforowanie odpowiedzi z serwera proxy, dołącz dyrektywę proxy_cache_path w kontekście http{} najwyższego poziomu. Aby określić sposób buforowania żądań, możesz także dodać dyrektywę proxy_cache_key w następujący sposób.
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;
Następnie aktywuj pamięć podręczną w dyrektywie lokalizacji.
location / {
proxy_pass http://127.0.0.1:3000;
proxy_cache PROXYCACHE;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
}
Aby zdefiniować warunki, w których NGINX nie wysyła treści z pamięci podręcznej i w ogóle nie buforuje odpowiedzi z serwera nadrzędnego, uwzględnij proxy_cache_bypass i proxy_no_cache.
proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment;
proxy_no_cache $http_pragma $http_authorization;
Dostosowywanie wydajności pamięci podręcznej proxy
Poniższe dyrektywy są przydatne do dostrajania wydajności pamięci podręcznej proxy. Mają one również takie samo znaczenie jak dyrektywy 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;
Aby uzyskać więcej informacji i wytyczne dotyczące konfiguracji buforowania, zobacz dokumentację dwóch głównych modułów ngx_http_fastcgi_module i ngx_http_proxy_module.
Dodatkowe zasoby: Buforowanie treści NGINX i wskazówki dotyczące poprawy wydajności WordPressa.