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.

Reply via email to