Re: [REBOL] Re: Rebol/command, fastCGI, session id, frames, etc....
From: allenk:powerup:au at: 24-Jun-2001 13:50
----- Original Message -----
From: "Graham Chiu" <[gchiu--compkarori--co--nz]>
To: <[rebol-list--rebol--com]>
Sent: Sunday, June 24, 2001 9:56 AM
Subject: [REBOL] Re: Rebol/command, fastCGI, session id, frames, etc....
> On Sat, 23 Jun 2001 22:21:27 +0200
> "Petr Krenzelok" <[petr--krenzelok--trz--cz]> wrote:
> >
> > thanks a lot - I am just discussing other possibilities
> > with Allen in RIM
> > conference. Maybe another option is to completly bypass
> > sessions at all?
> > Allen thinks sessions don't scale too well.
>
> Why not?
>
> >
> > So what about using some form, hiddent field, post
> > method, and some kind of
> > encrypted string (containing info about time, for
> > detection of timeout),
> > which would be sent to page each time?
> >
>
> These are just ways of implementing session handling.
>
> If I had to do this, I would probably use cookies. And of
> course advise the end user that cookies need to be enabled.
> Hidden fields mean that every page has to be posted, and
> mangling the URL is ugly.
>
> So, something like this
>
> 1. browser request - no cookie? create new session id and
> send cookie which holds the session id
> 2. store session id in session table with time stamp
Graham,
This is the point at which session handling does not scale well. The moment
you track anything on the server, you are reducing the scalability. Also
with a web app in largescale webfarm with load balancing there is no
guarantee that the same server will handle the next request from the client.
(Though there are some tools that try to make this happen with varying
success)
In ASP, sessions become even more dangerous to this scalability as it makes
incedibly easy and seductive to use variables within a session context. So
every current session could use 1k or so and under heavy load your windows
server uses up its memory in sessions and spends it time disk swapping the
virtually memory. And worse, a whole bunch of those are sessions from people
who aren't there anymore and probably left 5 minutes ago.
In designing session usage in REBOL it would be nice to avoid that,
particularly in fast-cgi.
These are extreme cases, but I was trying to explain that if Petr can design
a system that is largely stateless, just enough to recognise the validity of
the user at the current time the request comes through, then his system will
scale better. Storing & tracking session state on the server does not scale
well, was all I was trying to say.
Cheers,
Allen K