PERFECT! Thanks to you and Dan Baumann... -----Original Message----- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 4:59 PM To: Tomcat Users List Subject: Re: session replication/tomcat 5.5
Have a look at: http://yourserver:yourport/manager/jmxproxy?qry=*:* to find out about the available monitoring info. Once you find the beans you are interested in, you can make the query *:* more precise. Tim Lucia schrieb: > 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] --------------------------------------------------------------------- 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]
