On Mon, Sep 14, 2009 at 4:27 PM, Greg Ames <ames.g...@gmail.com> wrote:
> * Should we yank the squatting logic? I think it is doing us more harm > than good. IIRC it was put in to make the server respond faster when the > workload is spikey. It finally occurred to me what you meant by spikey: triggering MaxSpareThreads (duh). The other conditions with squatting are graceful restart and MaxRequestsPerChild. > A more robust solution may be to set Min and MaxSpareThreads farther > apart and allow ServerLimit to be enforced unconditionally. and not use graceful restart or MaxRequestsPerChild and hope you don't get any child-fatal errors while long-running requests are being handled and/or set ServerLimit "enough higher" than MaxClients / ThreadsPerChild to allow ServerLimit to be enforced unconditionally even while some number of processes hang around while a few dangling requests complete --/-- slightly?-over-generalization: The real problem is that processes are so expensive on some platforms in terms of real memory or swap space or something else that real pain is inevitable when you have more than a few processes only handling a small number of requests. The use of an array for the scoreboard exacerbates this because it artificially limits the number of requests that can be handled in new (squatting) processes.
