How many web servers does StackOverflow/ServerFault have?
If the answer is 'more than one', then is does it achieve Session Stickiness while DNS polling?
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
Large websites may be "load balanced" across multiple machines. In many load balanced setups, a user may hit any of the backend machines during a session. Because of this, several methods exist to allow many machines to share user sessions.
The method chosen will depend on the style of load balancing employed, as well as the availability/capacity of backend storage:
Session information stored in cookies only: Session information (not just a session identifier) is stored in a user's cookie. For example, the user's cookie might contain the contents of their shopping basket. To prevent users from tampering with the session data, an HMAC may be provided along with the cookie. This method is probably least suitable for most applications:
Load balancer always directs the user to the same machine: Many load balancers may set their session cookie, indicating which backend machine a user is making requests from, and direct them to that machine in the future. Because the user is always directed to the same machine, session sharing between multiple machines is not required. This may be good in some situations:
Shared backend database or key/value store: Session information is stored in a backend database, which all of the web servers have access to query and update. The user's browser stores a cookie containing an identifier (such as the session ID), pointing to the session information. This is probably the cleanest method of the three:
Overall, most dynamic web applications perform several database queries or key/value store requests, so the database or key/value store is the logical storage location of session data.
If your question is how to maintain sessions across multiple front-end web servers, then the answer is usually to use a centralized database. Instead of relying on the web server instances to track session files on the local file systems, you'd write the session ids and data into a central DB, and all the web servers would retrieve the data from there instead.
Using nemcached seems to be a good solution not as mentionned by @David Pashley
It means having a remote memcached instance shared by all servers and using the memcache PECL extension that provides its own session handler.
It only requires to change two parameters in the php configuration!
Here is a good tutorial http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/
IIRC, in DotNetRocks #440 they said one server period. Don't know if that is still the case.
Edit: Actually it was Hanselminutes #134. Sorry.
You can set a cookie.
You can calculate a hash of the remote IP (at its simplest, odd numbered remote hosts go to server A, even numbered hosts go to server B).
Looks like you can also do it via some values that stay with the source system if you're using an ssl tunnel.
Typically each of the above mechanisms requires a "reverse proxy" server or a load balancer of some sort. That load balancer accept the traffic and then direct it to whichever server initially had the session, based on one of the above criteria.
I'm not sure, though, what you mean by "DNS polling"
a)You can store session information in user cookie . See stateless hardened cookies, which stores none data at server side, but preserves session state http://www.cl.cam.ac.uk/~sjm217/papers/protocols08cookies.pdf . b)You can change session backend storage to database or memcached. To eliminate single point of failure, you can set database replication or multiple memcached nodes. Note, that memcached is recommended in such setups where losing user state in session is not big error and does not make him very unhappy. For cases where preserving state is vital, use databases. Both PHP, Django and Rails allows developer to write custom session backend.