Happy Friday everyone!
I hope that you’ve all had a good week 🙂
I’m back with an interesting news story to share, and it provides an example of how overengineering can impact the deliverables you’re trying to achieve.
So, a gentleman called Jens Axboe has published an interesting patch update (link here) that claimed with their test case a performance increase from 108M IOPS to 115M IOPS, and they said they haven’t even enabled most of the costly block layer items that means the performance improvement could be even higher in real world utilisations.
Now, such a claim could be met with scepticism, but I was intrigued, how is this working?
Thankfully Jens provided some insights into this, and this is where I believe a lesson can be learned in overdesigning a solution to a problem, to its own detriment.
Jens explains in his patch notes that the patch reduces the number of times that the time is queried for timestamps. Historically near enough every time that a write occurred, the time would be queried, so that timestamps had nanosecond accuracy. But Jens patch caches the time more frequently so this takes place less often. Because realistically, do you need NANOSECOND accuracy in your logs when troubleshooting? Who knows, maybe one day? But for now, a slightly lower level of accuracy in the nanosecond range is a good enough solution, with real world performance improvements!
Hopefully we’ll see some speed improvements when this patch eventually makes its way into the kernels of our favourite Linux distros...
