The April, 2007 Netcraft Web Server Survey [LWN.net]

The April, 2007 Netcraft Web Server Survey

Posted Apr 4, 2007 2:09 UTC (Wed) by njs (subscriber, #40338)
In reply to: The April, 2007 Netcraft Web Server Survey by eklitzke
Parent article: The April, 2007 Netcraft Web Server Survey

>With respect to communicating with external processes for complicated requests, this is of course very slow.

Only if you do it wrong -- you seem to be assuming CGI. The bottleneck in CGI isn't the IPC, and it isn't even the fork(), it's the exec() -- mapping in the executable, dynamic linking, maybe byte-compiling, getting through main() to your actual code, etc., on every request.

Any setup that has apache talking to a persistent process, rather than loading a whole new one on every request (FCGI/SCGI/mod_proxy/...), will scale basically as well as mod_p*. The IPC overhead is basically a bounce through a memory buffer, it's not even radically different from the sort of work that might happen just moving your data out of mod_p* into apache's C layer.

You shouldn't see any cost to concurrency either, just the opposite... for instance, if you have multiple areas of your website (or virtual domains, or whatever) that are run under different systems (say one part using a particular CMS, another a different blogging system, whatever), and each gets about the same number of hits, then you can have 10 CMS processes and 10 blog processes to handle both, instead of 20 apache+cms+blog processes -- a total of 2x the memory usage. And it's worse if they aren't getting the same number of hits, because you still have to pay (total number of hits)*(total number of systems) in memory, while in the more decoupled design you can have, say, 15 CMS processes and 5 blog processes...

(Log in to post comments)

The April, 2007 Netcraft Web Server Survey

Posted Apr 4, 2007 11:09 UTC (Wed) by drag (subscriber, #31333) [Link]

In any benchmarks I've seen, even with FastCGI and SCGI, Apache has always been able to scale quite a bit higher with it's *mods then lighttpd with SCGI or whatever.

But usually it's artificial benchmarks designed to stress the system as hard as possible with a script generating 'hello world' or something like that.

So it's pointless for real life were you'd have your database or bandwidth limiting you.

I think the way it seems right now is that if you want something that is small were memory usage is important or something like that (say with a virtual private server) then lighttpd + fastcgi/scgi is what you'd want to use.

If you want to have something that is portable and fast with minimal dependancies and easier configurations then lighttpd is good also.

But if you want something to scale to the upper end of things then Apache with *mods is generally the way to go. Not always, of course. Just generally.

There are a lot of projects that make websites for home users or specific business stuff. Like configuration interfaces for firewalls, print/file servers, or stuff like bittorrent clients or corporate intranet forums. I think for that then lighttpd is a boon. Apache is just too huge of a hammer for such small nails.