-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Saurabh,
On 3/20/13 3:27 AM, Saurabh Agrawal wrote: > 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. Is the reverse true? Do you ever see thread A used by more than one client? Or is it a one-to-one mapping? > 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). Tomcat is doing its job just fine, otherwise half the Java servers in the world would lock-up and stop working. What may be happening is that your browser is maintaining a keep-alive connection long enough (maybe 10 seconds?) that the "next" request can be sent over the same connection, and will get the same thread. So, if you have fairly quick-responding clients, you may see that each one is kind of monopolizing a thread for a while. Honestly, if that's the case, it's a *good* case as long as you aren't running out of threads. It would be interesting to see how you have your <Connector> configured, and how you have your load-balancer configured, too. > 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. Users != requests. 10,000 concurrent users might generate 1000 simultaneous requests (that is, requests in-progress at a particular instant), unless they are really pounding on your cluster. What do your thread-pool usage metrics look like? Are you collecting that data (hint: do it)? Are you graphing them (hint: do that, too)? Doing time-based graphing can help you visualize your user load (measured in requests-per-second versus total average concurrent users, which is a nearly useless metric unless you have 100MiB sessions or something and you have to use that as part of your capacity plan) and you can even see things like "hey, every day at 11:00 PDT we hit our maxThreads for 5 minutes". That lets you know that you need to give yourself a little more breathing room and then watch for another couple of days. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlFJwI8ACgkQ9CaO5/Lv0PD8QACdHdYnkzzZbcbmq4dmayaguTp/ eDcAn2dGIn63MJRtbllnJcaicIClmJDp =AfQh -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
