Performance Tuning & Virtual Threads
Out of the box, LoomCache handles extreme concurrency workloads without complex tuning. This is primarily due to its integration with Java 25 Project Loom.
Java Virtual Threads (Project Loom)
Millions of lightweight virtual threads multiplexed over a few OS Carrier Threads.
OS Thread 1
OS Thread 2
The Virtual Thread Advantage
Section titled “The Virtual Thread Advantage”Older cache servers rely on complex, non-blocking asynchronous event loops (like Netty or epoll) because operating system (OS) threads are too heavy. A standard Linux server might struggle to maintain 10,000 active OS threads without suffocating under context-switching overhead.
LoomCache’s TcpServer completely ignores this limitation by utilizing Virtual Threads. For every single client connection, LoomCache spins up a dedicated virtual thread.
When that thread blocks to read binary data from the network socket, or waits for an fsync down to the WAL, the JVM automatically unmounts the virtual thread from the underlying OS carrier thread. This allows a standard 8-core machine to manage 100,000+ simultaneous open connections using readable, blocking Java code.
Garbage Collection
Section titled “Garbage Collection”LoomCache heavily utilizes off-heap memory and Kryo 5 object pooling to minimize object allocation pressure on the garbage collector. However, to ensure ultra-low latency, it is highly recommended to configure the JVM to use the Z Garbage Collector (ZGC) or the G1 Garbage Collector (G1GC).
# Example JVM Args for Production Cache NodeJAVA_OPTS="-XX:+UseZGC -XX:MaxGCPauseMillis=10 -Xmx8G -Xms8G"Hot-Key Detection
Section titled “Hot-Key Detection”Hot-Key Detection & Near Caching
Mitigating Thundering Herd problems automatically
A classic distributed systems problem is the “Thundering Herd” or “Hot Key” issue, where 90% of traffic suddenly targets a single Map key (which lives on a single partition leader).
LoomCache combats this via the HotKeyDetector. Through non-blocking, sliding-window sampling (default 5% sampling rate), LoomCache identifies hotspots and exposes them through SlotMetrics. Applications can query this data and optionally configure their LoomClient’s Near Cache to aggressively cache hot keys client-side, offloading the Raft leader entirely.