You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David O'Dell <do...@corp.meez.com> on 2006/11/13 20:27:10 UTC
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: session replication/tomcat 5.5
Posted by Mark Hagger <ma...@m-spatial.com>.
On Tuesday 14 November 2006 16:49, Caldarale, Charles R wrote:
> Your premise is well taken, but the math is a bit shaky. 99.99% uptime
> per week equates to 1 minute of downtime in that period, not one hour,
> which emphasizes you point even more.
Ooops, how embarrassing, I calculated everything in seconds and then
mysteriously wrote minutes all over the email. Probably didn't drink enough
coffee today.
Mark
________________________________________________________________________
This email has been scanned for all known viruses by the MessageLabs SkyScan service.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: session replication/tomcat 5.5
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Mark Hagger [mailto:mark.hagger@m-spatial.com]
> Subject: Re: session replication/tomcat 5.5
>
> 99.99% gives you a whole 3153 mins per year, or 52 hours, or
> 1 hour per week of operation per year.
Your premise is well taken, but the math is a bit shaky. 99.99% uptime
per week equates to 1 minute of downtime in that period, not one hour,
which emphasizes you point even more.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: session replication/tomcat 5.5
Posted by Mark Hagger <ma...@m-spatial.com>.
Hi,
Sorry to go slightly off the topic, but I have to express surprise (laugh) at
the 99.99% availability bit. Its highly laudable to aim at that, indeed
mobile phone operators claim to aim for, or even require, "five 9's", ie
99.999%, which equates to a massive 315 minutes downtime per year (and
between you and me I _know_ that mobile operators never even get close).
99.99% gives you a whole 3153 mins per year, or 52 hours, or 1 hour per week
of operation per year....And thats not much to play with.
As all of us who have tried it know that trying to make a system highly
redundant so that there are no single points of failure necessarily makes the
whole thing more complicated and thus if something does go wrong (2 switches
die at once or something, followed by a disk array failure, and causing an
unexpected knock on effect etc etc), you can suddenly find that your
massively complex system has all fallen apart and takes a few hours to put
back together....
Speaking from experience of the tomcat session replication issue, we use it
and it works well, although in fact we have just 2 tomcat instances at this
time. However, problems can occur if a server dies whilst there are a lot of
active sessions, after recovery of the failed box trying to bring the server
back into the group and thus attempting to copy all those active sessions
back can impose surprisingly and dangerous load levels on the "live" server.
On a few occasions this did actually grind the live server to a halt and we
had to restart the entire system from cold, dumping all the live sessions.
I'm still searching for the optimal configuration for this.
Still, I wish you well in the 99.99% availability quest.
Mark
On Tuesday 14 November 2006 12:09, Mirou, Antoine wrote:
> Hello,
>
> Could you please give an example of "really big sites" ?
>
> How do you organize your cluster (how many members/domains, ...) ?
>
> Do you use Farm-deployer ?
>
> Do you use session replication ?
>
> How do you manage/monitor the cluster ?
>
> Many questions, sorry, but I'm currently studying the possibility of
> setting up a cluster of tomcat 5.5 for a 99.99% available app with lots of
> user connexions, and I really don't feel confident of my ease with tomcat
> clustering...
>
> Thanks for your answers.
>
> Regards,
> Antoine
>
> -----Message d'origine-----
> De : Peter Rossbach [mailto:pr@objektpark.de]
> Envoyé : mardi 14 novembre 2006 09:31
> À : Tomcat Users List
> Objet : Re: session replication/tomcat 5.5
>
> Am 13.11.2006 um 20:27 schrieb David O'Dell:
> > Is anyone using session replication in production?
>
> Yes, at really big sites :-)
>
> > Is there an alternative to using multicasting?
>
> No, but you can implement you own membership service.
>
> > 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?
>
> Yes, but split your cluster into different domains. Use Apache/mod_jk
>
> >= 1.2.19 with the
>
> domain attribute. The mod_jk loadbalancer can then route to the right
> backup.
>
> regards
> Peter
>
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
> Ce message et toutes les pièces jointes (ci-après le « message ») sont
> confidentiels et établis à l'intention exclusive de ses destinataires.
> Toute utilisation de ce message non conforme à sa destination, toute
> diffusion ou toute publication, totale ou partielle, est interdite, sauf
> autorisation expresse. Si vous recevez ce message par erreur, merci de le
> détruire sans en conserver de copie et d'en avertir immédiatement
> l'expéditeur. Internet ne permettant pas de garantir l'intégrité de ce
> message, la Caisse des Dépôts et Consignations décline toute responsabilité
> au titre de ce message s'il a été modifié, altéré, déformé ou falsifié.
>
> This email message and any attachments ("the email") are confidential and
> intended only for the recipient(s) indicated. If you are not an intented
> recipient, please be advised that any use, dissemination, forwarding or
> copying of this email whatsoever is prohibited without Caisse des Depots et
> Consignations's prior written consent. If you have received this email in
> error, please delete it without saving a copy and notify the sender
> immediately. Internet emails are not necessarily secured, and Caisse des
> Depots et Consignations declines responsibility for any changes that may
> have been made to this email after it was sent.
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ________________________________________________________________________
> This email has been scanned for all known viruses by the MessageLabs
> SkyScan service.
________________________________________________________________________
This email has been scanned for all known viruses by the MessageLabs SkyScan service.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: session replication/tomcat 5.5
Posted by "Mirou, Antoine" <an...@caissedesdepots.fr>.
Hello,
Could you please give an example of "really big sites" ?
How do you organize your cluster (how many members/domains, ...) ?
Do you use Farm-deployer ?
Do you use session replication ?
How do you manage/monitor the cluster ?
Many questions, sorry, but I'm currently studying the possibility of setting up a cluster of tomcat 5.5 for a 99.99% available app with lots of user connexions, and I really don't feel confident of my ease with tomcat clustering...
Thanks for your answers.
Regards,
Antoine
-----Message d'origine-----
De : Peter Rossbach [mailto:pr@objektpark.de]
Envoyé : mardi 14 novembre 2006 09:31
À : Tomcat Users List
Objet : Re: session replication/tomcat 5.5
Am 13.11.2006 um 20:27 schrieb David O'Dell:
> Is anyone using session replication in production?
>
Yes, at really big sites :-)
> Is there an alternative to using multicasting?
>
No, but you can implement you own membership service.
> 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?
>
Yes, but split your cluster into different domains. Use Apache/mod_jk
>= 1.2.19 with the
domain attribute. The mod_jk loadbalancer can then route to the right
backup.
regards
Peter
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Ce message et toutes les pièces jointes (ci-après le « message ») sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. Si vous recevez ce message par erreur, merci de le détruire sans en conserver de copie et d'en avertir immédiatement l'expéditeur. Internet ne permettant pas de garantir l'intégrité de ce message, la Caisse des Dépôts et Consignations décline toute responsabilité au titre de ce message s'il a été modifié, altéré, déformé ou falsifié.
This email message and any attachments ("the email") are confidential and intended only for the recipient(s) indicated. If you are not an intented recipient, please be advised that any use, dissemination, forwarding or copying of this email whatsoever is prohibited without Caisse des Depots et Consignations's prior written consent. If you have received this email in error, please delete it without saving a copy and notify the sender immediately. Internet emails are not necessarily secured, and Caisse des Depots et Consignations declines responsibility for any changes that may have been made to this email after it was sent.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: session replication/tomcat 5.5
Posted by Peter Rossbach <pr...@objektpark.de>.
Am 13.11.2006 um 20:27 schrieb David O'Dell:
> Is anyone using session replication in production?
>
Yes, at really big sites :-)
> Is there an alternative to using multicasting?
>
No, but you can implement you own membership service.
> 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?
>
Yes, but split your cluster into different domains. Use Apache/mod_jk
>= 1.2.19 with the
domain attribute. The mod_jk loadbalancer can then route to the right
backup.
regards
Peter
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: session replication/tomcat 5.5
Posted by Dan Baumann <da...@gmx.de>.
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:timlucia@yahoo.com]
> 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:dodell@corp.meez.com]
> 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:dodell@corp.meez.com]
>> 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: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: session replication/tomcat 5.5
Posted by Tim Lucia <ti...@yahoo.com>.
PERFECT! Thanks to you and Dan Baumann...
-----Original Message-----
From: Rainer Jung [mailto:rainer.jung@kippdata.de]
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:timlucia@yahoo.com]
> 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:dodell@corp.meez.com]
> 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:dodell@corp.meez.com]
>> 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: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: session replication/tomcat 5.5
Posted by Rainer Jung <ra...@kippdata.de>.
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:timlucia@yahoo.com]
> 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:dodell@corp.meez.com]
> 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:dodell@corp.meez.com]
>> 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: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: session replication/tomcat 5.5
Posted by Tim Lucia <ti...@yahoo.com>.
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:timlucia@yahoo.com]
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:dodell@corp.meez.com]
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:dodell@corp.meez.com]
> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: session replication/tomcat 5.5
Posted by Tim Lucia <ti...@yahoo.com>.
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:dodell@corp.meez.com]
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:dodell@corp.meez.com]
> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: session replication/tomcat 5.5
Posted by David O'Dell <do...@corp.meez.com>.
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:dodell@corp.meez.com]
> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: session replication/tomcat 5.5
Posted by Tim Lucia <ti...@yahoo.com>.
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:dodell@corp.meez.com]
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org