tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emilio Recio <ere...@technisys.net>
Subject Re: Sticky session and ModJK Load Balancer
Date Tue, 07 Jul 2009 13:11:28 GMT
Rainer Jung wrote:
> On 06.07.2009 20:27, Emilio Recio wrote:
>   
>> Mark Thomas wrote:
>>     
>>> Emilio Recio wrote:
>>>  
>>>       
>>>> Hi,
>>>> i have installed Apache 2.2 and two Tomcat 6 whit load balancing in
>>>> cluster mode using "mod_jk" module and setting sticky session in TRUE,
>>>> and memory replication. I was testing my project and work perfect.
>>>> We have a dilemma using sticky session or not using it, with my team
>>>> work.
>>>> Setting sticky-session in TRUE, it works fine, even when one tomcat
>>>> fails-over. When set to FALSE i can see that the session have some data
>>>> loss, and the project start to fail.
>>>> I was reading the book Professional Apache Tomcat 6, goggle searches and
>>>> all kind of information in the net. The recommendation is: use
>>>> sticky-session in TRUE with memory replication.
>>>> Nobody mention concrete arguments, and need that to make a report to the
>>>> system administrator, to make him understand why we need to use
>>>> sticky-session in TRUE.
>>>>     
>>>>         
>>> I would have thought the occasional data loss you see is argument
>>> enough. What more were you looking for?
>>>
>>> Mark
>>>   
>>>       
>> Hi Mark,
>> We are developing an e-commerce app. The application store  in session a
>> lot of information like user data, user history data, etc.
>> The scenario is: 3 PC's, one with Apache 2.2, and the others have Tomcat
>> 6. Apache has mod_jk to make load balancing, and the Tomcat 6 have
>> configured in memory session replication, to support fail-over.
>> STICKY SESSION FALSE:
>>    Some times: Tomcat1 after the login, has all the user info charged in
>> session, when load balancer try to use the Tomcat2 some info is saved
>> but other info is missing.
>> We need to know good arguments to justify to the client, why we should
>> use sticky session in true to avoid this missing data issue. The client
>> doesn't want to use sticky session in TRUE, they arguments are: "We
>> loose performance in transactions and loose of loadbalancing (using
>> sticky session in TRUE). Using sticky session in FALSE the Tomcat more
>> idle attend the request that incoming and gain performance. One example:
>> You have 4 users, two in tomcat1 and the other two in tomcat2. If users
>> in tomcat2 logout, this stay idle when the other is attending the other
>> two users. So, you "loose load balancing"."
>>
>> They arguments are partial true, using stick-session in TRUE , you have
>> one tomcat attending a client session during its life cycle; even if
>> this users are idle or has very active session. Its stable and fail-over
>> tolerant. Of course you "loose" performance.
>> So we need good arguments to explain why we need use, sticky session in
>> true.
>> My regards,
>>    Emilio  Recio
>>     
>
> Usually you only use a custering solution like Tomcat session
> replication if you really need high availability. Clustering adds some
> complexity to the system, so in order to justify that you need a reason,
> which should be, that your user sessions are expensive, so you do not
> want to loose them under any circumstances.
>
> If so, your primary goal is stability not performance. Adding any high
> availability solution also reduces performance (but maybe only a bit).
>
> Why use sticky sessions when doing session replication? Because without
> sticky sessions, each request depends on the fact, that the replication
> of the previous request to the same session was completed successfully.
> So the correctness of your application depends the whole time on the
> completeness of the session replication (because requests will switch
> form node to node a lot without stickyness). Whenever something goes
> wrong with respect to session replication, a user will fail. This seems
> to be, what you actually oberve when working without stickyness. Your
> application is *not* replicating completely. Stiky off is a good setting
> for testing, but not for production.
>
> With stickyness, under normal operation you don't rely on the fact, that
> replication works. Only in case a node goes bad, the sessions fail over
> and then you need the correctness of the previous replications. Usually
> this only happens unplanned like maybe once a month or even fewer times.
>
> It is also much easier to track what's going on and maybe wrong, when
> you have stickyness, because then all requests for one session can be
> usually found in the log files of only one node. You don't have to
> consolidate them from multiple nodes.
>
> Concerning performance: If you only plan 2 Tomcat nodes, then you have
> to size the in order for one node to be able to carry the full load.
> Otherwise when a node crashes, although you have session replication, it
> could happen that the remaining node is not able to cope with the load.
> So an uneven load distribution between the two nodes is not a real
> problem, each one should be able to handle all requests.
>
> Under high session load (like e.g. more than 1.000 users logged in)
> usually the request load distributes good enough to not produce a very
> uneven load.
>
> In short: stability is more important then performance in
> high-availability situations and a two node cluster should be designed
> such that a single node can carry all the load.
>
> Concerning only one Apache node: that doesn't look like high-availability.
>
> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>   
Hi, Mark. Thank you very much!!! Your replay was very useful. But i 
still have some doubts.
When we use clustering, we gain in  availability. Otherwise you gain in 
performance.
The doubt is: Which is the purpose of the STICKY SESSION in a clustering 
system. The only thing we know is the fact that stickiness  only  attach 
a  client session to only one tomcat over the life cycle.
Thanks very much.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message