NYCPHP Meetup

[Marc Antony Vose]

Hello:

I guess it's all about balance between speed and disk space.  I was 
thinking of storing some limited data in sessions just because I 
figured it was less total overhead than hitting the database for a 
response.

Perhaps, though, it's not giving much of an advantage, and I should 
just confine session storage to things like unique IDs, and then do 
lookups based on that.

I guess my thinking was that involving another program in this was 
creates a bunch of overhead.  I guess touching MySQL isn't as 
intensive as I imagine?

Marc




>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.
>>
>
>_______________________________________________
>New York PHP Talk Mailing List
>AMP Technology
>Supporting Apache, MySQL and PHP
>http://lists.nyphp.org/mailman/listinfo/talk
>http://www.nyphp.org