Forums / Developer / eZSessionGarbageCollector run by PHP during user http request

"Please Note:

At the specific request of Ibexa we are changing this projects name to "Exponential" or "Exponential (CMS)" effective as of August, 11th 2025.
This project is not associated with the original eZ Publish software or its original developer, eZ Systems or Ibexa".

eZSessionGarbageCollector run by PHP during user http request

Previous topic

Developer

Next topic

Author	Message
Kevin Gaudin	Monday 17 May 2010 5:57:45 am Hello there, The method eZSessionGarbageCollector() is set by eZ as a PHP handler for cleaning sessions (session_set_save_handler php function) in eZ 4.0. While investigating performance issues on our Intranet production clustered RHEL servers, it appears that an important amount of slow queries (from 3 to 6 seconds) are generated by the "DELETE * FROM ezsession... " which is launched by eZSessionGarbageCollector(). With these execution time, having the session garbage collection run during users http request is a nonsense... Is this setting a recent addition to Exponential ? Do you know of performance "best practices" about Exponential which would advise to deactivate session garbage collection in php.ini or a configuration item in Exponential which would have the same effect ? My own analyse would be to set in php.ini the item session.gc_probability to 0 and run ez's cleanup.php as a daily cronjob script, as it was advised for Debian setups. Any experience on this subject is welcome, Thanks ! Kevin Twitter: @kevingaudin
Gaetano Giunta	Monday 17 May 2010 9:08:01 am - that query was altered in 4.2 so that it would not slow down db too much. Now it deletes 100 (or 50?) rows at a time. It's your best bet to fix the problem - doing it randomly on a statistical basis is the way of php (not just the way of ez) - you can increase in php.ini gc_probability and lower gc_divisor to have gc happen more frequently. That should make the queries faster if you have a site with lots of traffic (more frequency = fewer rows to delete) - also diminishing session timeout (3 days by default!) can have a positive impact, as there will be fewer sessions in the db at any given time - you can set in php.ini gc_probability = 0 and run the query via cronjob, so at least slow queries are not hitting live pages (see the cronjob session_gc.php, added in 4.1) Principal Consultant International Business Member of the Community Project Board

Author

Message

Kevin Gaudin

Monday 17 May 2010 5:57:45 am

Hello there,

The method eZSessionGarbageCollector() is set by eZ as a PHP handler for cleaning sessions (session_set_save_handler php function) in eZ 4.0.

While investigating performance issues on our Intranet production clustered RHEL servers, it appears that an important amount of slow queries (from 3 to 6 seconds) are generated by the "DELETE * FROM ezsession... " which is launched by eZSessionGarbageCollector().

With these execution time, having the session garbage collection run during users http request is a nonsense...

Is this setting a recent addition to Exponential ?

Do you know of performance "best practices" about Exponential which would advise to deactivate session garbage collection in php.ini or a configuration item in Exponential which would have the same effect ?

My own analyse would be to set in php.ini the item session.gc_probability to 0 and run ez's cleanup.php as a daily cronjob script, as it was advised for Debian setups.

Any experience on this subject is welcome,

Thanks !

Kevin

Twitter: @kevingaudin

Gaetano Giunta

Monday 17 May 2010 9:08:01 am

- that query was altered in 4.2 so that it would not slow down db too much. Now it deletes 100 (or 50?) rows at a time. It's your best bet to fix the problem

- doing it randomly on a statistical basis is the way of php (not just the way of ez)

- you can increase in php.ini gc_probability and lower gc_divisor to have gc happen more frequently. That should make the queries faster if you have a site with lots of traffic (more frequency = fewer rows to delete)

- also diminishing session timeout (3 days by default!) can have a positive impact, as there will be fewer sessions in the db at any given time

- you can set in php.ini gc_probability = 0 and run the query via cronjob, so at least slow queries are not hitting live pages (see the cronjob session_gc.php, added in 4.1)

Principal Consultant International Business
Member of the Community Project Board