The tuning guide says: --- Thread settings are sometimes helpful, sometimes not. In ns/server/servername, the options are "connsperthread", "flushcontent", "maxconnections", "maxdropped", "maxthreads", "minthreads" and "threadtimeout. In nearly all cases the defaults are optimal, with the exception of maxthreads which should be carefully adjusted based on your load. Along with "maxthreads", the "maxconnections" setting can be tricky, since making it too large can cause your system to thrash. ---
The parameter connsperthread is put into a variable but never referenced, at least not that I can find. I was a little confused about the relationship of maxconnections, maxkeepalive, and maxthreads, so explored some. A blob of memory is alloc'd to hold maxconnections connection structures. This is the number of connection requests the server will accept from the socket queue. If there is no available connection block, the server goes "busy" and stops accepting connections (they queue up on the socket queue) until a thread finishes servicing one of the already-accepted connections. On this transition from busy to not-busy, the server writes out "server ready - resuming". So this message means that your server got busy enough that it had to leave requests queued in the socket queue and couldn't immediately accept them. I don't quite understand the value of accepting connections even though there is no thread available to service the request (this occurs if maxconnections > maxthreads). From my point of view as a webmaster, I will probably set maxconnections and maxthreads equal. This way, if a browser hits our site and no thread is available, the user will see "contacting blah.com" during the delay and assume there is some network problem. If I set maxconnections > maxthreads and maxthreads is too low, users will see "blah.com contacted, waiting for reply" and it'll look like our site is slow. Okay - a bit deceitful. If maxconnections = maxthreads, the "server ready - resuming" msg can be used to see when maxthreads was exceeded, although it would be interesting to log how long the delay was between going busy and going non-busy. No way to tell that right now. "maxdropped" is unusual. AS keeps a count of the number of times a request came in and it could not be added to the connection queue because it was full. The connection is not really dropped though; the server waits until a thread is finished, resets the #dropped count to zero (no idea why) and outputs the "resuming" msg, then queues the held connection on the connection queue and a thread grabs it. I can't see how maxdropped would have any effect unless you set it to 1, which would cause your server to terminate the first time the connection queue is full. Not a good idea. Some people have posted that their server hangs under a load. You may want to try decreasing maxthreads and maxconnections to stress-test the "resuming" mechanism. A typical server with the default configuration of maxconnections=100 would probably never get in this resuming state. Or an alternative to avoid the problem would be to keep increasing maxconnections until you never see the resuming message in your logs. Apologies for the lengthy post... Jim
