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
[EMAIL PROTECTED]
http://joseph.randomnetworks.com/
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
