On Sep 19, 2008, at 11:10 AM, Eric Butera wrote:
On Fri, Sep 19, 2008 at 12:05 PM, Philip Thompson
<philthathril@xxxxxxxxx> wrote:
On Sep 19, 2008, at 10:54 AM, Wolf wrote:
---- Philip Thompson <philthathril@xxxxxxxxx> 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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
