Loading ...
close

Would you like to discuss your environment with a knowledgable engineer?

Preferred communication *

Thank you. We will be in touch with you shortly

Configuring Client-to-Origin Server Persistence.

Posted by on October 25th, 2010

Some sites have a need to “pin” clients to specific origin servers. For example, a client A might need to be pinned to origin server 1, client B to origin server 2, while client C might be served by any available origin server.

The reasons for such configuration may vary but a common theme to them is a notion of “session” and “session state”. Let’s imagine an E-Commerce site where a visitor is in process of populating a shopping basket with assorted items. If such a site is served via a number of origin servers, then there must be a provision that all of the origin servers that such client might access during a shopping visit, know of all the items that are placed into the shopping basket. Otherwise, as different origin servers are accessed, items will seem to disappear and reappear at random, a most frustrating situation for a shopper, as you can imagine.

Let’s agree on some tech speak. We state that such shopper creates a session state as soon as first item is placed into the basket. The session state includes basket items. And as long as shopper in our example is free to move between different origin servers, the session state must be somehow replicated between all of them so it is available on any of them. Now, doing it reliably and quickly is no easy task – with significant implications both on site’s infrastructure and site’s code.

Fortunately, there’s a much easier way to address this dilemma – we simply make sure that after a certain activity takes place, the user is pinned to an origin server. Another common name used for this technique is origin server persistence. When used, a given visitor always connects to a single origin server. Other visitors connect to other origin servers, so in the end the load is still distributed across all of the origin servers.

What do we choose as an event that triggers pinning may vary, but most of these do have a thing in common – the triggering request/response is almost always non-cacheable.

Leave Comment

US (208) 948-9786‬   EU ‭+31 621302365