Dossy, Sounds like a great goal, but there are still other considerations: 1. Even if the server tunes itself, it needs to start somewhere 2. Hard coding defaults already makes it difficult to figure out what the settings are because usually the programmers don't update the config 'data structure' when the default is triggered by a missing value. So getting the value now requires writing a specific accessor. Getting the settings is very important to diagnosing certain issues, like one I will discuss below related to ns_pools. 3. When a server has tuned itself up, it might be helpful to remember these settings during a restart, so storage is still a good idea. 4. Removing the ability to use fixed values, that is human tuning, seems like a sure road to disaster. 5. If all settings are dynamic, then every time they are accessed you need a mutex or maybe even a cond.
Problem with ns_pools: Pools are named. Only the pool name is used to create a pointer to the pool. However, then the pool pointer is stored using Ns_UrlSpecificSet which can take into account the server. The result is that virtual servers using the same pool name overwrite the previous data. The new pools.tcl file iterates once per virtual server, but uses the same pool name, the last one loaded updates the previous pool settings. Probably several function should take into account the virtual server, or somehow explain this. Regardless, the result is that one server can change settings for another server. You are not able to query the maps associated with a pool. If the data is only set via the ns_pools command, this information is completely unavailble. It also cannot be deleted. The query function would be available if derived from a config file setting. tom jackson On Wednesday 01 August 2007 17:31, Dossy Shiobara wrote: > On 2007.08.01, Michael Andrews <[EMAIL PROTECTED]> wrote: > > I guess adding the ability to manage pools from the config does not > > take anything away from the ability ALSO manage pools from a package/ > > module. Gives folks a choice. > > One of the ideas for AOLserver 5.0 is to eliminate most of the static > config-time parameters and make as much as possible tunable at runtime. > The notion of having to bounce the entire process to make certain config > changes can be disruptive, operationally--especially when you have large > libraries of pre-sourced Tcl scripts which makes server startup > expensive. > > The natural segue with "most settings changeable at runtime" is a body > of intelligent code that self-tunes and dynamically heals the server > (ala Oracle's clusterware, etc.). I'd love to get AOLserver the point > where you simply specify maximum and minimum boundaries (which default > to the hardware's limits) and the server tunes itself based on the > workload it's receiving. > > -- Dossy -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
