[UPHPU] load balanced file-based sessions
joseph at randomnetworks.com
Tue May 6 12:12:47 MDT 2008
On May 6, 2008, at 11:41 AM, Sean wrote:
>> I'm not suggesting that either ( I must have done bad job
>> explaining my position ). What I'm advocating for high traffic
>> sites is sticking with the shared nothing approach that HTTP
>> provides as much as possible. There are of course some minimal
>> things that need to be done via cookies, like user validation, but
>> that list should be very, very short and the exception, not the rule.
>> Keeping session state in cookies isn't really much of option for
>> variety of reasons (security, additional bandwidth, size
>> limitations, etc). Doing session state on the server side is fine
>> for smaller sites (will never grow beyond 1 web server), but is a
>> pain for sites that have to scale out to handle lots of traffic/
>> page views. That basic reason that it is a pain is keeping all of
>> that data in sync across all of the potential web servers and data
>> centers that your user might hit to access your site. In many
>> respects keeping user state in sync is much more important than
>> keeping your application data in sync (replication lag and such),
>> because of the potential security implications.
>> Avoiding session state for your high traffic site will make it
>> easier to scale and reduce the number of things that you have to
>> keep up and going and in (mostly) in sync. For high traffic sites
>> they'll be plenty of other things to keep you busy :-)
> You know that some major websites like Amazon use session, right?
> How do you propose to keep track of the current user without
I generally try not to quote myself, but this seems like a good time
to do so (see first paragraph in the email of mine you responded to):
What I'm advocating for high traffic sites is sticking with the
shared nothing approach that HTTP provides as much as possible.
There are of course some minimal things that need to be done via
cookies, like user validation, but that list should be very, very
short and the exception, not the rule.
be used sparingly.
I think part of the problem we are running into is confusion of
terms. Server side session store refers to the general concept of
setting a unique ID via a cookie and then tracking the current
session state for that unique ID via some data store on the server
(files, database, memcache, etc). This is what's happening when you
use PHP's session functions (http://us2.php.net/manual/en/
book.session.php). This makes many things a lot easier, but
generally breaks the shared nothing concept of HTTP.
Another technique is to set a cookie an encrypted cookie that
uniquely identifies a specific user. Then on each request you check
that the cookie and user are valid and lookup what ever details are
needed for the specific request. The result of this is that there is
some additional work managing the user info, but you don't have to
worry about keeping all of the session state data in sync and this
method is more in keeping with the shared nothing approach of HTTP.
In our case using the shared nothing approach is totally worth it,
having to keep session state synced across 3 different data centers
and hundreds of servers wouldn't be very much fun :-)
joseph at randomnetworks.com
More information about the UPHPU