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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
