Search

I mean you can save everything you want in it. Like $_SESSION[‘username’] = “phoque”;

Correct. We aren’t doing anything different. Cookie::set() and Cookie::get() provide interfaces for just that.

So why the need for a table when all you do is save a serialized array anyways?

The data within a session is serialised, but you cannot use the unseralize() function on it. It uses some special format specifically for sessions.

session_set_save_handler() allows you to overload the built in session reading/writing functions. If you aren’t using a custom session handler, the session data is saved in a file under /tmp and becomes nearly impossible to do anything with it. We chose to save the session data in the database and doing so affords us some niceties like the ability to query the sessions table and generate the “Who’s Online” feature of this site, or purge sessions easily.

The ONLY different here is one method saves to files, the other saves to the database. The data is the same, but the custom method lets us do more with it.

Alistair, your patch doesn’t seem to work on 2.0.7

Apologies. You need the 2.0.8 RC code.

[EDIT]: I only get this error message every few page loads.

That’s actually a good thing! It means the garbage collection function is getting triggered. (obviously the error is undesirable). You could comment out line 140 if you didn’t want to upgrade the core code to 2.0.8

Today I noticed my sym_session table containing a large number of rows. This is for a site that has not long been in use and gets almost no traffic a.t.m. There were about 1500 rows.

I know 1500 rows of session data is, in itself, marginal but I was wondering if/when/how this table is purged. I'm on 2.2.5.

I also noticed another strange thing. My session_expires was set to 2 hours back. The timezone is/should be the same as mine but I logged in at 16:40pm and the session would expire at 14:40. Am I missing something?

Edit Oops. I just realized that I am in GMT+2 and the session_expires is set to GMT so that makes sense...

Are you using the old Can Of Spam extension on this? While rewriting it, I noticed it created a session for every visitor on every page (not just on pages with forms). Default lifetime for Symphony sessions is 2 weeks, so it kept those session for 2 weeks. Could easily lead to 1500 sessions and more, depending on how many unique visitors you have on your page in 2 weeks.

Hi Jens, I am using CoS extension. version 1.0.4. and I've noticed the many rows in the canofspam tables too. Is this the latest version?

I wonder why my session_expires seems to be 2 hours instead of 2 weeks. Or does this only apply to the sessions for logged in admins?

Ah sure, you're right. I got it wrong from memory, sorry.

The old Can Of Spam (1.0.4) didn't use sessions at all, which was even worse because most of the entries were never deleted.

Latest version is 2.0 and kinda fixed the issue (only creates sessions on event-pages and Symphony should delete them automatically after 2 weeks), but only works with Symphony 2.3.

So Can Of Spam has nothing to do with your issue, but I guess another extension (with similar behaviour) has. Not sure about your session_expires, but if it's 2 hours instead of 2 weeks, it should actually lead to less instead of more session entries (Symphony would delete unused entries earlier/more often).

Edit: Maybe there's already a solution to your problem in this thread?

I have sessions tables with more than 350.000 rows. So one thing to note is: It does not seem to have any serious performance implications, so if you have just some ten thousand rows this is no reason to worry, probably.

But on the other hand: Yes, I would love to understand this session stuff, finally. I don't really get what Symphony does here (as mentioned in the other thread), but I am all ears if someone can explain it to me.

but I am all ears if someone can explain it to me

Admission: I've not read any of the above thread, but here's a brain dump that might be relevant.

Symphony stores its sessions in this table. If you've got nothing stored in your session, then Symphony shouldn't create a row. But when you do have something in your session, Symphony creates a row with your session ID and the data is stored there. As you add things to your session, so the value of the data column grows. A session has an expiry date which is stored in the table. PHP has its own garbage collection callbacks that Symphony subscribes to, which purge expired and empty session rows from the sessions table.

Previous bugs included:

  • every new session would create a row, even if the session was empty. I believe a row is only now created when it is needed, thereby keeping the table smaller (anonymous, casual users won't get a row)
  • the callback from PHP's garbage collection did not always fire, but there were settings added to the config file to control how often this occurs (I think it is triggered 1 in 10 or 1 in 100 new sessions)
  • there was a bug whereby when the table got large it would hurt performance, solved by adding column indexes to the table
  • there was a bug whereby blank sessions were not removed from the table, making it grow large, quickly. This was resolved in two ways: by preventing blank sessions from being saved in the first place, and amending the regular expression in the SQL (garbage collection callback) which finds and purges empty sessions

Thanks, Nick!

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details