Nginx cache usage

A web cache sits between the client and the "origin server" and keeps a copy of all visible content. If a client requests content that is stored in the cache, the content can be obtained directly from the cache without communicating with the server. (Recommended learning: nginx use )

This way, because the web cache is "closer" from the client, it can improve the response performance, and more efficiently use applications and apply it more efficiently. Server, because the server does not need to generate the page for every request.

Between the browser and the application server, there are multiple "potential" caches, such as: client browser cache, intermediate cache, content delivery network (CDN) and load balancing and reverse proxy on the server . Caching, just at the level of reverse proxy and load balancing, can be a big help in improving performance.

For example, last year, I took over a task, which was to optimize the performance of a website that was loading slowly.

The first thing that caught my attention is that this website took almost more than 1 second to generate the home page. After a series of debugging, I found that the reason for the slow loading was that the page was marked as non-cacheable, that is, the page was dynamically generated in response to every request.

Since the page itself does not require frequent changes and does not involve personalization, it is not necessary to do so.

In order to verify my conclusion, I marked the page to be cached every 5 seconds. Just by making this adjustment, I can obviously feel the performance improvement. The time to the first byte is reduced to a few milliseconds, and the page loads significantly faster.

It's not just large-scale content delivery networks (CDNs) that can benefit from using caching - caching can also improve the performance of load balancers, reverse proxies and application server front-end web services.

Through the above example, we see that caching content results can use the application server more efficiently because there is no need to do repeated page generation work every time. In addition, web caching can also be used to improve website reliability.

When the server is down or busy, instead of returning an error message to the user, it is better to configure NGINX to send the cached content to the user. This means that the website can maintain some or even all functions in the event of application server or database failure.

How to install and configure the basic cache

We only need two commands to enable the basic cache: proxy_cache_path and proxy_cache. proxy_cache_path is used to set the cache path and configuration, and proxy_cache is used to enable caching.

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

proxy_pass http://my_upstream;

}

}

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

2.levels sets a two-level hierarchy directory in /path/to/cache/ .

Placing a large number of files in a single directory can cause 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 up a shared memory area, which is used to store cache keys and metadata, somewhat similar to the use of timers.

Putting a copy of the key into memory allows NGINX to quickly decide whether a request is a `HIT` or a `MISS` without retrieving the disk, which greatly improves the retrieval speed.

A 1MB memory space can store approximately 8,000 keys, so the 10MB memory space configured above can store almost 80,000 keys.

4.max_size sets the upper limit of the cache (10G in the above example). This is optional; not specifying a value allows the cache to grow and consume 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 the time the item can be kept in memory without being accessed. In the above example, if a file is not 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 will not automatically delete expired content specified by the cache control header (Cache-Control:max-age=120 in this example).

Expired content will be deleted only if it has not been accessed within the specified time of inactive.

If expired content is accessed, NGINX will refresh it from the original server and update the corresponding inactive timer.

6. NGINX will initially put the files destined to be written to 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 the parameter to off to avoid unnecessary data copies in the file system. use_temp_path was introduced in NGINX version 1.7 and NGINX Plus R6.

Finally, the proxy_cache command starts caching content whose URL matches the location part (in this case, `/`). You can also add the proxy_cache command to the server section, which will apply the cache to all services whose locations do not specify their own proxy_cache command.

The above is the detailed content of Nginx cache usage. For more information, please follow other related articles on the PHP Chinese website!