Cherokee web server - the next generation?

Today I was surfing on the net while I was running some loong SELECT statemens on MySQL server. On the linuxquestions forum I found a thread about new web server called Cherokee. People said Cherokee's supposed to be quite fast (double as fast as Apache!) so I had to try it out myself!

I compiled Cherokee with basic settings and used default configuration files to run the tests - all I wanted to do was to test how fast Cherokee really is.

On the first test I used Cherokees default index page (sized 1700 ~bytes). I used Apache Benchmark to test the capacity of the web servers: 20 concurrent connections and 100k requests.

Here's the results:


Server Software: Apache/2.2.6
Server Hostname: localhost
Server Port: 80

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

Concurrency Level: 20
Time taken for tests: 43.383405 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 206406192 bytes
HTML transferred: 179505385 bytes
Requests per second: 2305.03 [#/sec] (mean)
Time per request: 8.677 [ms] (mean)
Time per request: 0.434 [ms] (mean, across all concurrent requests)
Transfer rate: 4646.20 [Kbytes/sec] received


Server Software: Cherokee/0.9.3
Server Hostname: localhost
Server Port: 80

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

Concurrency Level: 20
Time taken for tests: 24.177908 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 199401994 bytes
HTML transferred: 179501795 bytes
Requests per second: 4136.01 [#/sec] (mean)
Time per request: 4.836 [ms] (mean)
Time per request: 0.242 [ms] (mean, across all concurrent requests)
Transfer rate: 8053.96 [Kbytes/sec] received

As you can see, Cherokee is almost double as fast serving single small file. The developers at http://www.cherokee-project.com say that they have developed some über-cool I/O gadget that makes this possible.

I also wanted to test the results with a little bigger file: This time we're using 1.7 megabytes jpg image:

Server Software: Apache/2.2.6
Server Hostname: localhost
Server Port: 80

Document Path: /playboy/1.jpg
Document Length: 1791791 bytes

Concurrency Level: 20
Time taken for tests: 52.58448 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 740870816 bytes
HTML transferred: 738040816 bytes
Requests per second: 192.09 [#/sec] (mean)
Time per request: 104.117 [ms] (mean)
Time per request: 5.206 [ms] (mean, across all concurrent requests)
Transfer rate: 13897.96 [Kbytes/sec] received

And Cherokee:

Server Software: Cherokee/0.9.3
Server Hostname: localhost
Server Port: 80

Document Path: /playboy/1.jpg
Document Length: 1791791 bytes

Concurrency Level: 20
Time taken for tests: 47.941745 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 740070816 bytes
HTML transferred: 738040816 bytes
Requests per second: 208.59 [#/sec] (mean)
Time per request: 95.883 [ms] (mean)
Time per request: 4.794 [ms] (mean, across all concurrent requests)
Transfer rate: 15075.07 [Kbytes/sec] received

As you can see, this time the difference is allmost next to nothing.

So, which of the web servers is really faster? Can't say. The Apache was default installation that comes with Fedora Core. Cherokee was compiled. We were testing only one static file. In few days I'm going to make a test including Apache, Lighty, Nginx and Cherokee, testing static files (multifiles!), php scripts and all other kewl stuff. Then we'll see which of 'em is really faster!

Benchmarking Apache 2 vs. Lighttpd

Have you ever wondered which is faster, Apache 2 or Lighttpd? Everyone says that Lighttpd (or lighty) is a much faster, but is it really so?

I found this curious article I'd like to share with you. It can be originally be found here but I'm also going to write a short version about the article below:

The benchmark shows how Apache 2.2.3 compares to Lighttpd 1.4.13 when delivering static HTML file approx 50 kilobytes. Test was made with Apache benchmark.

The test was made on a Debian Etch running inside VMware. The box was quite old but it shouldn't affect on the tendency.

Versions were:

*Apache 2.2.3 mpm-prefork with default Debian configuration.
*Lighttpd 1.4.13 with default Debian configuration.

The HTML file was approx 50 kilobytes in size and it was saved as test.html.

I've run the following commands ten times each and calculated the average requests per second that the web server could handle:

*ab -n 100 -c 5 http://localhost/test.html
*ab -n 1000 -c 5 http://localhost/test.html
*ab -n 10000 -c 5 http://localhost/test.html
*ab -n 100 -c 50 http://localhost/test.html
*ab -n 1000 -c 50 http://localhost/test.html
*ab -n 10000 -c 50 http://localhost/test.html
*ab -n 100 -c 100 http://localhost/test.html
*ab -n 1000 -c 100 http://localhost/test.html
*ab -n 10000 -c 100 http://localhost/test.html

-n is the number of requests to perform for the benchmarking session; -c is the number of multiple requests to perform at a time.

Here's result of the test:



As you can see, lighty is almost one third faster on static pages! Knowin this one has to consider if it is worth using lighty instead of Apache. Personally I choose Apache? Why? More modules and knowledge. Maybe some day I'll start using Lighty. Or Nginx. Woudln't that be kewl?

Apache Internal Dummy Connection

Yesterday I updated our Apache HTTPD to the latest version (2.2.8). Soon after this I noticed that HTTPD's access log was logging some stange requests:

::1 - - [13/Mar/2008:09:05:13 +0200] "OPTIONS * HTTP/1.0" 200 -

And what does the request do?

[asdf@foobar logs]# telnet localhost 5453
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
OPTIONS * HTTP/1.0

HTTP/1.1 200 OK
Date: Thu, 13 Mar 2008 07:06:43 GMT
Server: Apache/2.2.8 (Unix) PHP/5.2.5
Content-Length: 0
Connection: close
Content-Type: text/plain; charset=UTF-8

Connection closed by foreign host.

I did a little research on the web and came up with the following links:
http://vdachev.net/blog/2007/02/01/apache-internal-dummy-connection/
http://apache.hpi.uni-potsdam.de/document/4_3Multitasking_server.html

It seems like the request above is called "Internal Dummy Connection", and it's a way for apache to let it's children processes know it's time to die. It's usually nothing you should worry about, but if you see many child processes spawn and die, you may want to configure MinSpareServers and MaxSpareServers directives, and your MaxRequestsPerChild.

If you want to clean up your HTTPD access logs, you can do the following:

SetEnvIf Remote_Addr “::1″ dontlog
CustomLog /foo/bar/access.log combined env=!dontlog