> 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
