Gustaf,
Earlier yesterday I was composing this message, but didn't finish it.
Essentially the one I did send was an answer to this. I was concerned about
the timeout values causing a thread exit. But it seems unlikely to every help
performance, so I'm not going to worry about thread exit under these
conditions.
But also below I discuss more interesting thread maintenance ideas which
should work well if the threads don't timeout. Essentially I can keep threads
ranging between min and max by adding a boost factor to min when calculating
the number of threads to create.
Dossy might be interested in the dynamic tuning effect which takes place here,
but it doesn't change the range (min-max) originally set, or hand configured.
It is as responsive as possible to load changes.
More later.
tom jackson
On Sunday 21 October 2007 11:42, Tom Jackson wrote:
> (Note: none of my changes have been committed, they are not complete or
> integrated with Gustaf's code yet.)
One thing bugging me with the pool operation is that it doesn't maintain
minthreads. The basic problem is that the timeouts in the while loop get set
long before it is apparent that the thread exit will violate the minthreads
setting.
This is very bad (maybe unfortunate for performance) for threads which have
not reached ncons, essentially they shouldn't exit. I think the problem can
be fixed in the while loop, but I'm not quite sure how.
Anyway, the other issue is that I have at least found a way to maintain
minthreads during constant load (lulls less than timeout). This still leaves
an important issue: getting the server to use more threads when there are
queued > 1 requests.
I'm experimenting with a new dynamic variable which is added to minthreads:
boostmin. All the adjustments are made in the experimental
NsCreateConnThreads:
void
NsCreateConnThreads(Pool *poolPtr)
{
/*
* Reap any dead threads. Move to NsQueueConn:
*/
NsJoinConnThreads();
/*
* Create new connection threads.
*/
Ns_MutexLock(&poolPtr->lock);
/*
* Dynamic increase or decrease min threads with boostmin
* boostmin is added to min up to max-2. max-2 allows threads
* to exit on timeout.
*
* boostmin starts at zero and goes up 1 if queued requests > 1
* boostmin goes down if there are idle threads
*/
if (poolPtr->threads.idle == 0
&& poolPtr->threads.boostmin > 0) {
--poolPtr->threads.boostmin;
}
if (poolPtr->threads.queued > 1) {
poolPtr->threads.create += 1;
if (poolPtr->threads.boostmin
< poolPtr->threads.max - poolPtr->threads.min - 2) {
++poolPtr->threads.boostmin;
}
}
if ( poolPtr->threads.current
< poolPtr->threads.min + poolPtr->threads.boostmin ) {
poolPtr->threads.create += poolPtr->threads.min
+ poolPtr->threads.boostmin - poolPtr->threads.current;
}
while (poolPtr->threads.create-- > 0) {
NsCreateConnThread(poolPtr);
++poolPtr->threads.idle;
++poolPtr->threads.current;
}
Ns_MutexUnlock(&poolPtr->lock);
Ns_CondBroadcast(&poolPtr->cond);
}
So basically, if there are idle threads, boostmin is reduced by 1, but never
below zero.
Then if there are queued threads > 1, boostmin is increased by 1. This
continues with each call until the effective minthreads is maxthreads-2.
Anything above this doesn't allow timed out threads to exit (in the current
code).
So what happens is that very quickly threads.current ramps up to maxthreads-2.
If there is a lull, and therefore idle threads, the process slowly reverses
itself. Performance appears to be enhanced with this change, but my
benchmarking tools are very primitive.
--
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.
