We basically do this, but there are times where some requests have to
execute on a "less than ideal" server because we do not have all data
resources shared across all servers. Plus, even if you separate them
out, there will be users that execute fast searches and slow searches.
This is a case where your threadpool thing would be useful, to say
"we will simultaneously run N fast searches but only M slow searches".
I had suggested something similar when the TCL/thread init problem
first showed up: having different classes of threads: a pool to handle
TCL requests, another pool to handle static requests, another to
handle Phython requests, etc. We have achieved basically the same
thing by manually forcing all static requests to go through a
different server, but it would have been easier to setup if AS did
this on its own. Plus it seems it would scale better: if you have a
site that serves 80% static content but runs a TCL script 20% of the
time, every one of their server threads will have all the TCL crap
loaded even though only a few need it at any given time.
I agree with your basic logic though - maxthreads will be way lower in
3.X for us than in 2.3.3 and I'll be more careful about upping it.
With 2.3.3, raising it was a non-issue, because 50 threads didn't take
up significantly more resources than 10 (although I did/do have some
concerns about whether the wake-up mechanism would wake 1 thread or
all 50 when a new request came in...)
Jim
> Yes. If you can classify your requests according to resource usage,
> then you can improve the site by having separate servers dedicated to
> different request types.
>
> At ArsDigita, I suggested this configuration (but I don't know if we
> every fully deployed it): one server (or set of servers) for completely
> static entities like images and style sheets; one for "lightweight"
> pages - bboard messages/indexes, classified ads, etc.; and one for
> "heavyweight" pages - various types of searches.
>
>
> +---------- On Sep 21, Jim Wilcoxson said:
> > Rob - if we look at a simple case of all requests being CPU bound,
> > 2 CPUs, and service time varies from .5 seconds to 3 minutes, then
> > maxthreads should be set a 2 to maximize jobs per second. But if 2
> > 3-minute jobs come in, everyone suffers. If maxthread were set higher,
> > jobs per second may be lower because of a decrease in efficiency
> > (context switches increase), but I have happier customers. :)
>
