When is Garbage Collection done on DbSession?

Yii 2.0 General Discussions
1

I have a site running Yii2. I’ve set the session handling to be done by the Db\Session component and I’ve setup the DB with the “session” table.

What I’m seeing now is that the “session” table just keeps growing… it’s like no Garbage Collection is being made. Am I just misstaken or how does yii handle the GC - and when?

I read in the documentation it’s suppose to be done every 24 hours… But I’m not seeing this.

If someone could shed some light on this topic for me that would be highly appriciated. Thank you.

2

This doesn’t address your issue directly, but I would strongly recommend you don’t use a db for sessions. If you use memcached(good) or redis(better eg, not subject to 1MB limit) you will avoid the garbage collection issue altogether.

3

Let’s say I don’t have any of this available. Wouldn’t the DB be the best option? (from the out-of-the-box options like File etc.)

Is the GC an issue with the database DbSession so I should run my own routine to clear the table of old sessions?

The documentation recommends the DbSession as a better alternative to the File storage.

4

If you have a site running on one server then db sessions offer no advantage, they just put additional load on your db. Assuming you are hosting on *nix, filesystem based sessions are extremely fast because of *nix excellent filesystem caching and you have no GC issue.

If you are hosting across multiple servers then either use sticky sessions on your load balancer or seriously consider redis.

If you want to stick with the db sessions, you could easily setup a cron job to purge sessions older than x but IMHO it just seems like an awful lot of work for no benefit

5

Then I’ll just switch to the File storage option. I’m running Debian7 Nginx.

Will I have any problem with GC on the File storage or will that "work better" then the DbSession alternative?

Thank you!

6

The Yii2 documentation states this though. What’s you comment on that?

7

My comment on that is that I think it is a bad idea if you have any kind of scale. A RDBMS for storing sessions is using a sledgehammer to crack a nut. However, I do understand that it is very simple to implement and alternatives such as a key/value store may not always be available.

8

So you would recommand DbSession over FileSession for a medium site? (let’s say around 50,000 hits a day)

9

Myself, I would never put sessions in the db; in a huge percentage of modern web apps it is the storage (usually RDBMS) that is the bottleneck so adding more load to that makes no sense to me. As I stated above it is also a sledgehammer to crack a nut.

I would use file based sessions until scale meant moving to a key/value store.

I would recommend you start with file based sessions, so that you avoid the GC issue and if, when you come to do performance profiling, you find that there are some big delays in sessions, you could consider alternatives. However, my guess is that you would have many other higher leverage optimisations to make before sessions would yield any tangible gains.

10

Thanks flarpy for all the input :)