Redis in Appwrite has high latency spikes – possible link to function timeouts

Hello,

We are running a self-hosted Appwrite 1.5.10 on Debian 12 Bookworm (Docker Compose). Redis is used exclusively as part of the Appwrite stack (Pub/Sub, queue, realtime). Our mobile app (iOS/Android) communicates with Appwrite through ~40 functions, which call an external API and return JSON or file data.

Problem

Using redis-cli LATENCY DOCTOR, we observe regular spikes in the fast-command category. Average ~7 ms, with peaks up to ~40 ms.

Spikes occur even under normal load, with Redis having sufficient CPU and RAM available.

We suspect these latency spikes may be causing timeouts in Appwrite functions.

Steps taken so far

Our Docker Compose configuration is otherwise unmodified, but we tested pinning Redis to a dedicated CPU core and increasing its process priority — no improvement.

Questions

1. Is it expected in Appwrite that execution.responseBody is passed through Realtime/PubSub (Redis) in full size? Is there a way to limit this data (e.g., large JSONs or binary files)?

2. Are there any recommended settings or tuning steps to reduce Redis latency in the context of Appwrite (Appwrite config, Redis tuning, or disabling certain internal events)?

3. Could these fast-command spikes realistically lead to function timeouts?

Thank you for any guidance.

Best regards,

Latency doctor log: /data # redis-cli LATENCY DOCTOR
Dave, I have observed latency spikes in this Redis instance. You don't mind talking about it, do you Dave?

1. fast-command: 10 latency spikes (average 7ms, mean deviation 4ms, period 73.30 sec). Worst all time event 15ms.

I have a few advices for you:

• The system is slow to execute Redis code paths not containing system calls. This usually means the system does not provide Redis CPU time to run for long periods. You should try to:
  1. Lower the system load.
  2. Use a computer / VM just for Redis if you are running other software in the same system.
  3. Check if you have a "noisy neighbour" problem.
  4. Check with 'redis-cli --intrinsic-latency 100' what is the intrinsic latency in your system.
  5. Check if the problem is allocator-related by recompiling Redis with MALLOC=libc, if you are using Jemalloc. However this may create fragmentation problems.

Ist from max load. Normal is 0.5