Apache / IIS Flamebait
There's a ZDNet blog posting by Richard Stiennon that shows two call graphs comparing the system calls that a Linux / Apache server makes to serve up a simple page versus the equivalent on Windows / IIS.
Surprise, Apache makes fewer system calls. The argument is that this makes it easier to secure a Linux / Apache implementation. That might be true. My experience is that ignorant administration is an orders-of-magnitude greater threat than the inherent limitations of either platform.
While it's sort of an interesting look... I've got a few big problems with the post:
a) The graphs are unreadable, and therefore FUD. I'm sure it was just a bandwidth issue not to have a version of the graph with enough resolution to actually read the system calls being made. However, just showing two pictures with lots of lines and basing your conclusion on the fact that one picture has way more lines in it is a pretty shoddy argument. I'll give Stiennon the benefit of the doubt that he both analyzed the original graphs, and is qualified to understand what they say. If that's not the case, then shame on you for stirring up a pointless religious debate.
b) Microsoft chose this implementation on purpose. You can make an intellectually honest argument that keeping most processing in user-space is inherently more secure, but that's just a (sensible) opinion, and not gospel fact. IIS7 moved most low-level processing into http.sys as a conscious decision in support of performance and stability. ASP.Net can blow chunks and IIS will restart it. IIS can blow chunks and http.sys will queue up the requests until the OS restarts IIS. You would be right in assuming that this puts the entire OS at the mercy of any holes in http.sys. But in closed-source land that means that http.sys is going to be something that they pay extra-special attention to, and also insulate from the feature-itis that ASP.Net (and thus IIS) are prone to.
Alright, that's enough defending Microsoft (like they need my help). In Linux-land, there's a fanatical devotion to moving as much code as possible out of kernel-space and into user-mode. Security is one of the concerns, but it also keeps the kernel simple and light (well, simple as far as kernels go). This is a design decision that gets repeated in lots of Linux projects, but it comes at a price, like all design decisions do. Until the code can cross the magic line where really almost everything is happening in user-mode, there's a not-irrelevant performance cost from the marshaling between memory spaces. Apache already crossed that line... it's a good decision. And really, under the open source model where defense-in-depth is even more important, it's usually a good decision for most projects.
Of course, this is only a "decision" you get to make if you're hacking straight at the API. And if you're one of those people... you knew all this already. :)
Oh, and thanks to Arno for pointing me at the post.