On 15.06.2010 23:09, William A. Rowe Jr. wrote:
As a broad general question - why not equivalent number of MaxClients
across all MPMs?
I was uncertain about that. Users often tend to try to fix performance
problems by adding concurrency to the web server. If your web server is
configured very tight, then this will help. But if you actually have a
throughput problem (slow backends, network etc.), then allowing even
more concurrency will make things worse.
So I wanted to stick away from sizing to what's possible and stay closer
to what's reasonable. Concerning Unix my gut feeling was that 256
processes (prefork) and 16x25=400 threads doesn't put much pressure on
system resources of modern entry servers. I raised the MaxClients for
the threaded MPMs, because I expect them to be a bit cheaper. But no
strong opinion here about the best numbers. Keeping MaxClients in sync
would make the MPMs better comparable out of the box, but on the other
hand precisely this type of comparison might not make much sense.
On 6/15/2010 4:03 PM, Rainer Jung wrote:
The default configuration for various MPMs
differs from the example configuration file
conf/extra/httpd-mpm.conf.
Before bringing those two in sync, I want
to propose the values we want to use as new
defaults as well as for the extras configuration
file.
Prefork
======= conf default proposed
StartServers 5 5 5
MinSpareServers 5 5 3
MaxSpareServers 10 10 15
MaxClients 150 256 256
MaxRequestsPerChild 0 10000 0
This seems bursty - can't we raise MaxSpare to at least 50?
Right, we should in order to prevent continuous forking and dying.
Worker/Event
============ conf default proposed
StartServers 2 3 2
MinSpareThreads 25 75 25
MaxSpareThreads 75 250 100
MaxClients 150 400 400
ThreadsPerChild 25 25 25
MaxRequestsPerChild 0 10000 0
If threaded, and stable, why not some 50 or 100 threads per child?
OK, especially since for Event I think that there is a problem of
correctly balancing load between child processes. For worker it is
clear, when a child is saturated, i.e. when each thread has a connection.
For event it's quite possible, that the idleness of worker threads
fluctuates. So bigger thread pools (per process) might reduce risk of
starvation.
Simple
====== conf default proposed
SimpleProcCount 5 5 5?
SimpleThreadCount 5 5 5?
WinNT
===== conf default proposed
ThreadsPerChild 150 64 150
MaxRequestsPerChild 0 0 0
+1
ThreadStackSize could probably be cut to 128k default (256k
processwide-default).
Only the Netware MPM uses a thread stack size different from the OS
default at the moment (OK, Windows uses hard-coded 65536 for the service
thread and a stderr_thread but not for the worker threads). So do we
want to now switch over to an httpd specific value or should we stick
with system default?
Netware
======= conf default proposed
StartThreads 250 50 50
MinSpareThreads 25 10 25
MaxSpareThreads 250 100 100
MaxThreads 1000 2048 1000
MaxRequestsPerChild 0 0 0
ThreadStackSize 65536 65536 65536
MaxMemFree 100 0 - (remove)
ThreadStackSize seems a bit dicey, would rather see 128k default.
Because it is the only MPM with non system default used, I wondered
whether there's a bit of history behind that value.
OS2
=== conf default proposed
StartServers 2 2 2
MinSpareThreads 5 5 5
MaxSpareThreads 10 10 20
MaxRequestsPerChild 0 10000 0
ThreadsPerChild?
i read the code like this: number of threads per child is dynamic.
Maximum is not configurable but instead defined by HARD_THREAD_LIMIT,
which is set to 256 in the MPM source.
Rainer
