Reading through your responses, I'm curious about how much experience you actually have in our industry. Most of what you claim is easily falsifiable. The idea

Reading through your responses, I'm curious about how much experience you actually have in our industry. Most of what you claim is easily falsifiable. The idea that C10K doesn't matter is definitively untrue. I've worked with numerous large systems (games, content) where Apache was the problem, and swapping it out was the solution to making maximal use of the hardware and the (gigE+) pipes. Even outside of saturation, there are large-scale systems that benefit from being able to park an open socket and provide asynchronous notifications over that socket (in web terms, think websockets). If you're paying for a thread or process for every socket, this becomes prohibitively expensive very quickly. It's also not an unusual use case outside of traditional web development, and now with websockets, this kind of architecture is likely to see considerably more use. This approach provides numerous advantages to legacy polling approaches, but does not work on traditional short-lived connection software architectures. In addition to the above, your discussion of robustness really has no bearing on Apache's architectural suitability in production use-cases. Auto-restart functionality exists for other architectures, and in addition to that, it's standard practice to deploy multiple servers with automatic failover behind a load balancer -- in addition to the server process itself, the OS can crash, disk drives can fail, power supplies can blow, etc. Additionally, you shouldn't have production processes crashing regularly, and shouldn't be making significantly performance-impacting architectural choices on the basis of Apache's ability to restart a child process. Software crashes in production are a worst-case failure, akin to a drive failing, and should never be so common as to justify Apache's performance costs/constraints.