Re: Why use sessions and not DB?

I'm timing things to the millisecond, and it doesn't seem to. The particular situation in this case is that we're using the freetds system to connect to sql7, and it seems to slowdown with queries over 500 bytes. This is a big time savings in this case - a savings of ~40-50 ms per page. Not a lot, maybe, but when the whole page is only taking 120-130 ms, that's a big %. The gzcompress aspect, haven't noticed any slowdown or speed up in small testing. This *could* present a larger CPU load on the processor, but I don't think it's running long enough to have that kind of impact. The times I'm seeing to gzcompress and uncompress that amount of data are <5 ms. The 50ms v 5ms is, as I said, a large savings in this situation. Jason Murray 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. > > Doesn't that increase the load on the webserver, though? > > Jason -- ========================== Michael Kimsal http://www.tapinternet.com 734-480-9961