On 3/14/2011 8:21 AM, Peter Crowther wrote:
On 14 March 2011 12:08, David kerber<dcker...@verizon.net> wrote:
Dave, could you give us any more information about your network? What is
the piece that's at 80% utilisation when you see the trouble? Is it a
point-to-point connection, or an Ethernet LAN, or what? If it's Ethernet,
what hardware are you using for connection?
It's our internet connection to the outside world, which is a T-1, with a
Cisco ASA for the firewall. The connections we're processing are from a
bunch of separate customer sites, but which all connect to us through the
customer's gateway.
A T1 used to be 1.5 Mbit/s bidirectional, back when I did my basic network
training (which, I admit, is a good few years ago). Is it still? If so,
Yes, 1.5Mbps bidirectional
that's quite low. I have 34 Mbit/s down, 1.5 Mbit/s up to my house for the
price of a decent restaurant meal for one per month. What might your
Me, too (mine is 10 down/2 up), but FIOS isn't available where we are,
or I'd go that route in about half a heartbeat. Cable is, and is
faster, and we actually use that for our backup, but the reliability
isn't good enough for it to be our primary connection (frequent short
outages).
upgrade options be?
We're in the process of upping our bandwidth with our current ISP, but
the options ae rather limited without having to change our IP address,
and therefore all our customers' firewall settings, Lan-2-Lan vpns, etc.
So changing that, while doable, is a last resort.
Also, see if the ASA can give you any usage statistics. There's a small
chance that you're saturating your firewall if you have a very large number
of short-lived connections. Cisco's figures don't always stack up here - in
Yeah, I've been looking at that as well, but as you say, the numbers
don't always stack up.
the past, I've had to debug load problems with Cisco routers that were
supposed to be able to handle two ISDN PRIs, and couldn't when there was
heavy call setup and termination load. I accept this isn't quite a parallel
case!
Tomcat might still be the problem, but I'd certainly take a long hard look
I never really suspected tomcat as the cause after I did my app tuning
work a year ago or so, but since that's the easiest to test and
eliminate, I started there.
at your network infrastructure. Does the server really have to be on your
site, or can you have a server in a bunker somewhere that passes hourly /
daily reports to your site via a heavily compressed file format? Our
telemetry system does that, for example, just running in a VM (for
reliability, believe it or not).
Hourly or daily wouldn't be enough, but every minute or every 5 minutes
might be a possibility, and one we hadn't thought of; thanks for the
suggestion. We're also looking at moving the entire process to a data
center hosting service as well.
D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
