The April, 2007 Netcraft Web Server Survey
Posted Apr 4, 2007 2:09 UTC (Wed) by njs
In reply to: The April, 2007 Netcraft Web Server Survey
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...
to post comments)