Improved Redis config

[melroy89]

Me again. Here is an improved Redis config, which you most want to try with m7a.large or m7a.xlarge (or higher AWS instances). Increase io-threads when needed.

I'm actually using Valkey myself, but since it's a fork of Redis. This configuration should just work fine! I'm curious if it makes the difference!

Brief explanation:

• tcp-keepalive: Try to increase the keepalive ensures idle TCP connections remain active. Most likely will not make a huge difference in your test, but on production use case it might.
• allkeys-lru: Redis evicts the least recently used keys, regardless of their type or expiration status. This maximizes memory efficiency by keeping frequently accessed data in memory. There are other options as well. On a Symfony setup I use volatile-ttl for example.
• lazyfree-lazy-eviction yes: Instead of synchronously freeing memory during eviction (which could cause latency spikes), it offloads memory cleanup to a background thread.
• lazyfree-lazy-expire yes: With this setting, expired keys are lazily deleted in the background. This reduces blocking operations, especially for large keys.
• lazyfree-lazy-server-del yes: When commands like FLUSHALL or FLUSHDB are issued, Redis typically deletes all keys synchronously, which can be resource-intensive.
• replica-lazy-flush yes: When enabled, the flush operation is performed lazily in the background, reducing latency during replication processes.
• lazyfree-lazy-user-del yes: for deleting keys, Redis will delete those keys asynchronously using lazy freeing.
• lazyfree-lazy-user-flush yes: If custom commands trigger a flush operation (e.g., to clear a database), those flushes are handled in the background using lazy freeing.
• io-threads 2: With multi-threading enabled, Redis can process certain network I/O tasks.. Valkey give better performance here. But you can play around and increase if needed if you have more vCPUs.
• io-threads-do-reads yes: Redis can use I/O threads to read requests from clients in parallel, improving performance under high network load.

Last but not least, I also try to use unixsocket to reduce the network overhead, but that depends on the stack.

[melroy89]

You're welcome. I wanted to add that if you are testing KeyDB as well, then the IO threads option is called differently under KeyDB. When using KeyDB, use: server-threads 2
(or again, since any other higher number of threads depending on your AWS instance).