-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Bruce,
On 3/7/14, 3:08 PM, Bruce Weertman wrote: > Chris; > >> Just curious: why do you have maxKeepAliveRequests=1? That's... >> not terribly efficient. > > That’s a good question and perhaps we should revisit it. I’m a > little fuzzy on the reasoning (it was a while ago that we did > this), but I believe it was so that we would have a more even > distribution to our back ends. The requests often take a bit of > time to complete (10’s of seconds) and are large. So it’s not like > a web page where there’s 50 2k gif files to download or that sort > of thing. It’s one big blob of data at a time. REST services > basically. Okay. You could even disable keepalive if you really wanted to. But what really matters is the keepalive behavior on the lb. >> Are you using the native/APR connector or the Java blocking-I/O >> (BIO) connector? You can tell from the startup messages or if you >> do a thread dump, the names of the threads will tell you apr >> versus bio. >> > > BIO You might consider switching to NIO. Load-test and see if it improves things. It may not. If you have long-running requests that are neither accepting data (like large uploads) nor generating a lot of data (like returning large files), you might want to take a look at using Async. That will allow you to handle more requests at the HTTP level with fewer threads. You still need threads to do the "real" work of your web application, but you can handle more HTTP requests with fewer threads and -- especially if you have some short requests and some long requests, you won't tie-up those short requests by waiting to service the long-running ones. Switching to async does require some re-architecting of your web application and turning your brain inside-out a bit, but it's worth considering. It obviously depends on exactly what your web application actually does. >> Hmm... Tomcat used to complain when you hit maxConnections. >> Perhaps that it gone, or perhaps it only was for certain >> connectors, or maybe without using an executor (and an executor >> is always used since Tomcat 7... maybe Tomcat 6). > > I would think so. Perhaps I’m missing anything obvious. Anyway, I > really doubt I’m running out of threads. Between the threads and > the queue, I should be able to do 300 connections. That sounds reasonable. Just remember that it's the lb refusing the connections, not Tomcat. (Unless you have some information you aren't sharing with us). > I guess I should have started out with this: it’s tomcat 7 fairly > recent builds (< yr old). I should go through the source and see if > I can spot that. You will lose your mind tracing through all that. >> You might want to set up something like Nagios to watch all the >> time. You can set alarms for high-usage of the connection pool. > > Not a bad idea. > >> I was wondering if you could connect through the lb to a >> specific backend server, because it's possible that the lb is the >> one refusing the connections for some reason and not Tomcat >> itself. > > Yup, and in the end this is probably the case. Thanks for the > help. Good luck, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTGi8ZAAoJEBzwKT+lPKRYiXkP/15qxVdoiSqgSe0Pbdn28N5A /lK1ou7SmguWCWGRMTKEaUdRwcFpW3W8wry59qQCqjTSOC6qxQFo9CSYTf3KNYFr cbZHFfJDll2kznuWlna/XpTUgZ3ZyEyfCk49gmXbxN6FZKq7AErtef0+AZA8cZ4I M6jVbxNb7Ua/quH3MYHYwi+Bdp37vPBgOC3DT8a2VFeAl2iqQC+X4rPAvm++TMhS gr2I4S6vFu9JSmSTM9GfA4VlDlt5bfYQut7IozBsVaqXvkFSrSZ6Zoa1eDo5MRK/ /FxhNjlIPiAbZSY8RU2NDsndmlOYB6nO7fuWrv4RJ0p5x3byyoLqfFDiISX4CuXS vVBxg8YVxu8tgiczYtuSJ3mT0gd9Xdmm8GA7jjeem6lE4m//0VF+ocpdcgA+17MQ m9ihHxnT6fO1tAHd/0CtTLWtHgvVGVMPT+4UwHTGs7EhzY0MmHD/zT2oohk/vxRN usvCG0uTCiEW0+JP/K7cNKNPwkzEkH1NCvkZ80by5t0Ms0MUd69Nvq6MrVUcHDB2 ccBhOvppTjQet06ZypPr6smnx+eheRZFXq0iOBDA1AIxtdyg7Fl8U81l8n+xh7uL dFUCSFAh9LQTTy2xE8z+rX4RHbUJdh1ZU7sEmTZYwTDZh68J3rwrvc76MaVRQjvn Mdr3/Q4ezfKKvhvuVkTy =o+aJ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
