Nginx Server enforces caching configuration and caching priorities _nginx

Source: Internet
Author: User
Tags current time php code nginx server

Nginx Agent done, the cache is also configured, but found that CSS, JS, jpg these static files are all cached success. But the page file is still to the source server.
1. Nginx does not cache reason
by default, whether the cache is nginx by the Nginx cache server is determined by the source server, and the caching server needs to strictly follow the header of the source server response to determine whether caching and caching is frequent. Headers are mainly as follows:

Cache-control:no-cache, No-store

If these two values are present, the Nginx cache server is definitely not cached

Expires:1980-01-01

If the date appears earlier than the current time, it is not cached.

2. Solve the non-caching scheme
2.1 Method One:
To modify the header of a program or source server Web program response

2.2 Method Two:
The Nginx agent directly adds the following sentence:

Proxy_ignore_headers x-accel-expires Expires Cache-control Set-cookie; 

3. Cache Priority
3.1 Frame composition
Client Side <------------------> Nginx cache <------------------> Source server
After a lot of testing, Nginx's expiration order has a priority. The following first describes each of the factors that affect cache expiration:
(1) Inactive: configured in the Proxy_cache_path configuration entry to indicate that a cache will be removed from the cache if it is not accessed within the time specified by inactive.
(2) The expires in the response header generated in the Source server PHP page, and the resulting statement is:
Header ("Expires:fri, Modified Sep 2013 08:05:18 GMT");
(3) Source server PHP page generated by the Max-age, generated statements are:
Header ("cache-control:max-age=60");
(4) Nginx configuration item Proxy_cache_valid: Configure cache time for cached files in Nginx cache, if the configuration item is: Proxy_cache_valid 304 2m; Shows that cached files with status 200 and 304 have a cache time of 2 minutes and two minutes before accessing the cached file, the file expires and the source server is fetched again.
3.2 Second to note: The source server expires and Nginx cache expires configuration items of the conflict is described, the scenario is as follows
(1) The source server side has php file ta1.php content as follows:

<?php
Header ("Expires:fri, Modified Sep 2013 08:05:18 GMT");
Header ("last-modified:"). Gmdate ("D, D M Y h:i:s"). "GMT");
Header ("cache-control:max-age=60");
echo "Ta1";
? >

(2) The configuration information on the Nginx cache server side is as follows:

..... 

From the above two items can be seen in the Nginx cache server expires configuration is 30s, the expires value directly determines the browser to see the Max-age and expires values. And in the source server broken code in the response header set in the Max-age is 60,expires for Fri, the SEP 2013 08:05:18 GMT. This is the source server settings in the Nginx-cache settings conflict, then the two properties should be how to set it?
The client-side max-age and expires values are set according to the expires configuration item in Nginx cache, namely:

Expires Fri, Sep 08:59:16 GMT
cache-controlmax-age=30

The cached max-age and expire values on the Nginx cache are set according to the code on the source server. That

Expires Fri, Modified SEP 2013 08:05:18 GMT
cache-controlmax-age=60

Now to the point:
3.3 After a large number of tests found that the expiration of the cache and elimination of factors that affect the priority from high to low once:
Inactive configuration items, expires for source server settings, Max-age for source server settings, proxy_cache_valid configuration items
These priority levels are described in several instances below
Example 1:
Server-side PHP code:

<?php
Header ("Expires:fri, 08:03:18 GMT");/In fact, 3 minutes later
header ("Last-modified:". Gmdate ("D, D M Y h:i:s"). "GMT");
Header ("cache-control:max-age=180");//2 min
//header ("cache-control:post-check=0, pre-check=0", false)
; echo "Ta1";
? >

Nginx Cache Configuration Entry

Inactive 4M//4 minutes
proxy_cache_valid 1m//1 minutes

Phenomenon: After the first visit to the page ta1.php, the results of each time access:

    • 1 minutes later: hit//This means valid didn't work.
    • 2 minutes later: hit//This indicates that the max-age of the source server settings did not work
    • 3 minutes later: miss//This means that the expires of the source server settings works.
    • 4 minutes later: miss//This means inactive's working.

Example 2:

Server-side PHP code:

<?php
Header ("Expires:fri, 08:03:18 GMT");//3 minutes later
header ("Last-modified:". Gmdate ("D, D M Y h:i:s"). "GMT");
Header ("cache-control:max-age=180");//2 min
//header ("cache-control:post-check=0, pre-check=0", false)
; echo "Ta1";
? >

Nginx Cache Configuration Entry

Inactive 10s//10 seconds
proxy_cache_valid 1m//1 minutes

Phenomenon: After the first visit to the page ta1.php, the results of each time access:

    • 5 Seconds to visit: HIT
    • 10 seconds to visit: MISS
    • 15 seconds to visit: HIT
    • 20 seconds to visit: MISS

