[UPHPU] load balanced file-based sessions

Joseph Scott 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  
> cookies???


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.
--------------

I'm not suggesting that you don't use cookies, only that they should  
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 Scott
joseph at randomnetworks.com
http://joseph.randomnetworks.com/






More information about the UPHPU mailing list