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. :-)

There is something about the Cherokee administration interface that have been generating the same question over and over again since we released the first version a few weeks ago: "How can I administer a remote server?".

The configuration interface server (cherokee-admin) binds only the local network interface, so it is not possible access it from anyway else by the machine where the server is running.

There are two possibilities if you really want to access the administration server remotely:

• You can launch cherokee-admin with the --bind parameter. In this case the server would bind to the new specified interface; most probably your local network interface.

  This case is the easiest one, but also the most dangerous case as well: anyone on your local network would be able to access the server configuration, which does not look like something desirable.

• The second option is in my opinion the right approach to the problem. The basic idea is to run cherokee-admin on the local interface, and then create a SSH tunnel from your machine to that local port in the remote server.

  You need SSH access to the web server box, but we can assume it is granted to you - at the end of the day, you are the web server admin. So, the easiest way to run the server and map the TCP port would be:

  ssh -L 9090:localhost:9090 remote-web-server "sudo cherokee-admin"

  after which you could browse the remote administration interface in http://localhost:9090/

I hope this help to clarify things.. :-)

After a couple of days fixing a few minor bugs, I have got Cherokee (trunk) to build and work on Windows again! Of course, it does not use Cygwin or any other additional layer.

To say the truth it hasn't been as tough as I thought it would be. The hardest part was to take the first step: install Windows and the development environment in a virtual machine. The rest was fairly straight forward, actually.

Anyway, I have learnt a couple of interesting things along the way:

• The "Msys + MinGW + msysDTK + Emacs + Python + a few misc missing utilities" bundle is not trivial to install. So I have packaged it up for the next the I need it (Cherokee-Win32-comp).
• The rxvt I/O has been broken for a long time now. The best workaround I have found is to edit the msys.bat file and comment out the startxrvt invocation.

Anyway, I will continue polishing our Windows build for a few more days.. <sighhhhhh>

I would like to point you guys to a comic strip that I good friend of mine (and Cherokee contributor) has started publishing.

It is called South Pole. Basically, it is a story around three main characters who live on the 7th continent: Antarctica. A penguin named Linus (what a perfect name for a penguin, don't you think?); Bob, a polar bear born in Greenland; and Scott, a white fox.

It is definitely worth reading. Give it a try! Here you have the RSS feed. Enjoy it! :-)

I have just seen that the Cayac project guys have released its first set of packages.. which is great news!

Cayac is a bundle of different web technologies that makes much easier to deploy your preferred web infrastructure on OpenSolaris.

I'm specially happy because they chose Cherokee over the rest of the web servers. Now the installation is almost trivial because of Cayac and the web server administration is quite straightforward because of the administration interface that Cherokee 0.6 shipped.

What used to be a tough work that could take hours compiling and editing pseudo-XML files, has become a trivial process where you don't need to compile anything, nor to edit a single file by hand. What a change! :-)

We have finally released Cherokee "Shake well before using" 0.6.0!

A huge amount of work has been put on this release. It has taken us more than two years to complete it. There are too many changes to be listed here; as a summary, the most important improvements over the previous Cherokee 0.5 series are:

• Administration Interface: You will not need to edit a text file in order to configure the web server any longer! A user friendly web interface will assist you to set up your site.
• 20% to 25% faster Even if our previous Cherokee releases perform very well, Cherokee 0.6 is even faster!
• Load balancing support has been added. It can distribute load between multiple FastCGI, SCGI and HTTP servers from within the web server.
• The authentication support has been improved by adding new modules for validation against MySQL and LDAP servers.
• A new documentation system has been integrated, which has allowed the developer team to significantly improve the user documentation.
• This is the safest version of Cherokee ever. A new recovery mechanism has been integrated to ensure that the server will always be up and running.
• Looks nicer: new themes and icon sets have been included.

The source tarball is already available for download.

Links: documentation, mailing list, bug tracker and svn.

After more than two years of work, dozen thousands of new lines of code, bug fixes and improvements.. time has finally come for Cherokee 0.6.

I have just branched trunk. The release should be ready by tomorrow. Hurrah!! :-)

I'm back working after a weird week off. My original plan was to travel to Mexico DF for giving a couple of talks in a congress and hanging out over the weekend. However, my plans turned upside down when I got the flu a couple of days before departing.

So, what would you do if you are sick and eating antibiotics as it was candy? I know that it does not sound like the most common thing to do, but I chose to work on the upcoming version of Cherokee. I was not feeling the best, but even though, it was quite productive.

After writing around 150 new Kbytes of code, the administration interface (cherokee-admin) is working now. I cannot say that I am glad I couldn't attend the conference in Mexico, but at least this past week has been very fruitful. So if you are interested on new and fast web servers, be tuned, Cherokee 0.6.0 is around the corner!

Daniel just pointed me to this article that the Spanish edition of Linux Magazine runs on Cherokee (thanks!):

   

I have just released a new version of the tiny Cherokee PySCGI module: a 100% Python module implementing the SCGI protocol.

The latest 1.3 release fixes a potential communication issue between the application and the web servers. If you are using PySCGI the upgrade is recommended.

Bruno has just sent these videos made of some of the pictures I took a few days ago of OpenSolaris enthusiasts during the World Forum on Free Knowledge. It's pretty cool!