It is almost the same. It solves the same problem, it does the same work, it looks quite similar, but there is a difference though. One of them is way faster than its predecessor. :-)

With great joy, allow my to introduce our brand new DB-Slayer-like module for Cherokee!

In case you did not know the original implementation, it is a MySQL to JSON over HTTP bridge written by the New York Times folks. So, before I say anything more, I would like to thank Derek Gottfrid for such an inspiring piece of software.

So, what's up with the Cherokee module? Why the heck did we re-implement DBSlayer as a Cherokee module when the original version was already Free Software and was based on the well-known Apache library?

It's basically the same reason why we are working on Cherokee: there are alternative ways of facing the same problems, and it is our believe we have taken a very good decisions along the way that makes Cherokee a fit better on many environments.

On this case, I have written the handler_dbslayer because I wanted to prove myself how big was the difference between both architectures. The results? I'm simply delighted, they are kind of what I expected. Let me show it to you:

The benchmark consisted on 50,000 requests with 50 concurrent threads. Each one of them sending a really basic query to the same MySQL server. The request sent to DBSlayer and to Cherokee were slightly different because of a design decision I made. We send the SQL query as the body of a POST call instead of encoded in the request, and the options are sent as HTTP headers instead of encoded with JSON and re-encoded as part of the request:

This was the request to DBSlayer:

GET /db?%7B%22SQL%22:%22SELECT%20*%20FROM%20example;%22%7D HTTP/1.1
User-Agent: DBSlayer-tester/0.1
Host: localhost:9090
Connection: Keep-Alive
Accept: */*

And this one to Cherokee + handler_dbslayer:

POST / HTTP/1.1
User-Agent: DBSlayer-tester/0.1
Host: localhost:9999
Content-Length: 22
Connection: Keep-Alive
Accept: */*
X-Beautify: 0

SELECT * FROM example;

Check out the results!

It took Cherokee 2.40 seconds to reply all the requests (4,186 reqs/sec), while it DBSlayer needed 8.01 seconds to do the same work (1,255 reqs/sec).

However, things do not end there. As long as the Cherokee's handler_dbslayer has been implement as a response module ('handler' in the project slang) it can take advantage of the rest of the server features. For instance, you could configure it to use any of the load balancing modules that we are already shipping, so you could split the load among a number of MySQL servers.

But, wait; it goes on. There are more interesting enhancements that handler_dbslayer inherits. What about encoding the JSON formated result with, for instance, gzip before sending it back to the application server? It would only require you a click on the administration interface, isn't it cool? Another good point would be to use Keep-alive, Chunked Transfer encoding or Pipelining. It does sound like a really big advantage, doesn't it? :-)

I will write something more about how this handler works and performs in the following days.