> From: Caldarale, Charles R <[EMAIL PROTECTED]> >> From: Caldarale, Charles R <[EMAIL PROTECTED]> >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>> Subject: Solaris 10 Tomcat performance maxes out at 2 threads >>> >>> We see throughput increase when we go from 1 client thread to >>> 2 client threads, but when we run more than 2 threads we see >>> no additional throughput. >> >> First off, does your client support more than two connections to the >> same server? If your client is an untweaked version of IE or Firefox, >> it doesn't. >> >> Secondly, you may well have some contended resource in your application >> that limits concurrency, such as number of data base connections, data >> base record locks, overly coarse synchronization, etc. Try profiling >> the app and see where threads are getting stuck. Also might try >> cranking up the number of concurrent client requests and running jstack >> (a JDK tool) against Tomcat to see where the request processing threads >> are sitting. >> >> 1. The client is a custom application that we can set to spawn threads >> according to a parameter that we set on the command line. I've kicked >> off up to 40 threads each with its own connection to Tomcat. >> >> 2. The application preloads data from its database upon start up. It does >> write information to our database on a per transaction basis, perhaps >> this is where resource contention is occurring. I agree that profiling is >> the next step. >> >> I have a poor understanding of how Tomcat spawns/manages threads. Perhaps >> I missed the appropriate documentation on this... Any clue to a good >> resource about thread management. >> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> Subject: RE: Solaris 10 Tomcat performance maxes out at 2 threads >> >> I have a poor understanding of how Tomcat spawns/manages >> threads. > > It's pretty simple, all under control of the attributes on the > <Connector> elements in server.xml: > http://tomcat.apache.org/tomcat-5.5-doc/config/http.html > > Each <Connector> maintains a pool of threads for servicing requests on > that connection. When a request arrives, a thread from the pool is > chosen (or created) and performs all the processing for that request, > including calling whatever valves, filters, and servlets are in the > chain. Once the request is finished, the thread returns to the pool. > Look at the doc and the settings in server.xml for the limits on > concurrency and number of idle threads.
To tie up this thread: I had read the documentation referenced above, but given the apparent behavior I just kept imagining that there had to be more to it that the documentation indicated. I went so far as to purchase "Tomcat - The Definitive Guide" for Tomcat 6.0 and it reiterated the Apache information about thread activity... Your original question "does your client support more than two connections to the same server?" turned out to be the correct question to ask. I am working with a client who wrote a .Net test application to do a performance test / proof-of-concept with my application. The throughput would increase when went from 1 to 2 threads, but more threads would not give up any more throughput... Originally, not having access to their code - we did profiling on the server side and it indicated a lot of client time being spent. And when we profiled on the client side it showed a lot of server time being spent... I asked for the code to figure out what their test client was doing. As it turns out the default behavior of a .Net application is to set a default connection limit of 2?!?!? (I guess this explains why IE and Firefox default to 2 connections). Not being a .Net expert I didn't realize this - but when we did a netstat on the server it definitively showed only 2 connections from the client box to the server (no matter how many client threads were spawned!!!) "Well there's your problem..." Once we set the following parameter System.Net.ServicePointManager.DefaultConnectionLimit = 100; Everything was more or less happy, until we ran into a CPU capping issue on the Solaris machine, we were maxing out at 50% CPU capacity. This was easy to tweak and now we are more or less taking full advantage of the CPUs. Many thanks for your insights and help! John --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
