Ondřej Žára wrote:
Are you using Debian? Debian doesn't use the session GC in PHP - instead, it cleans sessions in a cronjob. To enable PHP GC in Roundcube, one must add (to main.inc.php) these lines:
ini_set('session.gc_probability', 5); ini_set('session.gc_divisor', 100);
Values '5' and '100' were chosen experimentaly by me, use your own if you want :)
Someone should add above info to installation manual.
By the way, reading rcube_sess_gc() I found an improvement possibility. Function could be simpler and speed increased if we'll create index on cache.session_id column with "ON DELETE CASCADE" reference, but it needs innodb in mysql (foreign keys not supported by myisam tables), and triggers in sqlite (foreign keys not supported at all).
On Thu, Oct 2, 2008 at 12:48 PM, A.L.E.C alec@alec.pl wrote:
Ondřej Žára wrote:
Are you using Debian? Debian doesn't use the session GC in PHP - instead, it cleans sessions in a cronjob. To enable PHP GC in Roundcube, one must add (to main.inc.php) these lines:
Wonder why the maintainer did that. Sounds pretty weird.
ini_set('session.gc_probability', 5); ini_set('session.gc_divisor', 100);
To avoid hacking in main.inc.php, you could add this in php.ini as well, or if you are running Apache in httpd.conf/.htaccess.
Values '5' and '100' were chosen experimentaly by me, use your own if you want :)
Someone should add above info to installation manual.
By the way, reading rcube_sess_gc() I found an improvement possibility. Function could be simpler and speed increased if we'll create index on cache.session_id column with "ON DELETE CASCADE" reference, but it needs innodb in mysql (foreign keys not supported by myisam tables), and triggers in sqlite (foreign keys not supported at all).
Not sure if it's worth it. That will throw off a bunch of people and make it way more complex.
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
Are you using Debian? Debian doesn't use the session GC in PHP - instead, it cleans sessions in a cronjob. To enable PHP GC in Roundcube, one
must
add (to main.inc.php) these lines:
Wonder why the maintainer did that. Sounds pretty weird.
Quoting from the Debian php.ini file:
; This is disabled in the Debian packages, due to the strict permissions ; on /var/lib/php5. Instead of setting this here, see the cronjob at ; /etc/cron.d/php5, which uses the session.gc_maxlifetime setting below ;session.gc_probability = 0
Ondrej
List info: http://lists.roundcube.net/dev/
Ondřej Žára wrote:
Are you using Debian? Debian doesn't use the session GC in PHP - instead, it cleans sessions in a cronjob. To enable PHP GC in Roundcube, one
must
add (to main.inc.php) these lines:
Wonder why the maintainer did that. Sounds pretty weird.
Quoting from the Debian php.ini file:
; This is disabled in the Debian packages, due to the strict permissions ; on /var/lib/php5. Instead of setting this here, see the cronjob at ; /etc/cron.d/php5, which uses the session.gc_maxlifetime setting below ;session.gc_probability = 0
I looked into the cron job in Debian. It cleans only file based sessions. RC uses database to store its sessions, so RC has to do its own cleanup and apparently it does it in rcube_sess_gc().
A.L.E.C wrote:
Ondřej Žára wrote:
Are you using Debian? Debian doesn't use the session GC in PHP - instead, it cleans sessions in a cronjob. To enable PHP GC in Roundcube, one must add (to main.inc.php) these lines:
ini_set('session.gc_probability', 5); ini_set('session.gc_divisor', 100);
Values '5' and '100' were chosen experimentaly by me, use your own if you want :)
Someone should add above info to installation manual.
By the way, reading rcube_sess_gc() I found an improvement possibility. Function could be simpler and speed increased if we'll create index on cache.session_id column with "ON DELETE CASCADE" reference, but it needs innodb in mysql (foreign keys not supported by myisam tables), and triggers in sqlite (foreign keys not supported at all).
Another solution would be to get rid of the initial SELECT query and IN (... ) clauses and do one DELETE query with a JOIN between "session" and "cache" and second DELETE just for session. Both DELETEs would just have a now()-changed > $maxlifetime WHERE clause. now() is constant, so it may be better to write expression like now()-$maxlifetime > changed. If there is an index on changed column, the search would be very quick. This approach has a potential of non atomic commit if cache entry is created between the two DELETEs. So it should be wrapped into a transaction.
Another approach for MySQL is multiple table DELETE. http://dev.mysql.com/doc/refman/5.1/en/delete.html However, there are no such thing in SQLite or PostgreSQL.
Dennis P. Nikolaenko wrote:
By the way, reading rcube_sess_gc() I found an improvement possibility. Function could be simpler and speed increased if we'll create index on cache.session_id column with "ON DELETE CASCADE" reference, but it needs innodb in mysql (foreign keys not supported by myisam tables), and triggers in sqlite (foreign keys not supported at all).
Another solution would be to get rid of the initial SELECT query and IN (... ) clauses and do one DELETE query with a JOIN between "session" and "cache" and second DELETE just for session. Both DELETEs would just have a now()-changed > $maxlifetime WHERE clause. now() is constant, so it may be better to write expression like now()-$maxlifetime > changed. If there is an index on changed column, the search would be very quick. This approach has a potential of non atomic commit if cache entry is created between the two DELETEs. So it should be wrapped into a transaction.
So, adding cache.session_id and session.changed indexes will be a good improvement for now.
A.L.E.C wrote:
Dennis P. Nikolaenko wrote:
By the way, reading rcube_sess_gc() I found an improvement possibility. Function could be simpler and speed increased if we'll create index on cache.session_id column with "ON DELETE CASCADE" reference, but it needs innodb in mysql (foreign keys not supported by myisam tables), and triggers in sqlite (foreign keys not supported at all).
Another solution would be to get rid of the initial SELECT query and IN (... ) clauses and do one DELETE query with a JOIN between "session" and "cache" and second DELETE just for session. Both DELETEs would just have a now()-changed > $maxlifetime WHERE clause. now() is constant, so it may be better to write expression like now()-$maxlifetime > changed. If there is an index on changed column, the search would be very quick. This approach has a potential of non atomic commit if cache entry is created between the two DELETEs. So it should be wrapped into a transaction.
So, adding cache.session_id and session.changed indexes will be a good improvement for now.
Now my session table shrank to a reasonable amount of entries. Thanks!
-
A.L.E.C -
Dennis P. Nikolaenko -
Ondřej Žára -
till