Comprehensive analysis through instance 1 and instance 2: If inactive has already been set, the cache expiration is based on the value set by inactive

Example 3:
Server-side PHP code:

<?php
Header ("Expires:fri, Modified SEP 1977 08:03:18 GMT");//Direct Expired
header ("Last-modified:". Gmdate ("D, D M Y h:i:s"). "GMT");
Header ("cache-control:max-age=120");//2 min
//header ("cache-control:post-check=0, pre-check=0", false)
; echo "Ta1";
? >

Nginx Cache Configuration Entry

Inactive 4M//4 minutes
proxy_cache_valid 1m//1 minutes

Phenomenon: After the first visit to the page ta1.php, the results of each time access:
Access once every second: miss//This means that the expires of the source server side masks the Nginx valide and the max-age of the source server settings.
Example 4:
Server-side PHP code:

<?php
Header ("Expires:fri, 08:03:18 GMT");//3 minutes later
header ("Last-modified:". Gmdate ("D, D M Y h:i:s"). "GMT");
Header ("cache-control:max-age=120");//2 min
//header ("cache-control:post-check=0, pre-check=0", false)
; echo "Ta1";
? >

Nginx Cache Configuration Entry

Inactive 4M//4 minutes

proxy_cache_valid 1m//1 minutes

Phenomenon: After the first visit to the page ta1.php, the results of each time access:

    • 1 minutes later: hit//This indicates that valid did not work because the expires of the source server set the valid effect to block
    • 2 minutes later: hit//This indicates that the max-age of the source server settings did not work because the expires of the source server settings Max-age blocked
    • 3 minutes later: miss//This means that the expires of server-side settings works.

The phenomenon of instance 2 and instance 3 shows that if the inactive setting is large, the Max-age set on the server side is set if the expires of the valid, server-side settings expires, server-side settings are inactive.

Example 5:
Server-side PHP code:

<?php
Header ("Expires:fri, 08:03:18 GMT");//3 minutes later
header ("Last-modified:". Gmdate ("D, D M Y h:i:s"). "GMT");
Header ("cache-control:max-age=120");//2 min
//header ("cache-control:post-check=0, pre-check=0", false)
; echo "Ta1";
? >

Nginx Cache Configuration Entry

Inactive 4M//4 minutes
#下面两行用于消除服务器端配置的Expires响应头的影响
proxy_ignore_headers "Expires";
Proxy_hide_header "Expires";
Proxy_cache_valid 1M//1 minutes

Phenomenon: After the first visit to the page ta1.php, the results of each time access:

    • 1 minutes later HIT//This shows that valid's role has been blocked by server-side Max-age
    • After 2 minutes, miss//server-side settings max-age work

Example 6:

Server-side PHP code:

<?php
Header ("Expires:fri, 08:03:18 GMT");//3 minutes later
header ("Last-modified:". Gmdate ("D, D M Y h:i:s"). "GMT");
Header ("cache-control:max-age=50");//50 Seconds
//header ("cache-control:post-check=0, pre-check=0", false)
; echo "Ta1";
? >

Nginx Cache Configuration Entry

Inactive 4M//4 minutes
#下面两行用于消除服务器端配置的Expires响应头的影响
proxy_ignore_headers "Expires";
Proxy_hide_header "Expires";
Proxy_cache_valid 2M//2 minutes

Phenomenon: After the first visit to the page ta1.php, the results of each time access:

    • After 50 seconds: miss//This indicates that the max-age of the server-side configuration works
    • 1 minutes later: hit//
    • After 100 seconds: miss//This means that the max-age of server-side settings works.

The phenomenon of instance 5 and instance 6 illustrates that if the inactive settings are larger, and the server-side expires effect on the cache is eliminated in the Nginx configuration file. With the Proxy_cache_valid and server-side Set Max-age response header fields set, the server-side Max-age value is used as the standard for cache expiration.

3.4 To sum up:
(1) At the same time set the source server-side expires, source server-side max-age and Nginx Cahe end of the proxy_cache_valid, the source server-side set the value of the expires to the standard cache of expired processing
(2) If the relevant configuration items are configured in the Nginx, the effect of the expires on the cache is eliminated, and the source server expires, the source server max-age and the Nginx Cahe end are set up. Cache expiration with the value of the source server-side Max-age
(3) If the source server-side expires and the source-server-side max-age on the cache are also eliminated, the cached expiration is treated with the value set by Proxy_cache_valid as the standard
(4) The value of the inactive is not affected by the above three factors, that is, after the first request page, every Inactvie specified time, to force the corresponding cache cleanup. Therefore, the inactive has the highest priority.
(5) So the priority of the cache expiration effect is sorted as follows: Inactvie, source server-side expires, source-server-side max-age, Proxy_cache_valid


Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.