Paul’s Journal

lighttpd is a relatively new webserver. It has quite a few good features. The major design choice, is for it to be completely single threaded and single processed. This means all dynamic content generation is done via FastCGI.

On the sidebar, they have a wonderful link to their benchmarks. Now, we all know that benchmarks are mostly fake, and ApacheBench is one of the worst available tools for doing benchmarks. They make some great claims on their benchmark page:

(emphasis is mine)
Well, I can’t stand people perpetuating the myth that Apache HTTPD is slow. I agree, it will never be the fastest in the world, but is is not slow. Therefore, I did some benchmarking of my own.

Hardware
Client:

Server:

Both machines are connected to a 24 port 10/100 switch. Nothing super amazing on the hardware size.

Software
lighttpd:

Apache HTTPD:

The Test
I grabbed a copy of the Slashdot Frontpage. 62686 Bytes long. This file was request 10,000 times at each concurrent client level. gzip/delfate compression was enabled on both lighttpd and Apache httpd.

The Graph

Insightful Commentary
Oh shit. lighttpd isn’t faster.

Both servers are able to max out the 100mbit LAN after awhile, but Apache HTTPD got to the point first.
Will the people who have >= 1 Gigabit Internet Connections to their servers please stand up?
Yes, you two who pay way too much money, and don’t actually use that much bandwidth, you don’t count.
Yahoo might count, but everyone else sit down. It doesn’t matter which server you use, since both can easily flood your entire maximum outgoing bandwidth.

Conclusion
Changing your webserver doesn’t solve real performance issues. Look at your 200,000 lines of PHP code and slow SQL first.

Disclaimer
Apache httpd had an unfair advantage. I am an Apache Developer, and breath it every single day.

I have no personal grudge against lighttpd, or it’s developers.

I don’t accept that Apache httpd should be slow, and I don’t believe their benchmarks are entirely truthful. Don’t let the myth continue.

Update 7/05/05: I replied to several comments in another post.

1 week after 2.1.5, a new alpha is out the door. Changes include fixing more of the security isseus from the Watchfire Report and unlike 2.1.5, this one should compile on Windows.

Download 2.1.6 from:
http://httpd.apache.org/dev/dist/

We really need testing of the new features, specifically the improved mod_cache and mod_proxy.

I am extremely excited to announce that I have accepted a Job Offer from AskJeeves, at Bloglines in Los Gatos. More info coming in the next couple days, but among other things, this means I am moving to California.

Purchased a Volkswagen Golf this weekend:


2005, 4 Door, Hatchback, 115 hp, yadda, yadda, yadda…

Apache has a 2.1.5-ALPHA posted at:

http://httpd.apache.org/dev/dist/


Change Log:

http://httpd.apache.org/dev/dist/CHANGES_2.1


We really need people to test the alphas. I would like to push for a new 2.2.0 stable branch soon, and the more testing we get in alpha means the less bugs we find after going stable….

I noticed that the Cherokee Web Server added support for Solaris 10 Event Ports. They thought Cherokee was the first open source server to add support, but I beat them by 6 months. Back in November of 2004 I added support to APR/HTTPD.


Little Dance.


I won.

At the highest level, HTTP is a very simple protocol. It is quite easy to write both a server and a client. However, the parts of the standard that control Cacahing of HTTP Requests become complex very quickly. So complex, that most web applications do not behave correctly. So here is “chip's abridged guide to HTTP Caching for Web Application Developers“.

The Vary Header
Simple Rule: If you look at any header from the client, and do something based on it, you must add it to the Vary header. This means if you use the User-Agent, the Accept-Encoding, or any Cookies, you must add them to the Vary Header.

The ASF Wiki uses MoinMoin. I would venture to say that it is one of the most popular Wiki software available. Despite popularity, it doesn’t handle the Vary Header correctly at all. Due to excessive load on the wiki server, mod_cache was added. People browsing the site quickly had problems. Users would get pages in different languages. Sometimes you would get a page with different person’s login. This wasn’t the fault of mod_cache, infact, the same problems would happen with any downstream caching proxy.

To start fixing MoinMoin, you need to add Vary: Cookie,Accept-Encoding to the output for every page. This means for every different value of the Cookie headers and the Accept-Encoding, mod_cache will cache a different version. If you do not do this, people will get the page in the wrong language, or with someone else’s login.

The Cache-Control Header
Simple Rule: You must use this for any personalized page. If you have any information that is specific to a logged in user, you must use the Cache-Control Header.

Now, Cache-Control is harder to put into a simple box, because it can be used to control many different things. For most applications however, it can be shortened to ‘If you have private content, you must add Cache-Control: private, must-revalidate.

MoinMoin doesn’t do this for pages generated for logged in users. This means it is possible for another user to see a different user’s logged in page, as it was cached. This is mostly harmless and more annoying in the MoinMoin case, but for other applications, you might have private information that you do not want cached.

If you follow those two relatively simple rules, most web applications will at the very least behave correctly behind an HTTP Cache. For details, there is always the RFC, but some other sites have more friendly information.

Update: Added must-revalidate to the Cache-Control section.

Dear Jim Green,
Your “Talking Fountain” is annoying. I do not want to hear gurgling water sounds while trying to get a drink of water.
Thanks,
-Me

For those who haven’t heard it, the best I can do is show a picture:

[From Here]

Maybe after being stranded at SeaTac for 4 hours, I just lost all appreciation of Art. It only takes 5 hours to drive from SeaTac to Spokane. If Alaska Airlines can’t fly ontime, driving doesn’t sound so bad.