Boost Web Performance with OpenResty: Lua Caching, Redis Integration & Auto Updates

1. OpenResty

OpenResty is a high‑performance web platform built on Nginx and Lua, bundling many Lua libraries, third‑party modules and dependencies. It enables rapid development of dynamic web applications, services and gateways that can handle massive concurrency.

2. Nginx + Redis

Typical architecture routes HTTP requests through Nginx to Tomcat, which then reads data from Redis; this chain is serial and blocks if Tomcat fails or its threads are exhausted.

By using the lua-resty-redis module, Nginx can access Redis directly, avoiding Tomcat threads, so requests continue to be served even when Tomcat is down, reducing latency and increasing concurrency.

3. Compression to Reduce Bandwidth

For payloads larger than 1 KB, Nginx compresses the response before storing it in Redis, which speeds up Redis reads and saves bandwidth. Data smaller than 1 KB is left uncompressed to achieve higher TPS because compression consumes CPU.

OpenResty does not provide a built‑in Redis connection pool; a custom Lua implementation is required. Example implementation can be found at

http://wiki.jikexueyuan.com/project/openresty/redis/out_package.html

.

Redis values are stored as JSON objects, e.g. {length:xxx,content:yyy}, where content holds the compressed page and length records the original size to decide whether decompression is needed when reading.

Compression is performed with the lua-zlib library.

4. Periodic Cache Refresh

A Lua timer in Nginx periodically fetches the HTML of a Tomcat page and writes it to Redis. Cache TTL can be set long (e.g., one hour) so that if Tomcat crashes the cached page is still returned, while the refresh interval can be short (e.g., one minute) to keep data fresh.

5. Request Forwarding Logic

Nginx first tries to read the page HTML from Redis.

If the key is missing, Nginx retrieves the page from Tomcat, updates Redis, and returns the HTML to the client.

The client receives the HTML regardless of Tomcat’s state.

6. Single‑Process Timer Execution

All Nginx worker processes can handle request forwarding, but only worker 0 runs the periodic update task. The worker ID is obtained with ngx.worker.id().

7. Configurable Caching via Management Backend

Cacheable URLs, expiration time, and refresh interval can be configured through a management interface. Example query string:

modify?url=index&&expire=3600000&&intervaltime=300000&&sign=xxxx

The sign parameter is a signature generated with the backend’s secret key; Nginx validates the signature using the same secret key before applying the configuration.