Performance issue With LiteSpeed Object Caching

Nobody has claimed this yet.

We have an auto-scaling WordPress setup which uses LiteSpeed Cache plugin in AWS. ElatiCache for Redis is used for Object Cache by the LiteSpeed Cache plugin. We recently encountered an issue where our website becomes slow and sometimes returns gateway time-out error. Below is the log entry we observed in our log file.

----------

PHP Fatal error: Uncaught RedisException: read error on connection to test-redis-001.gedshy.0001.aps1.cache.amazonaws.com:6379 in /usr/local/lsws/web/wp-content/plugins/litespeed-cache/src/object-cache.cls.php:463

----------

We could not find any exhaused resource metrics in ElastiCache. On further reviewing we found that that is a key in Redis "a83a2options.permalink-manager-uris" which is having approx. 8MB size. Below is the output of the command we have used to identify

----------

root@ip-10-0-25-45:~# redis-cli -h test-redis-v2.gedshy.ng.0001.aps1.cache.amazonaws.com --bigkeys

# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).

[00.00%] Biggest string found so far '"a83a2types_cache.41cf94d8687fbad660683a3991a6b4ef"' with 231 bytes
[00.00%] Biggest string found so far '"a83a2types_cache.43a9ed03514dfb402e352bb1dbb3f0c7"' with 337 bytes
[00.01%] Biggest string found so far '"a83a2types_cache.837751288f9f9a72098a8e973c760e79"' with 1091 bytes
[00.01%] Biggest string found so far '"a83a2post-queries.wp_query:22c79ad127d8ac5ab7fd3773bd15a81f:0.88600200 1749100211"' with 1678 bytes
[00.01%] Biggest string found so far '"a83a2posts.381737"' with 3480 bytes
[00.01%] Biggest string found so far '"a83a2post_meta.560886"' with 7145 bytes
[00.06%] Biggest string found so far '"a83a2post_meta.66152"' with 20125 bytes
[00.07%] Biggest string found so far '"a83a2posts.532151"' with 66476 bytes
[00.14%] Biggest string found so far '"a83a2posts.10312"' with 88629 bytes
[00.18%] Biggest string found so far '"a83a2post-queries.wp_query:021e77b22836100670711e01090152ba:0.52070100 17491003660.79208400 1749100355"' with 407917 bytes
[06.32%] Biggest string found so far '"a83a2options.alloptions"' with 492702 bytes
[14.67%] Biggest string found so far '"a83a2options.permalink-manager-uris"' with 8344570 bytes

-------- summary -------

Sampled 305290 keys in the keyspace!
Total key length in bytes is 16145056 (avg len 52.88)

Biggest string found '"a83a2options.permalink-manager-uris"' has 8344570 bytes

0 lists with 0 items (00.00% of keys, avg size 0.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
305290 strings with 153937741 bytes (100.00% of keys, avg size 504.23)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)
root@ip-10-0-25-45:~#
-----------

We are not sure if this is the root cause behind the downtime.

The website have a traffic of nearly 1500 requests per sec. This count may increase sometimes. This issue mainly started on Jun 4, 2025. Need to understand why this issue started all of a sudden even when there is no change in application code.

We have done a work around for the time being to automatically disable LiteSpeed Cache plugin, then reboot the ElastiCache and finally enable the LiteSpeed Cache plugin. This resolves the issue with a minimal downtime without any manual intervention.

But we need to identify the Root cause of the issue and fix that. One thing we suspect is the 8 MB size of that key.

I would like to understand if the Key size will cause performance issue to our website or if its something else.

Start with src/object-cache.cls.php around line 463 and trace how Redis read errors are handled by the LiteSpeed Cache plugin. Compare the 8 MB permalink-manager-uris value with the reported Redis exception, traffic, and ElastiCache behavior; done means establishing whether the key size is causal and identifying a supported fix or mitigation.

Written by the indexing model from the issue text.