Tickets :: Comment on [#12136] Session Timeout not enforced

* Your Email Address
* Spam protection	Enter the letters below: . .. . .. ..__ \|__\|\| \ /\ /[ __ \| \|\|___ \/ \/ [_./
Comment	>> 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 > given request > > 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 > wire... again. > 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 >> probability. > > 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. > > See above. > > 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.
Attachment
Watch this ticket

Saved Queries