Redis Clone: Reducing Memory Pressure
After the taking a look at the original naive implementation, I wanted to try reducing the memory churn. By accident the IO optimizations already reduced the memory usage. Let’s go a bit further, trimming down some memory usage.
I often look out for two things: - Object allocations of objects which are immediately thrown away again. Yes, the JVM allocator and GC do an amazing job handling short-lived objects. However, it’s not magic and the memory bandwidth is limited. So, removing unnecessary short-lived objects is often easy and gives you more memory bandwidth headroom. - Ensuring long-lived objects are in a compact form and a useful format for the purpose.
Anyway, I’m trying to shave off some allocations in this blog post. Note, as I reduce allocations the code becomes less Java-y and I introduce C-like fragility, where life-time of memory matters. In a real-world app I would only use such optimizations only if you really need more performance.
Creating Pseudo Terminals for Test Scripts with tmux
I recently tried to automate a test setup, where the program I tried to automate insisted on having a TTY. Oh no, yet another TTY adventure (previous one) for me ;).
Redis Clone: Improved IO Control
We left with unsuccessful attempts to improve the IO by only using Virtual Threads and the classing blocking IO classes in the previous post.
This time we are using the NIO network API to get more fined grained control to the IO pattern. As a recap: We try to avoid blocking while flushing each individual response. This way we take advantage of the pipelined requests: We get a bunch of requests from the client, answer all of them and amortize the flush over multiple responses.
Redis Clone: Virtual Threads (Project Loom)
In the last post we profiled the naive Redis Clone. One of thing showing up was the flushing of the response.
In this post we try out Virtual Threads and Structured Concurrency from the JDK 19 preview, and see if we can use it to improve on the flushing. This is certainly not a primary use case for these feature, but let’s try it out anyway.
Profiling the Naive Redis Clone
In the last post we ran a benchmark on our naive Redis clone. It performed already impressively. To improve its performance, the first step is to understand where the time goes in the program.
