Today, after releasing Cherokee 0.8.1 I decided it was time to test again how it was doing about performance. In the last months we have got a great new I/O cache layer and a couple of structural changes that were supposed to have a positive impact on the general server performance, although nobody checked whether those changes were as effective as we aimed them to be.

So, once again, here I am bringing good news. We have done it. Cherokee is actually the fastest web server among a set of the most common servers nowadays: Apache, Cherokee, Lighttpd and Nginx!!

The benchmark consisted on half a million requests of a 1.7KiB static file, with 20 concurrent clients, using a 1Gbit/s local network. The results (fastest to slowest) were:

Cherokee:

Server Software:        Cherokee/0.8.1
Server Hostname:        10.0.0.102
Server Port:            80

Document Path:          /index.html
Document Length:        1795 bytes

Concurrency Level:      20
Time taken for tests:   17.819725 seconds
Complete requests:      500000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    500000
Total transferred:      999007442 bytes
HTML transferred:       897506630 bytes
Requests per second:    28058.79 [#/sec] (mean)
Time per request:       0.713 [ms] (mean)
Time per request:       0.036 [ms] (mean, across all concurrent requests)
Transfer rate:          54747.93 [Kbytes/sec] received

Lighttpd:

Server Software:        lighttpd/1.4.19
Server Hostname:        10.0.0.102
Server Port:            80

Document Path:          /index.html
Document Length:        1795 bytes

Concurrency Level:      20
Time taken for tests:   21.248000 seconds
Complete requests:      500000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    470598
Total transferred:      991856958 bytes
HTML transferred:       897503590 bytes
Requests per second:    23531.63 [#/sec] (mean)
Time per request:       0.850 [ms] (mean)
Time per request:       0.042 [ms] (mean, across all concurrent requests)
Transfer rate:          45585.94 [Kbytes/sec] received

NginX:

Server Software:        nginx/0.5.33
Server Hostname:        10.0.0.102
Server Port:            80

Document Path:          /index.html
Document Length:        1795 bytes

Concurrency Level:      20
Time taken for tests:   23.741872 seconds
Complete requests:      500000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    500000
Total transferred:      1006000217 bytes
HTML transferred:       897500000 bytes
Requests per second:    21059.84 [#/sec] (mean)
Time per request:       0.950 [ms] (mean)
Time per request:       0.047 [ms] (mean, across all concurrent requests)
Transfer rate:          41379.30 [Kbytes/sec] received

Apache2.2:

Server Software:        Apache/2.2.8
Server Hostname:        10.0.0.102
Server Port:            80

Document Path:          /index.html
Document Length:        1795 bytes

Concurrency Level:      20
Time taken for tests:   35.438605 seconds
Complete requests:      500000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    495064
Total transferred:      1043777896 bytes
HTML transferred:       897500000 bytes
Requests per second:    14108.91 [#/sec] (mean)
Time per request:       1.418 [ms] (mean)
Time per request:       0.071 [ms] (mean, across all concurrent requests)
Transfer rate:          28762.81 [Kbytes/sec] received

For the record: I did my best configuring all the servers in the very same way. In all the cases I removed unnecessary rules that could have slowed down the server (checks for htpasswd files and so on). And all the binaries came from the Debian repository, except for Cherokee 0.8.1 that hasn't been packaged yet.

Anyway, this benchmark has been just a quick test. It is not certainly representing the result that these servers would have handling real traffic though. So, in the following days I will try to do a new a more accurate benchmark with static and dynamic content, compression, redirections, etc. I'm pretty sure the results will be even better.

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.

Yesterday I spent some time testing an idea on Cherokee and MySQL integration. It is actually quite unusual - do not think of the bleeding edge "I want to store my virtual servers list in a MySQL table". However, quite sadly, it did not success at first try because of a couple of API problems. (I will try a different approach today, though.)

Anyway! There was something quite scary that I wanted to write about. When I was reading the MySQL source code trying to find out how to reuse a connected socket (opened from outside the MySQL client library), I saw something scaring. Have you guys read the cli_mysql_real_connect() function? It is definitely worth reading. Geez, what a mess!!

So, allow me play Grover here of a second! Kids, if you want to learn to write good code, go and read clean sources like SSH or Cherokee; do not ever read pieces of code like the function I pointed before - even if, as a matter of fact, works alright. :-)

After releasing Cherokee 0.8.0, it is time to take care of a broken promise. It is time to give some love to our native Win32 port.

This subject has been a little bit of a pain. We have spent on this way much more time than what we should have because of the building environment. Well, actually, because of the lack of a bundle with the set of tools needed to compile an autotool based project on Windows.

Both Taher and me have spent a lot of time trying to get an acceptable building environment that we could use for keeping up with periodic Win32 binary releases, although none our tries were really fruitful. We found a whole lot of problems along the way: outdated versions of autoconf/automake/libtool that broke up when they were updated, weird 'make' issues, missing parameter in m4, etc.

However, I have finally found a path to get it working! (Hopefully it is actually true, not like the last time I said the same and I ended up proving myself wrong). Here is the cookbook:

• Download MinGW-5.1.4. Install it in c:\mingw

• Download Msys-1.0.10. Install it in c:\msys\1.0. Then: y, y, c:/mingw

• Download MsysDTK-1.0.1. Install it with the default values.

• Then you will have to go to SourceForge and download a few updates from the User Contributed: mingwPORT (current) section: autoconf-2.59-mingwPORT, automake-1.9.5-mingwPORT, libtool-1.5.22-mingwPORT, wget-1.9.1-mingwPORT, emacs-cvs-mingwPORT.

  These aren't actually packages, but scripts that download and compile updated versions of some tools, so it will require a little bit of time to get them installed.

  In the average case, it's trivial to install these packages. However, there are a couple of exceptions you should know about. The first one is wget; to get it installed open a shell and execute the following commands:

  mkdir /usr/src ; cd /usr/src
  tar xfvj ~/wget-1.9.1-mingwPORT.tar.bz2
  cp wget-1.9.1/mingwPORT/wget.exe /mingw/bin/

  The second exception is the autoconf update. Right after unpacking the package in /usr/src you will have to edit the mingwPORT/mingwPORT.configure file, and change:

  ${SRCDIR}/configure --prefix=`cd ${PREFIX} && pwd -W`

  by:

  ${SRCDIR}/configure --prefix="${PREFIX}"

  Then you can go ahead and execute ./mingwPORT.sh in order to get it compiled and installed (use the default values).

  For the rest of the packages, you will only need to unpack them and execute mingwPORT.sh.

• The next step is quite tricky. We will have to fix a broken aclocal script by hand. It is really easy though, just open a terminal and type:

  cd /mingw/bin
  mv aclocal aclocal.orig
  sed s.C:/./C/.g aclocal.orig > aclocal

• At this point, we will have a fairly acceptable environment, although it will still lack a few more software pieces. Next step is to install the Pthreads library and header by downloading the latest release, unpacking it and executing:

  cp -r Pre-built.2/{include,lib} /mingw/

• Then SVN. In my case I used svn-1.4.6 because I could not download the 1.5.1 Win32 client binaries without registering at CollabNet.. which kind of pissed me off.

• The last missing piece of software was Python. So after installing it and adding the SVN and Python paths to the PATH environment variable we will be done.

So, now that I have finally found the way to collect, set up and fix all the little pieces involved on the compilation environment I can finally start working on the real stuff. <sigh!>

"Hard as a rock" is the code name of our latest Cherokee release: Cherokee 0.8. With this version we have reached a really important milestone along the development roadmap.

Cherokee 0.8.0 is the very best version we have released so far. As its code name points, it is actually hard as a rock. In fact, I am going to ignore the bunch of features that have been added to this release (such as X-Sendfile, Graceful restart, GeoIP rules, deflate, etcetera) and I will focus on the performance and reliability improvements.

First of all, our FastCGI support has been reworked in order to support the broken PHP implementation. After having waited a couple of years waiting for PHP to fix it, I finally got desperate and found the way to make the Cherokee FastCGI implementation deal nicely with it. The final result? Aside of having a much better PHP support, both the FastCGI and SCGI handlers are way more reliable than on the previous releases.

We have also rewritten the whole I/O caching layer. It has been a tough task to accomplished, actually. But without any sort of doubt, it has been time well spent. The new caching policy has had an impressive positive impact on the whole server performance (as soon as I get some free time, I will publish a benchmark to backup these words).

Well, we also worked on the overload management. What happens when the server reaches the overload limit? Should it do something? Should it behave differently? Should it just keep working and send an SMS to the sysop asking him to pray for it? Well, we have implemented a few politics that delay quite a lot reaching the overload limit, and in case the limit is crossed, the new overload handling mechanisms would start taking care of it. The final result is astounding.. even for me that I wrote it!

And of course, last but not least, we have done something even more difficult, something way tougher, something that we did delay for many months and that people were sighing for.. we have finally written a whole lot of new documentation!!

So, what more can I say? I am really happy about our latest release. We have made huge improvements in a short period of time. The development activity is speeding up and the community growing. I'm delighted. :-)