Page 2 of 2

Posted: Fri Jan 10, 2003 12:09 pm
by Elmseeker
BDKR wrote:
Elmseeker wrote: That's funny, I use PHP sessions due to my feelings that if my site ever grows to the point of needing a server farm I can pay someone else to make sure the session handling makes the leap since the site will be making $ at that point...rofl
Yeah, and when they foul it up, how many dollars will you loose?

Doh!

Cheers,
BDKR
Ok, that's a good point, but I wouldn't even know where to begin writing my own functions to do all of this...I haven't been at PHP that long yet and I am still mostly cludging my way through hehe...

Posted: Fri Jan 10, 2003 12:23 pm
by BDKR
Ok, that's a good point, but I wouldn't even know where to begin writing my own functions to do all of this...I haven't been at PHP that long yet and I am still mostly cludging my way through hehe...
Don't worry about it. You'll get there! I was just being silly.

In short, the concern with session handling on a large scale is where does each server in a server farm or cluster store it's session information? If it's on the local drive then 1) it's slow, and 2) what happens if the session isn't correctly routed back to that server? Then the session information is lost.

However, if all the servers in the cluster (I prefer the term cluster to server farm) read from the same db, then it doesn't matter what web server a person is routed too as it will allways be able to retrieve the session information.

This is also something I have to keep in mind here at work as I was responsible for desinging our back end, and now running it. We are using a cluster based on Turbo Cluster 6 from Turbo Linux. Our web based adminstration is a combination of VB (written by my boss) and PHP (written by me). All of our session info is db based, written to the primary, and read from one of the replicated slaves. Lot's of fun being a system admin. 8O

Cheers,
BDKR

Posted: Fri Jan 10, 2003 5:07 pm
by volka
If you're using the default session handler avoiding any side-effects it will be easy to replace it when you have need for it. So, temper with sessions only if absolutly necessary to keep the chance of a painless upgrade..... (in case you do not already have your own handler, of course ;) )

Sessions & global.asa

Posted: Fri Jan 10, 2003 8:29 pm
by fractalvibes
No harm done!

No doubt, Sessions are a topic of much debate both in the ASP and the PHP
communities. Session variables are very handy, yet best used judiciously.
If I had a penny for every article I have read that stated that session variables are evil.....moderation perhaps is the keyword here....

There are pros and cons with any method of persisting "session-type" data in a supposedly "stateless" environment. Using a database is one method,
but that is an overhead also - access time to the DB and additional network traffic.

I am thinking that there are some strategies emerging for the server farms where the actual session state variables are stored all on one server, whereas the pages themselves may be served from 1.....N servers
in a farm.

Just don't like using a querystring, as the user can really muck it up!

Posted: Sat Jan 11, 2003 7:36 am
by BDKR
I am thinking that there are some strategies emerging for the server farms where the actual session state variables are stored all on one server,...
Of course, I hope that server has at least one backup or the system has a single point of failure. Additionally, keeping those two servers in sync means network traffic, unless you do something like connect them via a serial or usb port.

Another thing that can be done is put them on thier own network. This is something that I'm ramping up to do here with our databases. The db's will exist on their own network to reduce network congestion. The web and transaction servers then will communicate with the outside world (via a firewall) on one network, and with the dbs on a seperate network. Replication and other traffic between the dbs can happen with out creating congestion on the network for incomming transactions.

This same approach could be taken with two servers dedicated to session persistence. Store the session information in system memory and replicate it to the back up as well. If the primary fails, the secondary kicks in when it senses a faiilure of the primary.

Yeah, I think this approach could be good. :D Do you remeber where you heard or read this? Of course, there are those that believe it may not be worth it. Oh well....

Another take on the db session handling is the suggestion I heard somewhere of just making the table that stores session information a heap table. It would be blazing fast as it isn't disk bound, but you had prolly better be careful how much memory you allow it to use.

Sorry for the rant.
:cry:

Cheers,
BDKR

Posted: Sat Jan 11, 2003 10:26 am
by Elmseeker
BDKR wrote:Another take on the db session handling is the suggestion I heard somewhere of just making the table that stores session information a heap table. It would be blazing fast as it isn't disk bound, but you had prolly better be careful how much memory you allow it to use.
Yeah, I can see problems with this already, for small sites this would be ok but if you have 1000+ users hitting your page your gonna run out of memory very quickly and watch your sessions go *poof*...