Aug
16

Hello haywire

By kellabyte  //  Programming  //  4 Comments

Hello haywire

Back in April I decided I was going to learn how to write high performance code and that I was going to go all in with learning C to do it. In another learning project I had the need for fast communications so I thought why not see if I can write a HTTP server and see how fast I can make it?

I decided to do this all in open source so that it makes it easier to collaborate and learn. So I created a GitHub project called Haywire and off I went!

Some primary goals for Haywire include being a cross platform library and not so much a HTTP server that you run independently and host applications under. My needs were more about embedding communications into another service so the needs would be more geared towards being an API front end.

Haywire was kind of my “hello world” in C. Whenever I learn something new I have a habit of jumping 50 steps and starting with something probably too difficult as a beginners first step but I find it helps motivate me because the challenge of what I want to do interesting.

Haywire currently uses libuv for I/O and threading. It’s a C library that is the asynchronous I/O event loop based platform layer that node.js sits on top of. I picked libuv for I/O and threading because it had great cross platform support and helps abstract the nasty details of not having to implement epoll/kqueue/event ports on Unix systems or IOCP on Windows. This choice was really good in the beginning but later on I started fighting some of the event loop model. If libuv added a few key things it could be more flexible. More on that in later posts but the libuv team has been extremely helpful at giving me guidance on working around my problems.

I decided to use the build system libuv uses called Gyp which is created by Google. You write a .gyp file and it can generate Make, Xcode or Visual Studio outputs. This has been really helpful since I develop and test Haywire on Linux, OSX and Windows.

Haywire hello world took me about a day to learn how to use libuv to accept TCP connections, read bytes off the stream and parse a little bit of HTTP protocol from those bytes and then respond with a static response.

Relentless benchmarking

From the very beginning I was fairly relentless at benchmarking. While early benchmarks were not fair to compare to other HTTP servers doing much more than Haywire was (I was returning a static string after all!) it did give me a baseline. Whenever I added or changed code I would run the benchmark. Every time. This was extremely helpful because sometimes I would find out I did something that killed performance in major ways because I just compared it to the previous results.

I’ve gotten a bit (ok, ok, a lot) obsessed with performance in Haywire. In later stages I got much better at measuring hardware metrics because at times I was hitting bottlenecks like network saturation and I didn’t know this was happening until I created tools to collect and visualize hardware metrics. This became a blessing and a sin because now I was seeing a much better picture of what the machine was doing. Now I was even more obsessed with performance. Now I wanted to be efficient with the CPU so that code that uses Haywire gets more of the CPU rather than Haywire stealing most of it.

Following some talented database and distributed systems infrastructure engineers on Twitter has been a great influence for driving my motivation to get better at benchmarking and measuring. I see some of the things they are doing and the level of understanding they have of what is going on in the system and in their code is a great inspiration.

I understand that adding features will slow the performance down because anything is slower than something that does nothing but I try my best after introducing code that degrades performance to try to find creative ways to gain as much of it back as possible.

You can find Haywire on GitHub. While there are only Linux CI builds right now using Travis, I try to test on Windows fairly frequently but at times the build can be broken since Visual Studio 2012 has poor C99 support. I would love to get some Windows CI builds going so that I can stay on top of this better.

I would love to collaborate with you! I’m always open to contributions, comments, feedback and code reviews. Please be kind.

A tremendous thank you to the people who have already helped me out and offered their time. Thank you!

Now that I’ve introduced what Haywire is, stay tuned for some blogs describing some of the things I’ve done inside the code base.

  • Joe Wood

    Hi Kelly, so is Haywire kind of like a C99 version of node.native (https://github.com/d5/node.native)?

    I’ve been looking for node.native, and using gyp for building too. One thing that is missing is a good package manager. With cross platform C/C++ it’s easy to find yourself in build hell.

  • nick

    I would be interested in a blog about all the tools and techniques you are using for benchmarking. I

  • http://thecappsblog.blogspot.com Kyle Szklenski

    Might I ask whom you’re following on Twitter for this? I follow Howard Chu, who is, for my money, one of the most talented DB devs around, not to mention Ayende of course.

    Thanks for your posts about Haywire. Really interesting stuff!

  • Pingback: Improving the protocol parsing in Redis « kellabyte