PHP Sessions = Member Database Cache
Web Development
|
Let�s go over what a session is.
Sessions
First you call session_start() which gives you a unique ID such as: dde2ds2g67xs2zxjh89s3j8923
Everything you then save to $_SESSION is saved in a file on the server such as:
$_SESSION['message'] = 'hello';
Would be saved to:
tmp/phpsess_dde2ds2g67xs2zxjh89s3j8923
and next time you call session_start(), $_SESSION['message'] will still exist and will have 'hello' in it!
Database Problem
So, you record a members total page hits on your site, and the last time they made a page hit on your site. You keep these stats up to date like this (which is executed on EVERY page hit by the member):
$time = time();
mysql_query("UPDATE `members` SET `timestamp_last_seen` = '{$time}', `hits` = `hits` + 1 WHERE `member` = 'VBAssassin' LIMIT 1;");
Now, all you�re doing is keeping track of the last time they were seen, and the total page hits they have made while logged in.
Solution
You need to keep track of your active sessions using the database - which you are probably doing anyway to prevent session hi-jacking and other attacks.
Now open up the php.ini file and edit this line (or add it if it doesn�t exist):
session.gc_maxlifetime = 43200
That will make your sessions stay active for 24 hours, but your controlling them with your PHP code anyway so you will manually make them expire much sooner - say the default 24 minutes  meaning performance won't be affected at all.
When the member is browsing your site
You simply update the vars in the session like:
$_SESSION['memberid'] = 23;
$_SESSION['timestamp'] = time();
$_SESSION['hits'] = intval(@$_SESSION['hits']) + 1;
Run this code for every page hit the member makes while logged in.
When a session expires
Now when someone visits your site, and you prune out all the expired sessions (or the user logs out manually to destroy the session) make sure you get the session_id of the session your destroying because now is when you will permanently save the members stats to the database and remove it from the cache (session). Before destroying it locates the session file using PHP (which will likely be in your sites tmp file).
Read the file in to a php variable and extract the information you need. Which are the following (as they appear in the session file):
memberid|i:23;timestamp|i:1220391592;hits|i:564;
A quick bit of regex will extract the values you want so you have:
$memberid = 23
$timestamp = 1220391592
$hits = 564
Now what you have to do is simply update the member�s record with the new values from the cache.
mysql_query("UPDATE `members` SET `timestamp` = '$timestamp', `hits` = `hits` + $hits WHERE `member_id` = '$hits' LIMIT 1;");
And then continue to destroy the session file once and for all 
How has this helped?
Basically if you didn't do this you would likely either not keep those details, or keep very few such up to date details because of the overhead cost on the database having to keep them up to date with EVERY page hit the member makes.
The Old Way
300 pages hits = 300 write operations
The New Way
300 page hits = 1 write operation
The Benefits
Besides what i just mentioned above in regards to benefits you will now be able to add as many stats about your members as you like with little performance loss! You could add the last page they visited, their complete http request header, etc... and they will be kept up to date as possible and saved permanently in the database!
Summary
In simple terms the data is cached in the session where it is kept up to date and before it is removed from the session it is shifted across to permanent storage in the database. You need to store it with each page hit to make sure the data is as up to date as possible because you never know which will be the members last page hit!
Have fun caching...
Kind regards,
ScottPlease login to rate coding articles.
Click here to register a free account with us. |
|
|
Comments
|
| Please login to post comments. |
|
|
Hi ya,
If you use smart directories so the sessions files per directory are minimum (like
5 session files per folder) then the disk will not suffer from accessing directories
with thousands of files.
When the database has many read/write operating on a single table, it is easy to
cripple a database like that with exponential decline. Unlike a disk, where your only
real problem is that of scalability (write/read - no indexes etc to keep to up date,
tables to open, etc) which is much easier to scale (just create a dedicated server to
handle sessions).
Kind regards,
Scott
P.S. Take a look at this book:
http://www.amazon.com/Scalable-Internet-Architectures-Developers-Library/dp/067232699
X/
|
|
|
So you trade out hits on your db to hits on your disk.
Depending on how many files are in your saved session directory this could be more
expensive in cpu and io. You are doing a directory search, file open, read, close,
directory search, file open, write, close verses a db select and db update on a
record you probably are already doing a db select anyway.
Not sure which is better, but I would bet the db access would be better.
|
|
|
 |
Scott Thompson (22)
United Kingdom, Lincolnshire |
|
|
VBAssassin has 31 fans
become a fan |
|
 |
|
|
 |
|
