> Cool. Would it be possible to make this number configurable via a cmd line > switch?
You really don't want to mess with this value. It will bring you the absolute opposite results of what you expect. Memcached does this search while holding a global mutex lock, so no other threads are able to access the allocator at the same time. It must be very fast, and most people will just crank it and grind the system to a halt, so I'm unsure if we will make this configurable. The number's just in a couple places in items.c if you wish to recompile it and test, but again that's absolutely not a good idea if you want it to perform. > That's right for the normal case. However, for the memcached-session-manager > I just implemented a feature so that sessions are only sent to memcached for > backup if session data was modified. To prevent > expiration of the session in memcached, a background thread is updating > sessions in memcached that would expire ~20 seconds later in memcached (if > there would be some kind of "touch" operation I'd just use > that one). When they are updated, they are set with an expiration of the > remaining expiration time in tomcat. This would introduce the issue, that the > update would push them to the head of the LRU, but > their expiration might be e.g. only 5 minutes. So they would be expired but > won't be reached when the 50 items are checked for expiration. Are sessions modified on every hit? or just fetched on every hit? I don't see how this would be different since active sessions are still getting put to the front of the LRU. When you modify a session isn't the expiration time of that session extended usually? Or do users get logged out after they've run out of their 5 free hours of AOL? Honestly, if you have a background thread that can already find sessions when they're about to expire, why not issue a DELETE to memcached when they do expire? Or even a GET after they expire :) > That's true, this is the drawback that I'd have to accept. > > Do you see other disadvantages with this approach (e.g. performance wise)? Shouldn't be any particular performance disadvantage, other than serverely reducing the effectiveness of your cache and caching fewer items overall :P > Yes, for this I (the memcached-session-manager) should provide some stats on > size distribution. > Or does memcached already provide this information via its stats? `stats items` and `stats slabs` provide many statistics on individual slabs. You can monitor this to see if a particular slab size is having a higher number of evictions and doesn't have enough slabs assigned to it. As well as how many items are in each slab and all that junk. > In my case this is not that much an issue (users won't get logged out), as > sessions are served from local memory. Session are only in memcached for the > purpose of session failover. So this restart could be > done when operations could be *sure* that no tomcat will die. Tomcat sounds like such a pisser :P Even with your backup thing I'd probably still add an option to allow it to journal to a database, and I say this knowing how to get every last ounce of efficiency out of memcached. -Dormando
