Andrew Miehs wrote: > A connection pool of 750 threads seems unusable... How can 1 thread per > connection scale? or have I misunderstood how tomcat uses its > connection pool? And should all of these threads ever have something to > do at the same time, the box would just fall over with a load of > 750!!!!
Keep in mind that most of these connections will not be utilizing much CPU, they will most likely be busy sending/receiving data (or if keep-alive is on waiting doing nothing). > Would it not make more sense to use a smaller connection pool, and set > up queues? If you are serving resources which utilize a lot of CPU, then yes, it can be beneficial. You can use the OS's connection backlog on a listening TCP/IP socket as your queue. See the acceptCount parameter of the HTTP Connector. The default configuration has this set to 100. So if you only have 10 threads in your pool and all are busy, the OS will queue up to 100 additional connections to wait for a thread to become free. If more than 100 connections are waiting, any further connections will have their connection refused. > Would it not then be better when the request has been processed, to put > this into a second queue for requests which then go to the backend, > etc, etc? So many threads can't help performance. Wouldn't the kernel > be busy the whole time with context switching? and no user would ever > get any data back.... Regarding kernel-switching, note my earlier comment that you will find that most connections are waiting for TCP/IP data to be either sent or received. In addition, any modern OS on decent hardware will scale to thousands of threads without any issues. -Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
