Nginx content cache and common parameter configuration details

Use scenarios:

The project's pages need to load a lot of data, which does not change frequently and does not involve personalized customization. Dynamically generating data for each request will not perform as well as caching the results based on request routing and parameters. Using Nginx cache will greatly increase request speed.

Base

You only need to configure proxy_cache_path and proxy_cache to enable content caching. The former is used to set the cache path and configuration, and the latter is used to enable caching.

http {
 ...
 proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

 server {
 proxy_cache mycache;
 location / {
  proxy_pass http://localhost:8000;
 }
 }
}

Corresponding parameter description:

1. The local disk directory used for caching is /path/to/cache/

2.levels sets up a two-level hierarchy directory in /path/to/cache/. Placing a large number of files in a single directory can result in slow file access, so for most deployments we recommend a two-level directory hierarchy. If the levels parameter is not configured, NGINX will place all files in the same directory.

3.keys_zone sets a shared memory zone, which is used to store cache keys and metadata, which is somewhat similar to the purpose of a timer. Putting a copy of the key in memory allows NGINX to quickly determine whether a request is a HIT or MISS without searching the disk, which greatly improves search speed. A 1MB memory space can store about 8,000 keys, so the 10MB memory space configured above can store about 80,000 keys.

4. max_size sets the upper limit of the cache (10G in the above example). This is optional; if you don't specify a value, the cache is allowed to grow continuously, occupying all available disk space. When the cache reaches this limit, the processor calls the cache manager to remove the least recently used files, thus reducing the cache space to below this limit.

5.inactive specifies how long an item can remain in memory without being accessed. In the above example, if a file has not been requested within 60 minutes, the cache manager will automatically delete it from memory, regardless of whether the file has expired. The default value of this parameter is 10 minutes (10m). Note that inactive content is different from expired content. NGINX does not automatically delete expired content specified by the cache-control header (in this case, Cache-Control:max-age=120). Expired content will only be deleted if it has not been accessed within the inactive time specified. If expired content is accessed, NGINX will refresh it from the original server and update the corresponding inactive timer.

6. NGINX will initially place files destined for the cache into a temporary storage area. The use_temp_path=off command instructs NGINX to write these files to the same directory when caching them. We strongly recommend that you set this parameter to off to avoid unnecessary copying of data in the file system. use_temp_path was introduced in NGINX version 1.7 and NGINX Plus R6.

Finally, the proxy_cache directive enables caching of content for URLs that match the location portion (in this case, /). You can also add a proxy_cache directive to the server section, which will apply caching to all servers in the location that do not specify their own proxy_cache directive.

Nginx cache related processes

There are two additional NGINX processes involved in caching:

• The cache manager starts periodically to check the status of the cache. If the cache size exceeds the limit set by the max_size parameter in proxy_cache_path, the cache manager deletes recently accessed data. In the interval between two cache manager startups, the amount of cached data may temporarily exceed the configured size.
• The cache loader runs only once, after NGINX starts. It loads metadata about previously cached data into the shared memory area. Loading the entire cache at once might consume enough resources to degrade NGINX performance in the first few minutes after startup. To avoid this, configure iterative loading of the cache by including the following parameter in the proxy_cache_path directive:
  • loader_threshold – iteration duration in milliseconds (200 by default)
  • loader_files - Maximum number of items loaded during one iteration (100 by default)
  • loader_sleeps - delay between iterations, in milliseconds (50 by default)

In the following example, iterations last for 300 milliseconds or until 200 items have been loaded:

proxy_cache_path /data/nginx/cache keys_zone=one:10m loader_threshold=300 loader_files=200;

Other common parameters

Configuration example:

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

server {
 ...
 location / {
  proxy_cache my_cache;
  # proxy_cache_key "$host$request_uri$cookie_user"; proxy_cache_min_uses 3;
  proxy_cache_methods GET HEAD POST;
  proxy_cache_valid 200 302 10m;
  proxy_cache_valid 404 1m;
  # proxy_cache_valid any 5m; proxy_pass http://localhost:8000;
 }
}

Corresponding parameter description:

• proxy_cache_key specifies the cache key to change the request characteristics used when calculating the key. This is not recommended. An example is to use the domain name, request URL, and user cookie as the key, which means that a page will be cached n times for different users. In most cases, such an operation is not required.
• proxy_cache_min_uses is the minimum number of requests that must use the same key before the response is cached.
• proxy_cache_methods specifies the response values ​​of the request methods to be cached. The default values ​​are GET and HEAD. If other methods are added, they need to be listed together, as shown in the example above.
• proxy_cache_valid is the cache time of the response status code. In this example, you can specify a cache time for each status code, or use any to cache all status codes.

Clear the cache

A configuration needs to be added in advance to identify requests using the HTTP PURGE method and delete the cache corresponding to the matching URL.

1. Create a new variable in the http {} context, such as $purge_method, which depends on the $request_method variable:

http {
 ...
 map $request_method $purge_method {
  PURGE 1;
  default 0;
 }
}

2. In the location {} block, if the cache has been configured, introduce the proxy_cache_purge parameter to specify the conditions for clearing cache requests. For example, in the previous step, specify $request_method

server {
 listen 80;
 server_name www.example.com;

 location / {
  proxy_pass https://localhost:8002;
  proxy_cache mycache;

  proxy_cache_purge $purge_method;
 }
}

After configuring and making it effective, you can send a purge request to invalidate the cache, for example:

curl -X PURGE -D – https://www.example.com/*

In this example, resources with a public URL portion (specified by the asterisk wildcard character) are purged. However, these cache entries are not completely removed from the cache: they remain on disk until they are deemed inactive (determined by the inactive parameter in proxy_cache_path), or until the cache is purged (determined by purge in proxy_cache_path), or until a client attempts to access them.

Reference Links:

• Official Guide to Using Nginx Cache
• Nginx Content Caching Documentation

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM.