Boost Web Performance with OpenResty: Redis Caching, Compression, and Dynamic Updates

1. OpenResty

OpenResty is a high‑performance web platform built on Nginx and Lua, bundling many useful Lua libraries, third‑party modules, and dependencies. It enables developers to create highly concurrent, scalable dynamic web applications, services, and gateways.

2. Nginx + Redis Architecture

The typical architecture routes HTTP requests through Nginx load‑balancing to Tomcat, which then reads data from Redis. This chain is serial; if Tomcat fails or its threads are exhausted, the response cannot be returned.

By using OpenResty’s lua‑resty‑redis module, Nginx can access Redis directly, bypassing Tomcat threads. Even if Tomcat is down, Nginx can still serve requests, reducing response time and increasing system concurrency.

3. Compression to Reduce Bandwidth

For data larger than 1 KB, compress it in Nginx before storing it in Redis:

Improves Redis read speed

Reduces bandwidth consumption

Compression consumes CPU; for data smaller than 1 KB, skipping compression yields higher TPS.

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

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

.

Store Redis values as JSON, e.g. {"length":xxx,"content":yyy}, where content is the compressed page and length records the original size to decide whether decompression is needed on read.

Use the lua‑zlib library for compression.

4. Timed Updates

Set up a timer (steps 1 and 2 in the diagram) where an Nginx Lua timer periodically requests the Tomcat page URL, saves the returned HTML into Redis.

Cache TTL can be relatively long (e.g., 1 hour) to tolerate Tomcat failures, while the update interval can be short (e.g., 1 minute) to keep the cache fresh.

5. Request Forwarding Flow

When a browser requests a page:

Nginx first tries to fetch the HTML from Redis.

If Redis has no entry, Nginx retrieves the page from Tomcat, updates Redis, and serves the content.

The HTML is returned to the browser.

6. Single‑Process Timed Update

All Nginx worker processes can handle front‑end request forwarding to Redis, but only worker 0 runs the periodic update task. The Lua script obtains the worker ID via ngx.worker.id().

7. Configurable Caching via Management Backend

Cacheable URLs, TTL, and update intervals can be configured through a management interface. Example request:

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

The sign value is generated by applying a secret key to the same parameter string (without sign) and serves as an authentication token. Nginx validates the signature before applying the configuration changes.