On 19 Sep 2008, at 21:44, Philip Thompson wrote:
On Sep 19, 2008, at 1:12 PM, Stut wrote:
On 19 Sep 2008, at 18:47, Philip Thompson wrote:
4. Grab user privs
IMHO you should only grab these when you need them.
I will need these on most pages anyway. Because of the architecture,
the security class (which uses these a lot) is a separate part.
Fair enough, but I would suggest this is an ideal candidate for being
kept in the session.
5. Grab user session (for application)
Again, why isn't this already in $_SESSION for every page request
expect the first per visit?
This "user session" deals with merely keeping up with the time - how
long has it been since this user accessed the site? Keep logged in?
Logged in elsewhere? This uses the db and cookies. Note, this was
designed into the app from the beginning... using the _SESSION var
is new to the app as of this week. Yes, we can probably move this
functionality into the new _SESSION stuff....
Sounds like a lot of work for little benefit, but it sounds like it
might be hard to remove so I'd probably live with it for a while too.
6. Begin transaction
7. Lock user session row
8. Update user session
9. Commit transaction
If all you're doing is issuing an update command there is no need
to do so in a transaction and definitely no need to lock the row.
An update is atomic.
Maybe what you actually mean to do here is lock it before you get
the session data, make changes to it and then unlock it once you're
done changing it. Doing that would likely keep the row locked for
the entire duration of a request which can start causing problems
as traffic increases.
I'm starting the transaction because MySQL "SELECT... FOR UPDATE"
requires a transaction to lock the row. But now that I think about
it... the reason we use the lock is so that we don't have collisions
in data - specifically here the user session. However, the user
session row is only accessed by a single user (his/her own). And
since they can only be logged in at one location, there's virtually
no way for a collision. Right? I can remove queries 6, 7, and 9,
right?
Yes, you only need the update statement.
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
You may think they're required, but I'm betting they're not if you
really think about it. However, if your DB can handle it then why
fix something that ain't broken.
It can handle it now. But I'm not worried about now. We have less
than 10 clients/offices using the app. This may grow up to 100
within the next year. That's when there's gonna be lots and lots of
data and we may start to see a slow down.
That's not even close to a large number of users, but it depends a lot
on what else the servers you're hosting it on are being used for.
The way I approach this stuff is always with the knowledge that the
database is the most expensive resource in the infrastructure, so
anything I can do to avoid using it when it's not strictly
necessary is something I consider well-worth the effort.
With the rise of frameworks and the lazy architectures it's pretty
common to end up with this mass of DB access at the start of each
request, but it won't scale and it leads to assumptions that are
extremely expensive to find and fix when you do need to scale.
Trust me, I've been there many times and it's been painful every
time!
Can you explain why it won't scale and may lead to assumptions?
Sure. With an architecture like this you start to assume that X is
available anywhere in your code because at the moment you know the
framework loads it for you. This makes it exceedingly difficult to
strip the initialisation code down if you end up needing to optimise
the crap out of it.
As far as scaling goes you're placing all the load on the database so
if you get to a stage where you can no longer vertically scale the DB
hardware you're left with a major rewrite of your entire codebase to
allow it to scale horizontally. It's possible that your app is capable
of being sharded across multiple servers but chances are that's still
going to take major surgery to achieve.
Some on the list may have noticed I'm a bit anal about scalability
issues, but it's only because I've inherited several systems now that
were never designed with scalability in mind and I ended up almost
completely rewriting each one. Every new site I develop now is built
so it's modular, can spread across multiple servers if/when needed and
doesn't waste resources. No doubt most web developers never hit these
problems, but I guess I've just been unlucky in that respect.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
