10 replies to this topic

[Pete]

Hi folks

So I've got a very active PW site up and running (finally) but I'm not ready to link to it until I finish my snag list

I was just looking through the log files, and noticed the site/assets/sessions folder - it has almost 3,000 session files in it already and the site's not been online 24 hours yet!

Are these required for something? They all seem to contain the same content:

Session|a:0:{}

Seems a bit pointless, and I'm not sure what they relate to - any ideas anyone?

[apeisa]

Pete: similar to this http://processwire.c...__fromsearch__1

We don't have this problem anymore and I don't remember actual solution, but maybe vsulin will drop in and tell? It was something about server settings and ubuntu defaults anyway...

[Pete]

Cheers for that - it only appears to be keeping about 24 hours of them which is how it's suposed to work I see. Fortunately that stops it at 5,600 files

[ryan]

I'm going to be adding an option to store sessions in the DB soon too, so this will be another alternative option for those that want it.

[Pete]

That's good to know ryan, even though I'm not sure if it's doing any harm with that many files. I was just curious as to why it needed so many empty files. Is it more of a "just in case" thing in case any session vars get set or something?

[ryan]

This is one of those things that has to do with the inner-workings of PHP's session system. I've not attempted to override PHP's session storage mechanisms with PW (other than where it places the files) so this is probably a question for Rasmus Lerdorf. But I believe they are just placeholder files to track an active session, and they won't contain any significant data in them unless you specifically set it to the $session var. In lieu of tracking data, the filename itself is likely of more importance since it relates the session ID from the user's cookie to the session ID on the server. Of course, once we provide the option of DB session storage, we will be taking over more control from PHP in this area... at least when DB session storage is selected.

[netcarver]

Ryan,

check out flourish's handling of sessions for some inspiration too. Though not fully documented at the front-of-site, it allows different session storage mechanisms via the setBackend() static call. I have to add, I haven't used this personally but thought I'd throw this into the ring if you are about to do some research.

[joe_g]

Hello there. I'm currently deleteing 160.000 session files : )

 

rgds,

J

[Soma]

If the garbage collector on server is set wrong this can happen.

 

The good news, there's is now DB session module in PW since some versions in dev already to handle session via DB. Just install it. https://github.com/r...modules/Session

[ryan]

If PHP's garbage collector isn't working right, it'll affect DB sessions too. @joe_g, unless your site really handles that many sessions in a day, you may want to look into your PHP garbage collector settings. The relevant PHP settings are session.gc_probability, session.gc_divisor and session.gc_maxlifetime. We set the gc_maxlifetime automatically based on your $config->sessionExpireSeconds setting, but not the other two. However, you can force specific settings for those by adding lines like this to your /site/config.php file:

 

ini_set("session.gc_probability", 1);
ini_set("session.gc_divisor", 100);

[joe_g]

thanks! Will try this.