On Sun, Mar 14, 2010 at 5:12 PM, moses wejuli <[email protected]>wrote:
> there seems to be a general phobia out there of storing sessions in the DB It's not a phobia it's simply the case that it's easier to scale out by throwing more machines with app-server/memcached pairs in than scaling the database. For our current project we also have a policy that for a single "normal" request the database must not be touched (placing an order in fact is allowed to hit the database). The memcached-session-manager also serves sessions from local memory for optimal performance, so that for a single request there's no I/O needed. Writing sessions to memcached after the request is finished can be done asynchronously. And if such a write would fail occasionally the application can still work correctly as the up-to-date session is still in local memory (the primary data source). Cheers, Martin > -- 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/ >> > > -- Martin Grotzke http://www.javakaffee.de/blog/
