Forum OpenACS Q&A: Re: Aolserver 4.5 multithreading

Collapse
21: Re: Aolserver 4.5 multithreading (response to 20)
Posted by Tom Jackson on 10/05/07 05:31 PM

Last week there was a similar question on the AOLserver list, here is what I guessed was going on:

You're not doing anything wrong. You have a thread timeout. So after 60 
seconds, the idle thread exits. Maybe there is a bug in pools.c, but what is 
happening is that at startup, minthreads are created. If you go in and 
increase minthreads after starup of the pool, the minthreads will not 
increase, ever. But if new requests come in, new threads will be created. 
They are probably being serviced so fast that you never get too many at once 
showing up. If this isn't the case, then it could be a problem. 

So maybe play around with the timeout value, maybe if it is zero they don't 
timeout. If you want threads to exit at some point, use maxconnections to 
make them exit. 

So the problem is very likely that as maxconns is reached, threads are 
deleted, but there is never any check that numthreads have fallent below a 
minimum value. Hopefully you will reach a number of threads necessary to 
service the requests without going over maxthreads, but minthreads appears to 
be only a hint for startup, after that the threadpools regulates itself to 
minimum resources. However...does it ever reach zero, because if it does, I 
have noticed that the threadpool no longer responds to requests. This would 
be a definite bug. 

tom jackson

On Monday 01 October 2007 07:45, ** ** wrote:

> You said that current should never drop below min. But in my case after
> threads have serviced configured number of requests they start to die. idle
> and current keeps dropping  until 0 and never comes up again.
Collapse
22: Re: Aolserver 4.5 multithreading (response to 21)
Posted by Tom Jackson on 10/05/07 05:55 PM
I should clarify this comment. If maxthreads is set to zero after startup, as new requests are serviced, the thread will exit until all threads are gone. Since maxthreads is zero, no new threads will be created...but the driver thread still hands off requests which are never serviced. It should probably be illegal to set maxthreads to less than 1.

Maintaining at least minthreads could become difficult. I think you could consider it a bug, but maybe not. The result is this: your server will regulate threads down to the number required, a 'high water mark' less than or equal to maxthreads.

The best way to test this is to use something like apache bench. Set the concurrency above the minthreads and see if you can get it to go back over that amount. (Then let it rest and see threads exit, during testing you can set a low thread timeout.) Then set concurrency to something above maxthreads and see how it performs. You can test pages which are slow and see what happens. You will probably also need to keep pushing up the number of request to run (-n 500, or whatever), so that each thread gets multiple requests, and the queue gets a little full. You can also set the maxconnections to different values (very low and very high) and test that. Threads are started very quickly, but their startup cost is spread over maxconnections requests.

I'm guessing that what you will discover is that minthreads is a good hint at startup, but may be too many. If it is always too many, then you are wasting memory. Only by watching a production system can you determine a reasonable value for minthreads. If you have massive fluctuations in the number of requests over a time larger than thread timeout, then minthreads is pretty useless, you can expect it to drop below that soon after startup.