Tomcat clustering/loadbalancing performance in production environment-Collection of common programming errors

• The drawback of sticky-sessions is that with a growing number of nodes (in the range of > 100, > 1000) the probability of failure increases. Then it’s preferable that it doesn’t matter which node serves the request. However there are issues that have to be solved with sticky sessions differently, which of course depends on the requirements and the application (examples are session synchronization, preventing double submits, redirect-after-post etc.). Most often my own preference is to use sticky sessions as long there are a limited number of nodes. For 4 nodes personally I’d recommend using sticky sessions.
• We have used sticky-sessions and session replication via memcached-session-manager in production environments. memcached-session-manager was developed during the relaunch of tchibo.de (one of the biggest ecommerce-sites in germance), with the goal of both performance and scalability.
• We chose sticky-sessions for this application
  • because of better performance
  • the customer-requirements opted for sticky-sessions
  • the used web-framework was better suited for sticky-sessions.

Its not this or that, if the application requires both then you have to use both. Clustering is to manage the load while session affinity is used to protect the data of the user if a failure happens on a node.

Cite this example, if you are working a node and there is no sticky session and your node crashes, clustering will make sure you get to see the page but your current working session will be lost.