Stephen,
I agree that you have clearly defined one use of threadpools, essentially
overall limits. But note that threadpools are tied to url patterns. The
concept is that certain urls consume more resources that others, not just
memory, but processor time. Other urls consume few resources, maybe just
static content. Then there could be differences between a development version
of a site and a production version running in the same nsd process. Maybe an
admin section needs to always have available threads if the whole server is
jammed up for some reason. There is more than one use for threadpools, which
is the original reason for the threadpool maps: prior to threadpools, there
were per-virtual-server settings. This is what was removed and replaced with
the current code. Something else removed was a bunch of checks done on the
configuration parameters, maybe not important, who knows without testing:
things like minthreads <= maxthreads <= maxconnections.
I still think there is a funamental clash between the idea of global control
using global threadpools and allowing modules to setup and use their own
threadpools which either escape from or override the global settings. The
only thing preventing this is tight coordination between the global and
module level settings.
tom jackson
On Friday 03 August 2007 15:57, Stephen Deasey wrote:
> On 8/3/07, Tom Jackson <[EMAIL PROTECTED]> wrote:
> > Stephen,
> >
> > My concern over this is that one virtual server might have slightly
> > different code, for instance development vs. production, and would likely
> > share the same threadpool. What exactly is part of the thread in a pool?
> > Is there any remaining code or data from one use to another, or is all
> > data in the Tcl interp?
>
> Yes, each virtual server gets it's own interp in each thread. There is
> no sharing between virtual servers.
>
> > The problem with ns_pools is that without explicit configuration two
> > process wide threadpools are created: 'default' and 'error'. Now if any
> > virtual server sets up a threadpool named 'default', the new limits apply
> > to the process wide 'default' threadpool.
>
> Don't do that? :-)
>
> Thread pools are process-wide because memory (n * interps per thread),
> context switch overhead and caching effects, balanced against latency
> and paralelism etc. and so on, are properties of the system as a
> whole, not 1 of n virtual servers.
>
> To optimise a global resource you need a global overview.
>
>
> Anyway, here's a snippet from NEWS (same applies to pools):
>
> * New sections for server limits:
>
> ns_section "ns/limits"
> ns_param default "Default Limits" ;# Defines a limit.
>
> ns_section "ns/limit/default"
> ns_param maxrun 100 ;# Conn threads running for limit.
> ns_param maxwait 100 ;# Conn threads waiting for limit.
> ns_param maxupload 102400000 ;# Max size of file upload in
> bytes. ns_param timeout 60 ;# Total seconds to wait for
> resources.
>
> ns_section "ns/server/server1/limits"
> ns_param default "GET /*" ;# Map default limit to URL.
> ns_param default "POST /*"
> ns_param default "HEAD /*"
>
>
> Limits (pools) are explicitly set globally. The only thing to do in
> the per-virtual server section (ns/server/*) is to map existing pools
> to URLs.
>
> It isn't working for you because you have the definition of the pools
> per-virtual server, whereas you should just be mapping servers to
> pools. Works for me.
>
>
> A change of config file syntax is not the end of the world. You could
> always fall back to the old config locations if "ns/pools" doesn't
> exist, and implement 'ns_runonce -global { ... }' (or whatever) to
> prevent toe stepping.
>
>
> --
> 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.
