NYCPHP Meetup

[Dan Cech]

I've had pretty good success in the past using database-backed sessions 
with gzip compression.

I did it by writing my own session handlers which take the $_SESSION 
array, serialize and (optionally) gzip it, then store the result in a 
table.  A big advantage of this method is that you can store other 
useful data in the session like the activity time, user_id, etc for 
generating 'who's online' type reports, session timeouts, or whatever 
else might come in handy.

If you don't want to get involved with the inner workings of the session 
mechanism I would recommend looking at the session functions included 
with ADOdb.

Breaking session data across several different rows could work, however 
if data is getting that large I would probably think about using 
something like PEAR::Cache_Lite rather than extending the session mechanism.

Dan

csnyder wrote:
> On 4/21/05, Daniel Krook <krook at us.ibm.com> wrote:
> 
>> I saw some example a few months back about
>>about the space required by an application that had 20k of session data on
>>the file system x number of users x 20 minute time out which brought the
>>space needed to 2GB for a modest amount of users.
> 
> 
> So the answer is, store as much as you need to, and no more.
> 
> But I'm still curious about the performance implications of
> serialize() / unserialize() -- should large sessions be broken up into
> many rows of a table, so that updates only touch one row and not the
> entire structure?
> 
> It seems like if you had A LOT of data being stored in the session,
> you would be better off putting it into a db and only reading/writing
> the rows you need for a given request. Then the only thing stored in
> $_SESSION would be the key(s) to those rows...
> 
> The disk size requirements don't go away, but processing might be more
> efficient.
>