On Tue, Mar 16, 2010 at 5:31 PM, Adam Lee <a...@fotolog.biz> wrote:
> Yes. As described in my previous post, all necessary state
> information is contained in the request-- if you want to pass state
> information to the next request, it's easiest to encode it in a sort
> of cryptographically secure "token." I find it easiest to think of it
> as almost like an FSM where the cookies, token and query parameters
> are inputs. Obviously it's not purely deterministic or referentially
> transparent, since things do end up getting written to the datastores
> and such, but it is a somewhat useful abstraction.
Ok, thanx for sharing your experience. Do you have some app online
implemented like this I can have a look at?
Cheers,
Martin
>
> On Tue, Mar 16, 2010 at 4:02 AM, Martin Grotzke
> <martin.grot...@googlemail.com> wrote:
>> On Mon, Mar 15, 2010 at 6:57 PM, Adam Lee <a...@fotolog.biz> wrote:
>>>
>>> On Sun, Mar 14, 2010 at 2:59 PM, Les Mikesell <lesmikes...@gmail.com>
>>> wrote:
>>>>
>>>> Adam Lee wrote:
>>>>>
>>>>> well, it depends on what you mean by scalability... i'm personally of
>>>>> the opinion that traditional sessions should be avoided if you want to
>>>>> truly scale.
>>>>
>>>> And yet, everyone wants dynamic pages custom-generated to the user's
>>>> preferences. So how do you reconcile that? You can help things a bit by
>>>> splitting pages into iframe/image components that do/don't need sessions,
>>>> and you can make the client do more of the work by sending back values in
>>>> cookies instead of just the session key, but I'm not sure how far you can
>>>> go.
>>>
>>> Well, I guess it depends on your definition of "session." Obviously, you
>>> need to account for user preferences and such, but I don't consider those
>>> "session" data since they are consistent across any session that the user
>>> instantiates.
>>> Probably the easiest way to build a "stateless"/shared-nothing web
>>> application, and what we've done to scale, is to store user authentication
>>> data and the like in an encrypted cookie. Any other session-like data (geo
>>> location from IP lookup, language preference, etc) can be set in separate
>>> cookies. Since cookies are sent with every request, it is possible to
>>> easily authenticate that the user is who they say they are and discern the
>>> necessary data to build their page using only these cookies and you don't
>>> need to look anything up in any sort of centralized session cache.
>>> Data that is needed to authenticate a request or to display a message on a
>>> subsequent page view (things that would be stored in the Flash in Rails,
>>> from how I understand that to work) can be encoded into a cryptographically
>>> secure "token" that is passed to the following request.
>>> User preferences and settings, on the other hand, are not really session
>>> data, as I said above. I've already described somewhat how we have this
>>> data stored in a few previous posts on this thread, but I guess I'll do a
>>> basic overview for the sake of completeness...
>>> Our central datastore for users is still (unfortunately) a database
>>> (mysql), but this is essentially only used for writes. All user data is
>>> also written to TokyoTyrant, which is our primary persistent datastore for
>>> reads, and is replicated exactly in memcached.
>>> Since not all user data is needed for every page view, we've broken the
>>> user data into what we call "user chunks," which roughly correspond to what
>>> would be DB tables or separate objects in a traditional ORM. We built a
>>> service that will get you the data you want for a specific user or set of
>>> users by taking name(s) and a bitmask for what chunks you want. So, for
>>> example, if I wanted to load the basic user data, active photo and profile
>>> data for the user "admin," I'd just have to do something like this:
>>> RoUserCache.get("admin", USER | ACTIVE_PHOTO | PROFILE);
>>> The beauty of this is that the cache is smart-- it batches all of the
>>> requests from a thread into bulk gets, it does as much as possible
>>> asynchronously and it tries to get data from memcached first and, if it's
>>> not there, then gets it from TokyoTyrant. TokyoTyrant and memcached are both
>>> great at doing bulk gets, so this is pretty fast and, since they both speak
>>> the same protocol (memcached), it wasn't terribly difficult to build. Doing
>>> it asynchronously means that most of the latency is absorbed, too, since we
>>> try to do these loads as early on in the page building process as possible,
>>> so it tends to be there by the time the page tries to use it.
>>> Anyway, I've strayed a bit from the topic at hand, but I guess I felt I
>>> should elaborate on what I meant...
>>
>> So you're one of the lucky guys that don't have to support users with
>> cookies disabled?
>> According to what you describe is seems you're not using sticky sessions. Do
>> you handle concurrency issues in any way, to make sure that concurrent
>> requests (e.g. tabbed browsing, AJAX) hitting different servers see the same
>> data?
>> Cheers,
>> Martin
>>
>>>
>>> --
>>> awl
>>
>>
>>
>> --
>> Martin Grotzke
>> http://www.javakaffee.de/blog/
>>
>
>
>
> --
> awl
>
--
Martin Grotzke
http://www.javakaffee.de/blog/
To unsubscribe from this group, send email to
memcached+unsubscribegooglegroups.com or reply to this email with the words
"REMOVE ME" as the subject.
