On Sun, Sep 21, 2008 at 6:48 PM, Jochem Maas <jochem@xxxxxxxxxxxxx> wrote: > Philip Thompson schreef: >> >> Hi all. >> >> Let me start out by saying, I have STFW and read through the list >> archives. Now that that's out of the way. >> >> To speed up our application, we want to implement using SESSIONs in some >> locations. Beforehand, on every page, we would run approximately 30-40 >> queries just to get the page setup - user information and other stuff. Now >> while we can't take away all of the setup queries, we would like to reduce >> the startup number. >> >> Ok, so I've implemented this in several places where information basically >> does not change from page to page. Jumping to the point/question... when >> does it become more inefficient to store lots of information in SESSION >> variables than to run several more queries? Note, we are actually storing >> sessions in the database - so a read/write is required on each page load - >> it's not file sessions. >> >> Now I know this can depend on the complexity of the queries and how much >> data is actually stored inside the sessions... but initial thoughts? To give >> you a number, the strlen of the _SESSION array is 325463 - which is >> equivalent to the number of bytes (I think). > > not exactly - depends on how you measure it, also the serialized form of the > session data is longer still because it contains data type descriptions et > al. > > are you running on a linux box? if so try using session files again and > sticking your session data in /dev/shm/some-dir which effectively means your > sticking the files in RAM ... generally much faster than using a DB or the > FS, > on the other hand this is rather volatile (if the box goes down you lose all > the > data ... but then you have other problems probably, you can get round it > by regularly backing up the contents of /dev/shm/some-dir and restoring the > backup > if/when the machine reboots ... the backup can occur out of process, so > your page performance isn't directly effected, you'd still have to think > about > file locking etc) I use this trick quite often, generally without bothering > to backup the session data (I figure if the site goes down completely then > losing session data is the least of my worries ... and a user won't be > all that surprised to find his login status wiped when the site comes back > up ... although he/she might be a little miffed) > >> >> Thanks, >> ~Philip >> > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Wouldn't you (probably) loose sessions in /tmp if the box crashed also? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
