Tom Jackson schrieb:
I can try running my tests again with 3-5 threads, what other parameters were
there? Does this get stuck running OpenACS on any machine, or just on
openacs.org?
As written before, i set maxthreads to 5 and maxconnections to 3 to
trigger the problem.
I did not mess with openacs.org, but reproduced the problem under mac os x.
Also, Gustaf, the maxconnections should be higher...with maxconnections=3 you
are exiting a connection thread every three requests, is this how you want it
to work?
yes, i wanted to trigger the bug. When the problem occured, openacs.org
had different settings
(maxthreads 5 maxconnections 10).
Very interesting, I'll look into this more today. One thing I didn't try was a
configuration where maxconnections was lower than the number of simultaneous
requests from Apache Bench.
That is not the point. Run ab with more parallel requests than
maxthreads, such
that requests queue up. As long as maxconnections is high enough, the
connection
threads will process the queued requests. If the number of queued
requests is
higher than the number of maxconns, matters degrade. Having one or two
queued requests on a thread exit (due to maxconn exceeded) is no real
problem,
since on the next request, a new thread is started, which will care
about the
queued request as well. That means, that under "good conditions", it is
possible
that there are e.g. 10 requests queued, but a slow and steady heartbeat of
request will cause the queue to empty itself, such that aolserver recovers.
The worst case scenario is actually maxconnections 1 (stop every
connection thread after every request). In this situation (without
my patch) if a queue piles up, it is never shrinking.
Actually, if minthreads is set to a value > 0 (it was not set), then idle
threads should care about queued requests. Maybe the
easier fix is to set minthreads per default to 1. I will
try this, when i am back home (in a couple of hours).
How exactly does the patch work? It appears to simply
extend the tour-of-duty for a thread,
yes
but does the exiting thread ever get to trigger the queue to
create new threads?
no, i have not modified anything in this regard. When a thread
processes all queued requests before exiting, there is no
urgent need to create a new connection request. The next
incoming request will create a new thread on demand.
Once threads die,
it is nearly impossible to get the number of threads
back up,
i have not observed this in my test, the problem appears
with reaching maxthreads. This does not exclude, that there
might be another problem.
-gustaf neumann
--
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.
