On 14.11.2006, at 22:44, Tim Lucia wrote:
Let me now ask my own question about this -- Lambda Probe is a
great tool
for inspecting your app's current state (and Tomcat's overall
state.) Is it
possible to get, using /probe or any other app (including tomcat's own
manager) the current state of the connection pools in a machine-
readable
form (XML, one per line, CSV, etc.)? One that could easily be
parsed with
perl for consumption by MRTG? Lambda Probe's generated HTML isn't too
easily parsed, at least for my novice perl skills.
You might want to have a look at Tomcat's JMX Proxy Servlet (part of
the manager webapp, IIRC):
http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html#What%20is%
20JMX%20Proxy%20Servlet
The JMX Proxy Servlet is a lightweight proxy to get and set the
tomcat internals. (Or any class that has been exposed via an MBean)
Its usage is not very user friendly but the UI is extremely help
for integrating command line scripts for monitoring and changing
the internals of tomcat.
If that's not enough, MX4J's HTTP adaptor serves XML, and lets you
register custom XSLT stylesheets to transform the output. The default
stylesheet transforms the XML to HTML.
Regards,
Dan
-----Original Message-----
From: Tim Lucia [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 14, 2006 4:29 PM
To: 'Tomcat Users List'
Subject: RE: session replication/tomcat 5.5
I forgot to mention that we peak at about 6000 sessions on the
average day.
The all-time max for 2006 is 6810 sessions.
For monitoring, we do several things.
1) We use lambda probe
2) We use MRTG and some scripts to graph things that the manager will
readily disclose, like requests, threads, sessions, etc.
3) We use MRTG and some built-in application statistics for
application-specific statistics
At some point, I will probably use lamdaprobe to populate MRTG
graphs of the
connection pools. Right now we don't really monitor them per se
When you say "sessions per instance" keep in mind that sessions are
shared
across the cluster (or domain if so partitioned), otherwise it
wouldn't be
fault-tolerant.
There is no pro-active alert if something is bad, other then the
customers
call the support line ;-) But we do have a large monitor in the
engineering
department visible to most of us with the vital MRTG graphs on
display.
Tim
-----Original Message-----
From: David O'Dell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 14, 2006 3:03 PM
To: Tomcat Users List
Subject: Re: session replication/tomcat 5.5
Good to hear that someone is using this.
I want to try this out in my environment with 8 instances of tomcat
each
with around 2,500 sessions per instance.
Does this sound feasible?
Also how do you monitor the cluster status?
Tim Lucia wrote:
As a case study, I have, in production, 4 Dell 2850 servers
(running Red
Hat
Enterprise V4.) Apache httpd on one, using JK for load
balancing. The
other three are running Tomcat in a 3-way multicast cluster,
multicasting
with replication on a private VLAN (192.168.x) The application
accesses
several DB servers running Oracle and MySQL, depending on the DB
requested.
Over time, this handles 2 requests per second average, with peaks
at about
5-6 requests per second (Per Tomcat, so times 3). This does not
begin to
tax the Tomcat servers for memory or CPU. The bulk of the time is
database
latency. Our usage profile is extremely regular and predictable
-- we
service school districts and they mainly use it from 8 to 3 (local
time.)
This configuration has been very reliable and far-surpasses the
system it
replaced - based on IIS and JRun.
HTH,
Tim
-----Original Message-----
From: David O'Dell [mailto:[EMAIL PROTECTED]
Sent: Monday, November 13, 2006 2:27 PM
To: Tomcat Users List
Subject: session replication/tomcat 5.5
Is anyone using session replication in production?
Is there an alternative to using multicasting?
In the doc http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html
It states "This is an algorithm that is only efficient when the
clusters
are small."
I have 6 tomcat instances behind a load balancer, is this still
considered small?
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
