🐛Lack of Clear Guidelines for server-threads and io-threads Configuration in Production Environments

[luxdo]

Hello KeyDB Team,

First of all, thank you for continuing the development of KeyDB under Snap Inc. We’re excited to see a high-performance Redis alternative being backed by such a capable company. Now that Snap Inc. owns and maintains KeyDB, many teams—including ours—feel more confident in using it for serious production workloads on high-end servers.

However, there is considerable ambiguity in the documentation and community discussions regarding how to optimally configure server-threads and io-threads on modern multi-core servers. Even past guidance from the original creator seems to be exploratory, suggesting it "depends on network queue" or "try 4–8 threads," which does not help when scaling to enterprise loads.

❓ Questions for Production Configuration:

1. What is the recommended server-threads value for a server with >30 physical CPU cores (not virtual threads)?
   Should we match the number of physical cores, or is there a limit where performance degrades due to contention? We've seen suggestions ranging from 2 to 12 threads, but nothing concrete.

2. If io-threads is limited to 4 or 8 (as documented), does this limit or bottleneck performance if server-threads is set higher (e.g., 16 or 32)?
   Can server-threads scale independently of io-threads, or do they have a tight coupling in the internal architecture? This is crucial to know for tuning.

3. How does Snap Inc. itself configure KeyDB for their production workloads that process millions of operations per second?
   A real-world architecture outline (even abstracted) or guideline would help the community a lot. Are you using NUMA balancing, network queue alignment, or thread pinning?

📚 What We’re Looking For:
Updated and definitive documentation on thread configuration for KeyDB

Recommendations based on server specs (e.g., 32 cores, 128GB RAM)

Examples or case studies of Snap Inc’s internal deployments

Clarification on whether the server-thread pool has internal locks or data sharing implications when scaled

💡 Why This Matters:
The lack of concrete tuning guidance is a blocker for teams running high-throughput real-time applications (e.g., gaming, AI caching, analytics). Choosing the wrong configuration leads to underutilized hardware, unexpected latency spikes, or even regressions over vanilla Redis in edge cases.

We’d love to contribute to docs if we can get some insight from the core team.

Thanks again for your great work and for pushing KeyDB forward.