Enable HTTP Cache in OpenResty Edge
Today I’d demonstrate how to enable HTTP response caching in OpenResty Edge.
When the client requests hit the cache on the Edge Node server, no requests need to be sent to the backend server. This reduces response latency and saves network bandwidth.
Let’s go to the OpenResty Edge’s Admin web console. This is our sample deployment of the console. Every user has her own deployment.
We can continue with our previous application example, test-edge.com.
We already have an upstream defined.
This my_backend upstream has only 1 backend server.
Note the IP address of the backend server ends with number 191. We will use this IP address later.
And we also have a page rule already defined.
This page rule sets up a reverse proxy to this upstream.
Apparently we haven’t enabled the proxy cache for this page rule yet.
Now let’s edit this page rule to add response caching in the gateway.
Let’s enable the proxy cache.
Here we can configure the cache key.
By default, the cache key consists of two components: the URI, and the query string.
You can choose to use other kinds of key components.
Or we can remove the whole query string from the key.
We can also add even more key components.
For this example, we’ll just keep the default cache key.
Save this page rule.
Let’s make a new release.
Push out our pending changes.
Ship it!
Our new release is now synchronized to all our gateway servers.
Our configuration changes do NOT require server reload, restart, or binary upgrade. So it’s very efficient.
Let’s test a gateway server for caching.
We copy the IP address of this San Francisco gateway server.
Note the last number of this IP address is 133.
On the terminal, we send an HTTP request to this gateway server via the curl command-line utility.
1 | curl -I -H 'Host: test-edge.com' http://138.68.231.133/ |
Note the Cache-Status: MISS response header returned.
Do it again.
1 | curl -I -H 'Host: test-edge.com' http://138.68.231.133/ |
We are still getting the Cache-Status: MISS header. It means that the cache is not used at all. Why? Because the original response header from the backend server lacks headers like Expires and Cache-Control.
We can log onto the backend server.
1 | ssh ec2-user@54.213.103.191 |
Recall that the backend server’s IP address ends with 191.
This backend server runs the open source OpenResty software.
1 | ps aux | grep nginx |
The backend server may run any other software that speaks HTTP.
We can send a test request to this backend server directly.
1 | curl -I -H 'Host: test-edge.com' http://127.0.0.1/ |
Note that we are accessing the local host.
Okay, it indeed does not provide any Expires or Cache-Control headers.
Now let’s re-configure our backend server.
1 | cd /usr/local/openresty/nginx/ |
Open the nginx configuration file.
1 | sudo vim conf/nginx.conf |
Find our root location, location /.
And add an expiration time of 1 hour.
1 | expires 1h; |
Note that the backend server can define different expiration times for different locations. Or disable the cache completely for certain responses.
Save and quit the file.
Test if the nginx configuration file is correct.
1 | sudo ./sbin/nginx -t |
Good.
Now reload the server.
1 | sudo kill -HUP `cat logs/nginx.pid` |
Note that for open source Nginx servers, the configuration is also the same.
Time to test the backend server again.
1 | curl -I -H 'Host: test-edge.com' http://127.0.0.1/ |
Yay! It responds with the Expires and Cache-Control headers now.
Send the request to the gateway server instead.
1 | curl -I -H 'Host: test-edge.com' http://138.68.231.133/ |
It still shows the Cache-Status: MISS header.
It is an expected cache miss. Because this is our very first request.
Send the request again.
1 | curl -I -H 'Host: test-edge.com' http://138.68.231.133/ |
Great! We finally see the Cache-Status: HIT header!
So it is now a cache hit as expected.
If we add a query string,
1 | curl -I -H 'Host: test-edge.com' 'http://138.68.231.133/?a=3' |
Note the a=3 part.
then it will be a cache miss again.
This is because the default cache key includes the query string.
Running the same request again should result in a cache hit.
1 | curl -I -H 'Host: test-edge.com' 'http://138.68.231.133/?a=3' |
It’s indeed a cache hit now. If you don’t care about the query string, you can remove it from the cache key.
Sometimes we are just too lazy to change the backend server’s configuration. Then we can also enforce caching for responses without any cache controlling headers in the gateway.
We can change our original page rule to enable this feature.
We enforce caching by default.
We can set the default expiration time for cacheable response status codes.
We’ll demonstrate this feature in another video.
If you like this tutorial, please subscribe to this blog site and/or our Vimeo account and/or our YouTube channel. Thank you!
About This Article and Associated Video
This article and its associated video are both generated automatically from a simple screenplay file.
About The Author
Yichun Zhang is the creator of the OpenResty® open source project. He is also the founder and CEO of the OpenResty Inc. company. He contributed a dozen open source Nginx 3rd-party modules, quite some Nginx and LuaJIT core patches, and designed products like OpenResty XRay and OpenResty Edge.
Translations
We provide the Chinese translation for this article on blog.openresty.com.cn. We welcome interested readers to contribute translations in other natural languages as long as the full article is translated without any omissions. We thank them in advance.
We are hiring
We always welcome talented and enthusiastic engineers to join our team at OpenResty Inc.
to explore various open source software’s internals and build powerful analyzers and
visualizers for real world applications built atop the open source software. If you are
interested, please send your resume to talents@openresty.com . Thank you!
