Re: SESSIONS vs. MySQL

On Sep 19, 2008, at 11:10 AM, Eric Butera wrote:

On Fri, Sep 19, 2008 at 12:05 PM, Philip Thompson <philthathril@gmail.com> wrote:

On Sep 19, 2008, at 10:54 AM, Wolf wrote:

---- Philip Thompson <philthathril@gmail.com> wrote:

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). Thanks, ~Philip

We carry a sh!tload of information in our session, without slowing anything down. In fact, it takes the servers longer to run a full query then to use the session information. But we use the $_SESSION information. Our first query sets everything up in the session and we take on from there, and use stuff from the $_SESSION to actually make the rest of the pages faster. 30-40 queries just to set up a page? That's an abomination that shouldn't see the light of day. Anything slower then 2 seconds without any interaction back to the users will be short-lived.... Wolf

Even with 30-40 queries upon setup, it's very fast - less than 1 second... for now. We starting having speed issues in other locations. Hence, we decided to address every potential reason and possible slowndown in the future. Thanks for your input, Wolf. Any others storing sh!tloads in their SESSION array? =D ~Philip -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

I used to store objects in the session. I figured I used it a lot so why not. Then my app got really nasty and slow. Now I only store enough of the state to render the page. So instead of storing a complete user object I store the auth details to load a user object if needed. Only very simple parts of the state get loaded into my apps now. Now things are quite snappy again. Why do you have so many queries? Perhaps we can attack this issue from another angle.

I've narrowed it down to 10 initial queries... 1. Grab system config data (that's used in lots of places) 2. Grab session data (for SESSION array) 3. Grab page id 4. Grab user privs 5. Grab user session (for application) 6. Begin transaction 7. Lock user session row 8. Update user session 9. Commit transaction 10. Add page tracking (an insert-only table that keeps track of pages you visit) Note that these are the 10 queries that happen after the initial SESSION load. I supposed I could reduce this by 1 or 2 queries - I could store the page id/information in the session. Now with that said, the queries are negligible (in elapsed time) and required. However, I'm always open up to suggestions/improvements.... =D Thanks, ~Phil