Update: Wow! I just reread that post in its entirety and it sounds like using compression could exasperate the "can't get anything done for X amount of time problem" and/or the need to reap large children.

That's my point, slow clients keep Apache process running until it finish downloading.

gzipping contents will make page loads faster & will save traffic (a good idea even if the server is donated).

Beside if it was a really bad idea, why would both google & facebook guys implement it?

Beside if it was a really bad idea, why would both google & facebook guys implement it?

It's not a really bad idea in general. It's not a helpful idea for certain sites. You can't blindly apply performance tuning from one site to another and expect it to work. You have to profile what's slow and what's not to find out if you can expect any improvements or if you're only making it worse.

You haven't profiled anything. Other people have. Listen to them.

That's my point, slow clients keep Apache process running until it finish downloading.

Slow clients do not increase CPU load, they tie up child processes. I've heard nothing about requests getting queued due to having too few child processes or about excessive context switches due to having too many child processes.

Beside if it was a really bad idea, why would both google & facebook guys implement it?

We've been explaining that different sites have different bottlenecks. Why do you keep ignoring the specifics that apply to PerlMonks and revert to talking about what would help other sites?

Isn't it so that Apache keeps a pool of children available and does not kill off these child processes after each request? If that is so (my experience is mainly with Apache on Windows) then adding the mod_deflate process to each child will only bloat the child even more and stress the server even more. Over the many years I am with Perlmonks now, I cannot remember that anyone has been able to point to the lack of bandwith as a cause of the slowness of the Perlmonks site and I even hazard to guess that the number of "slow" clients will be very small.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

You did not provide data to support your argument or any useful links, so I thought it was an assumption.

I have no experience at all with FreeBSD (Never used it before), but if it's causing the slowness then why not change it?

3rd party donates and runs the servers. Can't change the OS.

I have decided to search about this, and it appears that FreeBSD/MySQL problem is a history now.

it appears to be running faster than Linux on FreeBSD 7 Benchmarked here