I believe ikegami and chromatic are both wrong in their replies to this node. If a significant fraction of request-processing time is spent shipping the bytes to the client, then that part being even a little slower can have a dramatic impact on the number of children Apache will want to create in order to keep up with the requests coming in. Which can certainly run your server out of memory (or even run your server out of other resources by DoS'ing the server with a near-fork-bomb of activity trying to create more children that makes Apache fall further behind which motivates creating more children...).

I used to work for a high-profile web site that used Apache in a back-end layer. A common request in that layer was to an external service that usually averaged about 100ms per response. A minor bog down at this provider might cause their average response time to climb to about 500ms. This was plenty fast for our needs. But it meant that we needed about 5x as many Apache children for a given level of traffic. And it would send a huge bank of back-end servers from "not busy" to "swamped" with no clear problem (requests aren't unacceptably slow, much less timing out).

Even after we (at my suggestion due to experience debugging performance problems at PerlMonks) set the number of Apache children to a fixed number (to avoid the fork-bomb-like problem), the lack of children could still cause requests to queue up to the point that the layer in front of that layer could start to fall over.

So being able to ship the bytes faster can reduce memory requirements on the web hosts and be beneficial. And we certainly have recurring problems at PerlMonks with running out of memory on web hosts.

But, the time required to ship the bytes to clients is only a significant fraction of the request-processing time during periods when the site is performing unusually fast. So the proposed improvement is unlikely to have much positive impact, I expect.

But I will keep it in mind the next time I try to tune things. If we haven't recently had problems with lack of web server CPU, than I'll probably try to deploy such a change.

Update: Re-parented as I originally accidentally replied to the parent of the intended node.