Skip to content

Add a cookbook entry on how to prevent unnecessary session writes #3017

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Oct 10, 2013
Merged

Add a cookbook entry on how to prevent unnecessary session writes #3017

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions cookbook/map.rst.inc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -148,6 +148,7 @@
* :doc:`/cookbook/session/locale_sticky_session`
* :doc:`/cookbook/session/sessions_directory`
* :doc:`/cookbook/session/php_bridge`
* :doc:`/cookbook/session/limit_metadata_writes`

* **symfony1**

Expand Down
3 changes: 2 additions & 1 deletion cookbook/session/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,4 +7,5 @@ Sessions
proxy_examples
locale_sticky_session
sessions_directory
php_bridge
php_bridge
limit_metadata_writes
68 changes: 68 additions & 0 deletions cookbook/session/limit_metadata_writes.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
.. index::
single: Limit Metadata Writes; Session

Limit session metadata writes
=============================

.. versionadded:: 2.4
The ability to limit session metadata writes was added in Symfony 2.4.

The default behaviour of PHP session is to persist the session regardless of
whether the session data has changed or not. In Symfony, each time the session
is accessed metadata is recorded (session created/last used) which can be used
to determine session age and idle time.

If for performance reasons you wish to limit the frequency at which the session
persists, this feature can adjust the granularity of the metadata updates and
persist the session less often while still maintaining relatively accurate
metadata. If other session data is changed, the session will always persist.

You can tell Symfony not to update the metadata "session last updated" time
until a certain amount of time has passed, by setting
``framework.session.metadata_update_threshold`` to a value in seconds greater
than zero:

.. configuration-block::

.. code-block:: yaml

framework:
session:
metadata_update_threshold: 120

.. code-block:: xml

<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:framework="http://symfony.com/schema/dic/symfony"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services http://symfony.com/schema/dic/services/services-1.0.xsd
http://symfony.com/schema/dic/symfony http://symfony.com/schema/dic/symfony/symfony-1.0.xsd">

<framework:config>
<framework:session metadata-update-threshold="120" />
</framework:config>

</container>

.. code-block:: php

$container->loadFromExtension('framework', array(
'session' => array(
'metadata_update_threshold' => 120,
),
));

.. info::

PHP default's behavior is to save the session whether it has been changed or
not. When using ``framework.session.metadata_update_threshold`` Symfony
will wrap the session handler (configured at
``framework.session.handler_id``) into the WriteCheckSessionHandler, that
will prevent any session write if the session was not modified.

.. caution::

Be aware that if the session is not written at every request, it may be
garbage collected sooner than usual. This means that your users may be
logged out sooner than expected.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about this too, I'm not sure it's relevant - misconfiguring GC values can always have consequences and it's not really part of this feature so it really doesn't belong here. You could just delete this caution entirely.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think users should be warned that this feature "alters" the default GC behavior

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont see how it affects GC: GC is set as a probability of being called by PHP and is a PHP ini configuration value. Your PR does nothing to affect that. what it does affect is the accuracy of the metadata so anything that relies on that metadata could be affected.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand it, if my session data isn't saved each time, then (using the PdoSessionHandler as an example) when garbage collection is called (whenever it happens to be called), my session may appear to be older than it really is (e.g. the sess_time column shows 1 hour ago, even though I've been surfing around actively during the last hour). This would cause my session to get deleted earlier than it might have been. You could certainly write a session handler that doesn't use this time metadata during its garbage collection process, but most handlers would use it, wouldn't they? So if I understand it correctly. @adrienbrault's warning here makes sense. GC isn't triggered more often, but if it is, your session may be deleted earlier than it would have been otherwise.

Is that accurate?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@weaverryan - what I am saying is it does not makes sense here. Triggering of GC is nothing to do with this feature so the caveat must not appear here or it is both confusing and in the wrong place meaning people would not see it unless browsing this particular entry.

If there is any place for a note (and I would say note not warning), it would be here: https://github.com/symfony/symfony-docs/blob/master/components/http_foundation/session_configuration.rst#configuring-garbage-collection

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Drak Is the saved time updated on every request when you use the framework.session.metadata_update_threshold option?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what I'm wondering. It seems that if you use the threshold, then your saved time isn't updated on each request, so when garbage collection is randomly triggered, your session time may look old (and therefore could be deleted) when it is really not old. Because the saved time is not updated, my session may look like it was last saved 20 minutes ago, triggering cleanup if my lifetime is 15 minutes. But in reality, I've been surfing the site actively. If I understand this correctly, then this seems like an issue that's entirely specific to the threshold feature.

So @Drak is right that this doesn't affect the triggering of GC, but it does seem like the threshold will affect the behavior once the GC has been triggered. Do you agree? Perhaps it's just a wording issue and this would be better:

Be aware that if the session is not written on every request, a session's last
"saved" time may appear to be older than it really is. During the garbage collection
process, this could trigger the session to appear older than your session lifetime
and cause it to be removed. The result is that users may reach the session lifetime
and be logged out even while actively using the site.

What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 I think that addresses the problem properly.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@weaverryan merge this - I will make a separate PR when I get time. There are a few things that need to be clarified properly. Better to have this documented now and I can tweak it afterwards, even if it's not 100% accurate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Drak sounds good :) - I've merged this in