Re: Why use sessions and not DB?

on 8/29/00 3:34 PM, Michael Kimsal at michael@tapinternet.com wrote: > Agreed. Storing session info into database will let you scale > to multiple front end machines much easier. If that's even a > remote possibility, you'd want to store info in a db. > > We've been gzcompressing large amounts of session data > (large shopping carts) before writing to the database. Now instead of > continually sending receiving 1-2k chunks across the wire between > server and db, we send 300-400 bytes each time, which is helping > speed things up. I am suprised that you are having to compress session data before sending it to the db server... Seems like that would put more of a load on the machines than you would gain. What sort of setup are you running (like number of web servers, db servers, how they are connected, etc.)? We send all the session data from the web servers to the db server in uncompressed format and it has only a minimum effect on performance (if at all). Mind you we have a decent machines performing these actions. Also we are not load balancing--really just load shaping with round robin DNS to a couple web servers that are using Linux HA/heartbeat. So users aren't getting handed off from web server to web server so much--but if they were it would work without missing a beat. -k