there seems to be a general phobia out there of storing sessions in the DB -- i know this coz i had it once, but overcame it by realizing (mentally and through this forum) that we really should use memcached for what it's good at and NOT as a persistent data store.
unless you have abysmally low/poor server specs, i think you shouldn't worry about perfomance issues with regard to DB-based session handling -- enhanced with memcached! On 14 March 2010 13:27, Martin Grotzke <[email protected]>wrote: > Yes, what you described is similar to the situation with the sessions not > updated in memcached as they were only read by the application issue. > > Still, I think if there's enough memory for all active sessions only > sessions should be dropped that are in fact expired. For this a simplified > slab configuration (one slab for all sessions) would be helpful AFAICS. > > Cheers, > Martin > > > On Sun, Mar 14, 2010 at 8:54 AM, Peter J. Holzer <[email protected]> wrote: > >> On 2010-03-12 17:07:25 -0800, dormando wrote: >> > Now, it should be obvious that if a user session has reached a point >> where >> > it would be evicted early, it is because you did not have enough memory >> to >> > store *all active sessions anyway*. The odds of it evicting someone who >> > has visited your site *after* me are highly unlikely. The longer I stay >> > off the site, the higher the odds of it being evicted early due to lack >> of >> > memory. >> > >> > This does mean, by way of painfully describing how an LRU works, that >> the >> > odds of you finding sessions in memcached which have not been expired, >> but >> > are being evicted from the LRU earlier than expired sessions, is very >> > unlikely. >> [...] >> > The caveat is that memcached has one LRU per slab class. >> > >> > So, lets say your traffic ends up looking like: >> > >> > - For the first 10,000 sessions, they are all 200 kilobytes. This ends >> up >> > having memcached allocate all of its slab memory toward something that >> > will fit 200k items. >> > - You get linked from the frontpage of digg.com and suddenly you have a >> > bunch of n00bass users hitting your site. They have smaller sessions >> since >> > they are newbies. 10k items. >> > - Memcached has only reserved 1 megabyte toward 10k items. So now all of >> > your newbies share a 1 megabyte store for sessions, instead of 200 >> > megabytes. >> >> There's another caveat (I think Martin may have been referring to this >> scenario, but he wasn't very clear): >> >> >> Suppose you have two kinds of entries in your memcached, with different >> expire times. For example, in addition to your sessions with 3600s, you >> have some alert box with an expiry time of 60s. By chance, >> both items are approximately the same size and occupy the same slab >> class(es). >> >> You have enough memory to keep all sessions for 3600 seconds and enough >> memory to keep all alert boxes for 60 seconds. But you don't have enough >> memory to keep all alert boxes for 3600 seconds (why should you, they >> expire >> after 60 seconds). >> >> Now, when you walk the LRU chain, the search for expired items will only >> return expired alert boxes which are about as old as your oldest session. >> As soon as there are 50 (not yet expired) sessions older than the oldest >> (expired) alert box, you will evict a session although you still have a >> lot of expired alert boxes which you could reuse. >> >> The only workaround for this problem I can see is to use different >> memcached servers for items of (wildly) different expiration times. >> >> > However the slab out of balance thing is a real fault of ours. It's a >> > project on my plate to have automated slab rebalancing done in some >> usable >> > fashion within the next several weeks. This means that if a slab is out >> of >> > memory and under pressure, memcached will decide if it can pull memory >> > from another slab class to satisfy that need. As the size of your items >> > change over time, it will thus try to compensate. >> >> That's good to hear. >> >> hp >> >> -- >> _ | Peter J. Holzer | Openmoko has already embedded >> |_|_) | Sysadmin WSR | voting system. >> | | | [email protected] | Named "If you want it -- write it" >> __/ | http://www.hjp.at/ | -- Ilja O. on [email protected] >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> >> iD4DBQFLnJYsfZ+RkG8quy0RAqt8AJoCTvx1wPJE6Q4P7+rz8Pvi2l2HLgCYvhpa >> SBop1pFUnyf6ODozse9kyA== >> =c9w0 >> -----END PGP SIGNATURE----- >> >> > > > -- > Martin Grotzke > http://www.javakaffee.de/blog/ >
