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. :) If memory is constrained, that is a different story. Jim > > +---------- On Sep 21, Jim Wilcoxson said: > > 4. Related to #3, I'm not sure how to evaluate what to use for > > maxthreads with 3.X. With 2.3.3 we have checkstats turned on every 2 > > minutes. I look through the interval stats periodically. If it looks > > like we are hitting maxthreads several times a day, I bump it a > > little. With 3.X this doesn't make sense if the thread startup time > > is 2-3 seconds. I need to bump maxthreads when the wait time for a > > thread to start handling a request exceeds 3 seconds. Is that > > information available? > > Just because you're hitting maxthreads doesn't mean you should increase > maxthreads. Doing so could mean that you're causing everyone's response > time to go down, but not increasing throughput. > > If you have enough CPU/RAM/database/etc. to handle N simultaneous > requests on a loaded system, then setting maxthreads to N will give you > the best throughput, in terms of requests completed per second. Setting > it to N+1 will give you the same or slightly less throughput (bad), and > will make each request take a little longer to complete (also bad). The > more you raise maxthreads, the longer each request will take, with a > declining throughput. >
