Ken Snyder wrote:
1. Do not garbage collect on every request. Basically, you can add a
time check against sessions.ses_date_modified in the where clause of
the _read() function query and then do garbage collection from a
periodic cron script.
2. Don't lock the table. The majority of your application is probably
not subject to race conditions in the sessions. Instead of locking
the session every time, try an explicit lock when you need it. The
locking doesn't even have to be session-specific. You can use the
mysql functions GET_LOCK(), IS_USED_LOCK(), and RELEASE_LOCK()
(http://dev.mysql.com/doc/refman/4.1/en/miscellaneous-functions.html).
Basically what you do here is add some functions to your session class:
Chad,
1) As mentioned recently, the delete statement
DELETE FROM sessions WHERE
(UNIX_TIMESTAMP(now())-UNIX_TIMESTAMP(ses_date_created))>" . $life
can't use the index you have on ses_date_created since you're using a
function on the indexed field. MySQL has to do a table scan every
time. So if this happens frequently (every page load), it's definitely
your session bottleneck. Better would be to do something like:
DELETE FROM sessions WHERE ses_date_created < DATE_SUB(NOW(), INTERVAL
".$life." SECOND)
I definitely agree with Ken, though, that you should only bother to do
this once a day. It generally doesn't hurt you to have extraneous
sessions sitting in your table.
2) As Ken points out, unless you're doing something pretty unusual with
your sessions, you wouldn't need any locking at all apart from what
MySQL does automatically. I didn't notice any locking in your code
though...?
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
