Session management

Session management, a forum discussion on Jojo CMS. Join us for more discussions on Session management on our Administration (backend and configuration) forum.

Back to Forum Index : Back to Administration (backend and configuration)   RSS
tom

Developer

tom

20 Apr 2014
Posts: 379

Anyone know about this stuff? For the next release I've added to the daily management script an auto cleanout of the session data table to remove anything older than a day - mainly because I has some site ending up with ludicrously large session tables.

Partly it's my own fault - sites that use a pre-populated zero-quantity cart (for an order form type approach) and up with a whole set of cart data being stored for every single visitor.

But it does seem, as far as I can see that Jojo is writing a separate session entry for every single request, not once per session per visitor, and also, that most of the time all it's storing is a sessionid, which as far as I can tell, it never reuses. Sometimes it stores a referrer, but I can't see where this gets reused either.

Sites that are moving between http and https there is I think some need to track the id between protocols? But most sites (none that I'm using) need this. Cart sites that want to hold the session longer than a browser session I guess also need some form of stored session. But I'm not running any of those either.

Does it have to store the session in the database? Isn't it storing it in the _SESSION? Is there a way it could be more efficient? Doing multiple writes all the time seems like a bad performance hit.

I really wish I knew more about what I'm doing..
Rick Rick

24 Apr 2014
Posts: 336

I haven't looked at it much but I believe it stores the referrer for use on contact forms.

I didn't realise it was creating new entries for each request, that makes no sense to me.

I'm not sure who made the decision to store sessions in the database instead of the default, but it does allow us to query them based on a few parameters. For instance I've got a plugin that hooks into the maintenance trigger and clears out sessions older than X hours and also clears out logs based on time and entry type.

Multiple writes each time could be avoided by simply storing the session data in memory then only writing from a registered shutdown function, but this may have edge cases where it fails.
tom

Developer

tom

25 Apr 2014
Posts: 379

yeah - that approach makes sense to me, I'm just not sure how to go about changing what's there currently.

As far as I can tell, stuff like the referrer is stored in $_SESSION anyway so the Contact plugin should be able to get that data directly from there. And I can't find anywhere an example of anything actually retrieving anything from the sessiondata table. Even the cart seems to rely on cookies rather than the database for those instances where it's supposed to remain open longer than a browser session.

It doesn't make much sense to me but the sessionhandler class looks like something someone who actually knows something about programming might build, and it may well be doing something and it's just that I don't understand enough about sessions to know what..
Rick Rick

25 Apr 2014
Posts: 336

Isn't the sessiondata table linked by Jojo to the PHP sessions, so anytime we get something from $_SESSION it comes from that table? Here's the wrapper functions in jojo_core/classes/Jojo/SessionHandler.php
tom

Developer

tom

25 Apr 2014
Posts: 379

oh, OK, that makes more sense. Are there alternatives to the database approach? Or maybe it doesn't open a session until there's a reason to?
Now that it's clearing it daily it's possibly less of an issue.

I'm not sure it *is* writing a new session for each request, but have a site that has 27000 entries for a 24 hour period with maybe 500 visits.
Rick Rick

25 Apr 2014
Posts: 336

The only thing I can think of is if it was generating new sessions for all requests or maybe just all assets on the individual load, but they should be tied to the same session as the original page request.

On mobile today so can't really look at it too deeply sorry.
Rick Rick

25 Apr 2014
Posts: 336

Or... Is the 500 number coming from Analytics? Maybe analytics is ignoring some spiders, and maybe badly coded spiders aren't returning session cookies and therefore triggering multiple sessions?
Harvey

Core Developer

Harvey

26 Apr 2014
Posts: 327

I'm fairly sure the session handling was written by MikeC.

The idea was that it would be a direct replacement for PHP session handling. Storing sessions in database is essential for load-balanced sites, but it's not a bad approach to use for other sites as it keeps the session handling consistent (otherwise it's subject to PHP config on the server). One of the important things about this implementation is it increases the session timeout above the PHP default of 20 mins (20 mins timeout is a complete fuckup for shopping cart sites where people have stuff in their cart then go have dinner and come back to finish the order later).

Definitely worth checking that the session table is cleaning itself properly - sounds like it's not. My understanding was that each session was one database record, and it was safe to delete after the browser session expires.
Rick Rick

26 Apr 2014
Posts: 336

I didn't think of load balancing as I've only dealt with load balancers that use sticky sessions. But that, along with the silly timeout, makes absolute sense.

Bad crawlers are still my best guess for the large number of sessions vs visits.
tom

Developer

tom

26 Apr 2014
Posts: 379

Thanks Harvey, that's good to know. And I think Rick, you may be right - it's possibly just bad bots that are clogging the session table.
Maintenance.php now (as of 1.3.3 I think) clears out anything older than a day so it's probably safest to leave it as it is for now.
Back to Forum Index : Back to Administration (backend and configuration)   RSS
You must be logged in to post a reply



You need to Register or Log In before posting on these forums.