Nginx configuration FastCGI Cache Method Introduction

This article brings to you the content is about Nginx configuration FastCGI Cache method Introduction, there is a certain reference value, the need for friends can refer to, I hope you have some help.

Caching mechanism

Nginx provides proxy-based and fastcgi-based caching methods, the instruction set is very similar, the use of the difference is not small. Because this site blog uses NGINX+PHP-FPM architecture, therefore uses the fastcgi-based cache, namely fastcgi cache.

Configuration

The fastcgi cache is a mechanism for caching the pages returned by the backend CGI service, returning the page directly when subsequent requests arrive, eliminating the consumption of communication with the backend service and generating the page. FastCGI cache is similar to squid, varnish, CDN and so on, in principle performance will be much higher than WordPress's various cache plugins due to reduced backend requests.

The fastcgi cache is part of the FastCGI module, and the FastCGI module belongs to the HTTP module, so the cache-related configuration should appear in both and subordinate configuration blocks (mainly HTTP, server, and location).

According to the official documentation, the blog site uses the following cache configuration:

HTTP {... fastcgi_connect_timeout 30s; # Global Settings, Fastcgi_cache_path can only appear in the HTTP configuration block # Fastcgi_cache_path Set the global cache path, file size, etc., you can set up a different cache pool multiple times fastcgi_cache_path/var/  Cache/nginx levels=1:2 keys_zone=wordpress:10m inactive=10m max_size=500m;  Fastcgi_cache_key $scheme $request_method$host$request_uri;  # Set the case for using outdated cache: Backend error, timeout, etc. fastcgi_cache_use_stale error timeout invalid_header http_500 http_503;    The.. server {... # cache policy indicates the variable set $skip _cache 0;    # Cache Policy if ($query _string! = "") {set $skip _cache 1; } if ($request _uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|sitemap (_index)?.    XML ") {set $skip _cache 1; # login user or post a reviewer if ($http _cookie ~* "Comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logg    Ed_in ") {set $skip _cache 1;      } location ~ \.php$ {... # uses the Keyzone, which uses HTTP as defined in WordPress fastcgi_cache WordPress;      # Whether to skip cache fastcgi_cache_bypass $skip _cache;      Fastcgi_no_cache $skip _cache; # back end returns a successful situationCache 10 minutes Fastcgi_cache_valid 10m;    # Add header field to indicate cache hit status (debug use) Add_header X-cache $upstream _cache_status; }  }}

The above configuration does the following work:

1. Set Cache pool information (fastcgi_cache_path);

2. Set the Cache key (Fastcgi_cache_key);

3. Expired file processing (Fastcgi_cache_use_stale)

4. Cache Policy (Fastcgi_cache_bypass/fastcgi_no_cache)

5. Cache time when backend request succeeds (Fastcgi_cache_valid)

6. Added debug information header (Add_header)

Restart Nginx, then visit the page to view the page header status and response time. As you can see, the request is over (the number can be fastcgi_cache_min_uses set), and subsequent requests are from the cache request (the X-cache value is hit), and the speed increase is noticeable. For the admin background page, x-cache the value is BYPASS exactly what we need.