New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Session][3.0] PdoSessionHandler: precalculate expiry timestamp #13955

Open
Tobion opened this Issue Mar 17, 2015 · 6 comments

Comments

Projects
None yet
8 participants
@Tobion
Member

Tobion commented Mar 17, 2015

Based on #13858 we should make the following BC break in 3.0 to speed up garbage collection in PdoSessionHandler.

  1. rename sess_lifetime column to sess_exipiry
  2. save time + lifetime in sess_exipiry
  3. probably add an index on sess_exipiry
  4. change gc() to delete by sess_exipiry
@robertfausk

This comment has been minimized.

robertfausk commented Apr 20, 2015

+1 for that. PdoSessionHandler as of symfony 2.7 is not usable on large production websites with default php session garbage collector.

@rodinia814

This comment has been minimized.

rodinia814 commented Sep 23, 2016

This was delayed until 4.0? I'm having the same problem as the poster of #15020. It's causing significant production issues.

@digilist

This comment has been minimized.

Contributor

digilist commented Sep 26, 2016

Why not introduce a new Session Handler that can be used as an alternative to PdoSessionHandler? Anyone who is aware of this problem can switch the handler and everybody else stays with the current solution. This would not introduce any BC.

@bcremer

This comment has been minimized.

Contributor

bcremer commented Jan 25, 2017

Our clients have the same Lock timeout issue since we introduced PdoSessionHandler recently so I implemented this proposed changes in a shopware plugin: https://github.com/bcremer/SwagSessionHandler/blob/master/PdoSessionHandler.php

I would like to open a Pull Request to Symfony/Symfony with the updated PdoSessionHandler, any objections how to proceed? In #14625 the same failed because of deprecation issues.

bcremer added a commit to bcremer/symfony that referenced this issue Jan 26, 2017

[HttpFoundation] Precalculate expiry timestamp
Removed timestamp and lifetime columns in favor of expiry column.
Based on the work done in symfony#14625.

Fix symfony#13955.
@nicolas-grekas

This comment has been minimized.

Member

nicolas-grekas commented Jan 30, 2017

Just wondering: did you consider a chunked-delete strategy, as described eg in https://sqlperformance.com/2013/03/io-subsystem/chunk-deletes?
This will still require a full scan, but maybe this is not an issue on large installs if this is done lazily in chunks? Especially compared to adding an index (which is the goal here if I read correctly) - which can create a big space overhead (since we're talking about large installs?)

@bcremer

This comment has been minimized.

Contributor

bcremer commented Feb 1, 2017

To be honest I don't know if the added complexity for chunked deletes is worth it.
We could add a configurable LIMIT clause here https://github.com/symfony/symfony/pull/21423/files#diff-5b96aee9c7c07a0e18d1fd32f7a3028eR429 so one could decrease the limit and increase the gc_probability to archive something similarly.

For real large installs a session storage with self expiring entries like redis or memcache should be recommend.

robfrawley added a commit to src-run/symfony that referenced this issue Mar 3, 2017

[HttpFoundation] Precalculate expiry timestamp to allow indexed lookups
Removed timestamp and lifetime columns in favor of expiry column.
Based on the work done in symfony#14625.

Fix symfony#13955.

Implemented CR suggestions from nicolas-grekas
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment