Sticky vs Non Sticky

One of the most important configuration property of the manager is the sticky variable. This property informs the manager if the balancing configuration is sticky (all request from the same client are redirected to the same server) or non-sticky (the balancer sends the request to any server or, at least, two of them). If the architecture manages sticky sessions the couchbase-manager can take advantage of that feature.

In general the Sticky vs Non-Sticky question has some pros and cons:

Sticky

The implementation of the sticky configuration is well commented in this post. Features of this configuration:

• A sticky configuration is simpler and, therefore, faster. In this kind of configuration the manager can assume it is the only one managing and modifying the session and that saves some access to the external repository.
• A sticky configuration makes each application server to only store the sessions that are being re-directed to it. In a normal (no failure) situation a server knows nothing about the sessions in the other containers.
• The sticky configuration saves operations against the repository but it needs to maintain the whole session in memory (because the session is not re-read, the saved attributes should be mantained).
• Normally a sticky configuration produces a more unfair balancing of the requests (but fair enough in my humble opinion).
• Cos the session is cached in the local server, an error in the repository could be detected not as fast as in non-sticky situations.

Non Sticky

This configuration was the original idea for the manager and its implementation was documented here. Its main features are the following:

• The non-sticky configuration produces the most fair balancing.
• All the sessions are managed by all the servers that receives request for that session. But the session is cleared, ie, the attributes of the session are only in the local session while the request lives in the container, once the session is unlocked the attributes are cleared.
• Error conditions in the repo are immediately detected (session is always read and written, no caching is done).
• This configuration needs the couchbase to lock/unlock sessions and that operations represents some performance degradation (there are more operations performed and more complex).
• Locking can produce some weird behaviors if the application sends several requests at the same time or in parallel (usually applications that uses web-services a lot). In normal applications (one request, one page) this effect is meaningless.

---

In summary I recommend to use the sticky ( non-default, take care with this) configuration. At this moment I think is faster and more reliable.