Test Containers for C#/.NET
This post is part of C# Advent Calendar 2022.
Many applications lean heavily on relation database. Your application uses complex queries, constrains on data and all more of the wonderful features of a relation database. That means that a lot of your applications behavior depends on how the database acts.
Therefore, I try to test an against actual database system.
Years ago this used to be a challenge, as most database systems where hard to setup and automate.
Today it is easy.
Use TestContainers!
Test Containers
TestContainers is a library which starts up Docker containers for your tests. More, it provides many pre-configured setups for databases.
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.