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.
Tim -----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]
