Basant Kumar kukreja wrote: > +1 for production ready configuration. > > Just a note that it is sometimes difficult to come up with a common production > config for different kind of servers. For example, ServerLimit and MaxClients > ServerLimit 2048 > MaxClients 2048 > > For a larger system like CMT systems with more memory, these tunables can be > higher. Ideally it should be self tunable. For example, in Sun Web Server, we > tune few settings (if unspecified by user) based on Number of CPUs, memory > etc. >
I certainly agree it is difficult to come up with a common production config ;) note that I'm not aiming for complete production-ready configs; instead, I'm aiming for an alternate config framework which contains the bare necessities, along with guidance on how to enable the desired web server features beyond static files (start with a simple base, add just what you need) > For my above example, if ServerLimit is not specified by user then Webstack's > apache can define these values based on the system it is running on. In > longer > term, we can work on a separate patch, which tunes some configuration > dynamically. > > MPM and keep alive settings are the most common setting which should be tuned > dynamically unless user wants to override it. > > Most of the MPM settings should be derivable from MaxClients. Prefork example: MaxClients xxx <- user sets this MaxSpareServers auto <- some meaningful percentage, such as 15%, of MaxClients (users sometimes modify MaxClients and forget to change this, resulting in bogus config) MinSpareServers auto <- 5% of MaxClients perhaps? StartServers auto <- same as MinSpareServers How do you see MaxClients changing dynamically/automatically? If you're considering raising it, wouldn't there still need to be a way for the admin to declare how much of his/her machine Apache could own? (MaxClients is a very rough way for the admin to specify that, but OTOH it very easy for Apache to maintain compliance) The event MPM should resolve the primary keepalive consideration (reducing keepalive timeout to a value low enough that connections in keepalive don't consume too many resources) since it doesn't consume worker threads for keepalive, but mod_php and some other modules have an affinity to prefork, so dynamic timeout determination would be cool. > For CMT systems, we can have separate include files too. (Where configuration > for built-in crypto card can be included) > BTW, is there documentation anywhere for tuning Apache for Sun systems, such as for different crypto cards?
