[Tickets #12136] Re: Session Timeout not enforced
noreply at bugs.horde.org
noreply at bugs.horde.org
Thu May 2 17:27:39 UTC 2013
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: http://bugs.horde.org/ticket/12136
Ticket | 12136
Updated By | Michael Slusarz <slusarz at horde.org>
Summary | Session Timeout not enforced
Queue | Horde Framework Packages
Version | Git master
Type | Bug
State | Feedback
Priority | 2. Medium
Michael Slusarz <slusarz at horde.org> (2013-05-02 11:27) wrote:
> I can't tell about the cost of storing the session if not necessary,
> but Michael has put a lot of work into only writing to the session
> if really necessary, so I trust him that there are very good reason
> to not write to the session on every request.
Many years ago, I was retained by a large company that wanted to
further adapt Horde (mostly IMP at the time) to enterprise-level
performance. At the beginning of this work, we looked at the
bottlenecks of the system. Two things stood out (there was more than
two... but these were the first time items on the list and pertinent
for the present discussion):
1) c-client's performance was atrocious
2) session retrieval/saving took up way too much resources for any
Admittedly, the former was the much bigger performance issue than the
latter (2-3 times). Hence Horde_Imap_Client was born. But I digress...
As for the latter, we were seeing things like an internal network,
solely for purposes of interacting with the session storage, being
completely swamped. This was because of several factors:
1) We were using session storage as a general cache. So session sizes
were way too large. This was remedied by moving large data items out
of the session.
2) Along with 1, session data on the wire could be large - 50-100 KB
may not sound like much, but on every access and with 1,000s of active
users, it adds up. An easy way to reduce the load was implementing
lzf compression of session data.
3) unserializing is not free. Pretty much dependent on session size (see 1)
...and, important for our current discussion:
4) serializing is not free. Dependent on 1, but this action is
completely avoidable if session data does not change in a request.
5) See number 2 above - session data then needs to be sent out on the
6) There is no guarantee of the performance of the session storage
backend. For people who use SQL databases to store session data,
write times and propagation across a cluster can take forever (one of
the reasons session data is NOT RECOMMENDED for SQL databases). Not
to mention that theses SQL databases may have a caching component in
front of it - e.g. memcache. So *2* systems potentially need to be
updated on every session write
What we learned is that by preventing/limiting session writes,
performance was vastly improved.
And from a theoretical perspective of how session data is supposed to
be used, this makes sense. Session data is there to store things like
authentication/configuration information. These are things that
normally occur once per application upon initial authentication.
Now... session storage is flexible enough to allow data to be stored
in it at a later time, but this should be avoided as a
practice/performance consideration as much as possible.
> I'm with Michael that it's perfectly fine to not being able to set
> the session timeout on the minute, but rely on PHP's session garbage
> collection which exact purpose it to kill outdated sessions. If it
> doesn't do this quick enough for you, and you accept the additional
> performance penalty (which you do, see above), set a higher
Exactly. Not only would you lose the performance advantage, but you
lose the performance advantage WITHOUT ANY ADDITIONAL FUNCTIONALITY
THAT DOESN'T ALREADY EXIST.
Additionally, I think you are mistaking session expiration as a
front-line security mechanism. It isn't. Obviously, leaving sessions
active forever is a bad idea. But the simple fact that a session is
slightly aged in and of itself is NOT an appreciable security risk.
As I have mentioned before, and Jan repeated, I have yet to hear how
something like a 30 minute timed session that is not actually removed
until 45 minutes is in actual security risk.
>> I didn't yet get why it should be a bad idea to write to the session
>> on each request. The only thing I can think of is that the write
>> operation is expensive. But I think horde is probably doing much more
>> expensive operations during a request than updating a session. But
>> I'm not an expert.
> I'll leave this to Michael to explain why he has such a strong
> opinion about this.
That's why I have to laugh when I see people post on the PHP
manual/other random internet site and act like session storage is
"free". That is so near-sighted, it is comical. Yes, it works on a
single-user site. But expecting that to work on any halfway loaded
installation with any sort of speed is sort of like expecting an
sqlite database to be able to scale up to the size of serving all
Google search requests.
More information about the bugs