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.
Building a (Java-) Redis Clone, naively
Oren Eini (Ayende) has a wonderful blog series where he builds a small Redis clone in C#, and then investigates performance issues and improves on it. I got tempted to do a Java version, out of curiosity. I probably won’t go as far as Oren Eini with the profiling and optimization, but I’ll try to do at least some iterations.
Model Results/States with Java 17's Records
I often want to represent a set of possible results or states with different possible values. For example a processing result:
A successful full result
And expect error with some error code
An unexpected error with some exception
Some other rare edge case I need special handling for.