Andrew,
It might be a bug, and I just discovered another one related to this.
If -timeout is set to zero or less, the value is still used, but it should
probably be set to null, meaning infinite timeout:
403 if (poolPtr->threads.current <= poolPtr->threads.min) {
404 timePtr = NULL;
405 } else {
For one, I've moved this check inside the following while loop so it gets a
chance to change on each cycle, but I also made these modifications:
. if (poolPtr->threads.timeout <= 0
. || poolPtr->threads.current -1 <= poolPtr->threads.min) {
. timePtr = NULL;
. } else {
The behavior I see with apache bench is that after a bunch of requests are
finished, most of the threads exit, if there is a timeout. However, this may
be a result of the fact that apache bench sends extra requests and then
disconnects them. The problem is that each thread calculates for itself what
to do, and there is no way for them to know what other threads are going to
do within the next cycle.
I've started looking at JMeter, because apache bench doesn't really do what
you ask it to do, but maybe that is good. You discover things you weren't
testing for. For one, even with concurrency set at some number, fast requests
will lead apache bench to send another request before cleanup is complete on
AOLserver. AOLserver thinks the concurrency is higher than ab, up to double
the concurrency. I know this because I'm testing a boost factor for
minthreads. On large requests, threads.current never reaches the concurrency
level of ab, but on small requests, it can exceed it, up to maxthreads-2.
With my latest changes to my setup, the threadpool moderates to something
else: with high concurrency, the idle threads value tends to zero. If
concurrency is less than maxthreads, the queued requests tends to zero.
Eventually, if concurrency is less than maxthreads, both of these values tend
to zero, they bounce around a low number and zero, so all threads are busy
and the queue is empty. Otherwise the trend appears to be
current+queued=concurrency and idle=0.
tom jackson
On Monday 22 October 2007 07:48, Andrew Piskorski wrote:
> On Mon, Oct 22, 2007 at 06:30:40AM -0700, Tom Jackson wrote:
> > My only point here was that I'm going to stop looking at the timeout
> > parameter, and timed out threads as an issue. If threads timeout, the
> > number of threads in a threadpool will drop below minthreads, usually to
> > zero.
>
> But isn't that a bug? If not, just what is "minthreads" supposed to
> really mean?
--
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.
