Towards sysbench 1.0: some history and more active future development

2 minute read

TL;DR summary: sysbench development has slowed down over the last years, resulting in users looking for workarounds for missing features and limitations. However, things are going to change with more active development and many features and fixes planned for the next version. This is the first post in a series to describe all those improvements.

sysbench started as an ad-hoc project inside the High Performance team in MySQL AB. In fact, the very first version was a single large C source file Peter Zaitsev sent me when I had to look into a Linux kernel 2.6 regression (TODO: find that email for my memoirs when I retire).

The original version didn't have all the features I needed for that task, so I started hacking on it, adding the missing bits and refactoring the code to simplify adding new features. The Linux kernel regression was reported to LKML and later fixed by developers, which was probably the first of the numerous issues that sysbench has helped to fix.

Over the next few years sysbench had become pretty ubiquitous in the MySQL community. I like to think I have contributed to that success with a few design choices: compared to other popular benchmark tools at the time sysbench was fast, easy to install and setup, had no external dependencies, and apparently was universal enough for people working on performance-related tasks. Yet it has always been a side project. Even though I've always wanted it to be much more flexible and be able to benchmark everything in all kinds of scenarios with as little fuss as possible, I've never really had time to implement those goals. Instead, I've always been fixing and adding things that I and others needed right there, right then.

I also found myself using sysbench less and less frequently as I changed roles and companies. Of course, I did my best to respond to bug reports and feature requests, but lack of dogfooding never works well for a software project, and it was hard to find time and motivation to work on important, but time-consuming requests from users. Which eventually resulted in some users with the most complex and strict requirements to their benchmarks find other ways to achieve their goals: use older sysbench versions, because newer ones had too much overhead, start multiple sysbench instances, because scalability on high-end hardware was bad, maintain their own forks of sysbench, or use another tool for their benchmarks.

The good news is that I'm going to change that situation by putting more efforts into sysbench development. Partly because I now have enough time for that, but most importantly because I now use sysbench very extensively in my current projects. So, to all those users who have been unhappy with sysbench recently, I feel your pain now!

I have already started fixing some of the biggest performance and scalability issues.

The very first and obvious improvement is replacing Lua with LuaJIT, as the latter is a de facto standard these days. I'm going to describe it in the next post.

Leave a Comment