To clarify - The pools.tcl file I wrote serves ONE purpose. To set
the "default" pool's params to what is in the server config. This
was ONLY done because folks expected the default pool to be set at
start up using the config params... as it was in 4.0.10.
My opinion is that any OTHER pools should be created and managed by
Tcl Modules and or Tcl Packages, not the server config.
M
On Aug 1, 2007, at 9:56 PM, Tom Jackson wrote:
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.
--
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.
