Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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