On 8/4/07, Tom Jackson <[EMAIL PROTECTED]> wrote:
> 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.


I agree, there are many possible configurations (some more useful than
others)...


> 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.


The old way didn't absolve you from setting threads correctly. If you
had two virtual servers and you thought the ideal number of threads
for an nsd process on a particular machine was 20, you give each
v-server 10 (or some other portion).

But here's the problem: server1 gets slashdotted, uses up all it's
conn threads, and starts rejecting connections. Meanwhile server2 sits
idle with spare threads.

You could say: well, give each server 20 threads if that will max out
the server. Now both servers get slashdotted and response time goes
through the roof.

Threads are a global resource.


> Maybe an
> admin section needs to always have available threads if the whole server is
> jammed up for some reason.


Use ns_pools and ns_limits in combination.

You could, for example, create a pool with 20 threads and map both
servers to it. Create a limit with maxrun 15 and map both servers to
it. Now, when server1 overloads there will still be 5 threads left for
the other v-server.

Use pools to separate by type: threads with interps vs. without, error
pool, etc. Use limits to implement some QOS policy, such as the /admin
example.


--
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