Hi Nick, Thanks for your valuable feedback. The point I was trying to make when I mentioned that all requests from the same browser results in same thread is not a mere coincidence. The reason why it may not be sheer luck is because we have seen this on production which is accessed by more than 1000 simultaneous users on the site. Currently we trace the user journey by the thread id in the logs and my observation is all 1000 users (across the globe) gets the same thread id from the pool when they access subsequent URLS from the browser. It makes me feel as if the thread is not returned to the pool till the session times out or the user has closed the browser. Although the behavior is weird because tomcat won't should not have a persistent connection as it would mean improper use of the resources (thread).
I read the connector documentation and my gathering is threads are allocated per request and they are returned to the pool once the HTTP response in sent back to the client. However, if that's the case my thread ids should be different when the user accesses multiple pages on the site from same browser. Also printing the thread id may not be the right way to trace user journey then. Also I understand there may be difference in milli seconds or seconds between 10000 concurrent user requests and it may not be exactly 10000 users in system at one go but I can also simulate 10,000 concurrent request at same time even in milli seconds. Google analytics does show 10,000 concurrent users. In that case I assume it will leverage 10,000 concurrent threads. Let me know your thoughts around it. Regards, Saurabh Agrawal Manager Technology | Sapient -----Original Message----- From: Nick Williams [mailto:nicho...@nicholaswilliams.net] Sent: Wednesday, March 20, 2013 2:31 AM To: Tomcat Users List Subject: Re: Tomcat Behavior on Multiple HTTP requests from same browser On Mar 19, 2013, at 8:49 PM, Saurabh Agrawal wrote: > Hi Nick, > > We currently have 8 tomcat nodes with each node configured to have 1000 > maxThreads. We did a round of performance test for 8000 concurrent users and > the observation was that the number of active executor threads were far less. > > My understanding was if 8000 concurrent users hit the site at the same time, > 8000 executor threads are required to suffice the requirement of all the > requests. However, I see far less executor threads in action when we put a > load of 8000 concurrent users. > Yes, this is to be expected. Tomcat / the JVM will try to be as efficient as possible. A thread will only be in use during an active request. Just because you have 8,000 simultaneous users does not mean you have 8,000 simultaneous requests. Remember that "real" users will have some time between each request, ranging from a few seconds to several minutes depending on the page and the user. A good load testing tool like JMeter, The Grinder, or NeoLoad (just examples) will mimic this behavior by putting varying pauses between requests. It sounds like whatever tool you are using is doing this--that's good! So, 8,000 simultaneous users might result in only 400-500 simultaneous requests (just a guess; depends on your application and its user base). In this case, you'd only see 400-500 threads used across the cluster. In your small-scale test, where each request from your browser got the same thread, that could just be pure luck. If you're the only person using the server, it's likely that the Thread pool is extremely small, thus the odds are high that the same thread would get picked over and over again. However, in a high-load environment, this will not be the case, and the number of threads will nearly always be less than the number of simultaneous users. I'm glad to see that you have a working cluster of some sorts and that you are performing load tests to evaluate its performance. This means you are on the right track, making some good decisions, and have obviously done a little reading. I suspect a little more reading of the Connector documentation will help you understand exactly how all of this works. Nick P.S. Please remember to bottom post. Don't top post. > -----Original Message----- > From: Nick Williams [mailto:nicho...@nicholaswilliams.net] > Sent: Wednesday, March 20, 2013 1:44 AM > To: Tomcat Users List > Subject: Re: Tomcat Behavior on Multiple HTTP requests from same browser > > > On Mar 19, 2013, at 8:37 PM, Caldarale, Charles R wrote: > >>> From: Saurabh Agrawal [mailto:sagra...@sapient.com] >>> Subject: Tomcat Behavior on Multiple HTTP requests from same browser >> >>> Let's say I hit http://localhost:9001/homepage.html. Upon hitting the URL, >>> tomcat will assign one of the worker threads (say Thread 1) from the pool >>> to the HTTP request which will be processed and then response will be sent >>> to the client. Now if I hit a link on homepage which is for login, a >>> separate >>> HTTP request will be initiated from the same browser. >> >>> What I want to understand is if the Tomcat will keep Thread 1 as persistent >>> thread to server the second request (for login) from the same browser or >>> will >>> it assign a separate thread from the pool ? >> >> Normally, the first available thread from the pool is used for each request. >> However, if you are using the BIO <Connector> with keep-alives enable *and* >> the browser is using keep-alives, the same thread as long as the HTTP >> connection is active. >> >> See the HTTP <Connector> doc, especially the Connector Comparison at the end. >> >> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html >> >> - Chuck > > I think the most important thing to say here is that there is NO guarantee > that the browser will always keep the connection alive, therefore there is NO > guarantee that every request will get the same thread. You should never rely > on having access to the same thread from one request to the next. (That is > what HttpSessions are for.) > > If you need to support 20,000 simultaneous users, you are going to need a > farm of servers. Just one server will not be enough. One simultaneous user > does not equal one thread needed: when a user is between requests, a thread > can be servicing some other request. You should read the Tomcat documentation > thoroughly, especial the sections on connection management, session > management and clustering. > > Nick > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
