On Mon, Feb 18, 2002 at 09:32:20PM +0000, Mike Silbersack wrote: > Well, a benchmark should be able to show that, assuming that a set of > files larger than physical ram is used. I wasn't intending to imply that > thttpd was necessarily superior to Apache, I just would be interested to > see how various web servers compare today.
At the risk of dragging this even further off-topic, I'll throw in a couple of thoughts about web servers and performance. 1) Speed isn't everything. In fact, it's often the last thing that the user/customer goes shopping for. The vast majority of web servers have far more ability to source traffic than their upstream bandwidth will carry. While figuring out how to get a couple of T1's worth of bandwidth out of a web server might have been a challange 7 or 8 years ago, few machines won't do it today. 2) Configurability is highly desirable. This is part of why Apache is so very popular -- it's highly configurable. The plugin modules support allows for all sorts of weird and wonderful features. 3) Robust code is paramount. This is probably the biggest plus for Apache. Apache is known not to be the fastest web server. Examine it's internal architecture -- it's designed to be oh-so-flexible, and moderately fast. Thttpd is much smaller (and much, much less configurable) and doesn't have to pay a penalty for supporting a generically extensible operations framework. Back when I worked on UUNET's web farm, running a BSD based system (BSD/OS for those interested), having Apache's flexibility won out over the raw speed of many of the other web servers we bothered to look at possibly supporting. I have no trouble believing that a lightweight web server can be faster than Apache in sourcing data. If raw throughput is the goal here (and not actually a *useful* web server) -- well, have fun. You might as well just jump right down into the kernel. Or, for maximum performance, perhaps you should do away with the OS entirely and run on the "bare metal", to make sure that not one iota of performance is left on the table. -Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message