> From: David Kerber [mailto:dcker...@verizon.net] > I definitely should hook a profiler to the app so I can be sure of > what's taking the time, though.
Yes. If you don't measure it, you don't know whether you're fixing the right problem! Also consider connector, then if necessary process and OS limits on the number of concurrent connections. Do you usually have connector threads sat idle, or are they all reading and processing requests most/all of the time? A thread dump will tell you - the last one you posted had at least one thread in the pool waiting for a connection, and you can simply spot which others look similar. The other way to check would be to monitor the depth of your connector's socket's accept queue, but I'm not aware of any way to do this in Windows. At this point, I'm guessing on any remaining bottlenecks. I recall your network is gigabit from the router (I think I've recalled correctly), but also check: - Is the firewall or router overloaded? Highly unlikely if they're properly specced, but I have been in one data centre where the bottleneck turned out to be the routers.* - What's your external connectivity like? Gigabit from the router is irrelevant if you're trying to fit 20 Mbit/s of data down a 10 Mbit/s pipe :-). - Peter * Names elided to protect the innocent, but a manufacturer's claim that a particular spec of router could handle two ISDN primaries turned out to be correct in the USA (23 B-channels per PRI) and wrong in Europe (30 B-channels per PRI). --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org