High performance .NETBuilding a Redis Clone–separation of computation & I/O
time to read 2 min | 256 words

After achieving 1.25 million ops/sec, I decided to see what would happen if I would change the code to support pipelining. That ended up being quite involved, because I needed to both keep track of all the incoming work as well as send the work to multiple locations. The code itself is garbage, in my opinion. It is worth it only as far as it points me inthe right direction in terms of the overall architecture. You can read it below, but it is a bit complex. We read from the client as much as we are able, then we send it to each of the dedicated threads to run it.

In terms of performance, it is actually slower than the previous iteration (by about 20%!), but it serves a very important aspect, it makes it easy to tell where the costs are.

Take a look at the following profiler result:

image

You can see that we are spending a lot of time in I/O and in string processing. The GC time is also quite significant.

Conversely, when we actually process the commands from the clients, we are spending most of the time simply idling.

image

I want to tackle this in stages. The first part is to stop using strings all over the place. The next stage after that will likely be to change the I/O model.

For now, here is where we stand:

 

Tweet Share Share 4 comments
Tags:

More posts in "High performance .NET" series:

  1. (19 Jul 2022) Building a Redis Clone–Analysis II
  2. (27 Jun 2022) Building a Redis Clone – skipping strings
  3. (20 Jun 2022) Building a Redis Clone– the wrong optimization path
  4. (13 Jun 2022) Building a Redis Clone–separation of computation & I/O
  5. (10 Jun 2022) Building a Redis Clone–Architecture
  6. (09 Jun 2022) Building a Redis Clone–Analysis
  7. (08 Jun 2022) Building a Redis Clone–naively