At first glance, it looks like they could improve performance by replacing the red-black trees guarded by reader/writer locks with skip lists. That should remove most of the lock contention that they see in their simulations.
----- Original Message ---- From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> To: memcached <[email protected]> Sent: Wednesday, October 15, 2008 3:37:13 PM Subject: Re: multi-threading support Hi, few weeks ago I've made a small research on available web app caching technologies. Memcached became my favourite, but I was a bit disappointed about the fact that multi thread support was not implemented natively. On the other hand, the multi instance capability is pretty nice, so it solves many multicore needs. I'm just wondering if an CPU binding capability exists? Is it possible to bind an memcached instance to a CPU core? Thankfully to memcached I also found this project/research: http://ivoras.sharanet.org/papers/mdcached.pdf The multi thread attempt of these guys, but also the resulting performance which is compared to memcached is pretty nice. Unfortunately the guys don't published any reliable code so far, probably it will stay as it is - an research project. Regards Oleg On 14 Okt., 22:04, "Toru Maesaka" <[EMAIL PROTECTED]> wrote: > Hi! > > FYI, from version 1.3 multi-thread build is going to be default (it > already is in the development branch). > > In addition to Todd's reply, if you actually test the performance > between a single thread build and a multi thread build, you will > notice that the performance difference is not so significant. This is > because memcached currently has a single global cache lock, thus > limiting the operation to the slab layer to one thread at a time. On > the other hand, the parser can be executed in parallel. > > I bet a lot of folks in the community are looking at improving this > (e.g. cache lock per slab_id and vertical locking). This should > hopefully be easier to do once the pluggable engine rearchitecture > happens :) > > Cheers, > Toru > > On Tue, Oct 14, 2008 at 9:24 PM, Todd Fisher <[EMAIL PROTECTED]> wrote: > > > It's true being single threaded means it will only do one *thing* at > > time, but depending on how you look at it - having only one processor > > means you'll only be able to process 1 instruction at a time or can it > > do more? This is a good read about how we can get more out of a > > single processor then just one instruction: > >http://cse.stanford.edu/class/sophomore-college/projects-00/risc/pipe... > > > If we can get more out a single processor, shouldn't we be able to do > > the same in code? read here: > >http://en.wikipedia.org/wiki/Reactor_pattern > > > Imagine processing small parts of each request within a very small > > loop, but imagine that loop to be very efficient, it won't loop more > > then necessary and it'll only run when absolutely necessary. How can > > we get the loop to have these kinds of smarts? Well, the operating > > system provides a few tools to aid us. Initially, that was in the form > > of select or poll system calls. More recently, we have kqueue and > > epoll, that can more efficiently do the work of select/poll - see > > google:http://www.google.com/search?q=epoll+select > > > There are many ways to get at this, I'd begin by looking at how you > > can write a select or poll loop - you'll notice you can break things > > up into "events" via callbacks to do specific tasks, at specific times > > during the life of a client connection (usually a socket). To make > > things easier have a look at: > > > http://monkey.org/~provos/libevent/ > > > Finally, memcached is written using the libevent library. So, while > > it's single threaded because all it is doing is processing requests > > that spend the majority of their time handling the socket input/output > > operations it can handle a substantial amount of load. If an > > operation is run however in memcached that takes much more time to do > > the work for the operation then to read input or send output, then a > > multithreaded approach might be desired. I don't know enough about > > the internals of memcached to comment... But I hope my explanation > > has been helpful. > > > On Tue, Oct 14, 2008 at 4:06 AM, wing <[EMAIL PROTECTED]> wrote: > > >> from > >>http://www.danga.com/memcached/news.bml > > >> does that mean before "Version 1.2.2", memcached is single-threaded? > > >> and for version 1.2.2+ > >> memcached is still single-threaded unless we build the memcached with > >> the following option? > > >> ./configure --enable-threads > > >> if so, without the above multi-thread mode enabled, even we configure > >> the memcached to open 300+ connections, the memcached will just do one > >> thing at a time? > > >> if our client is used to work with "single-threaded" memcached > >> properly, if we now change our memcached server to "multi-threaded", > >> is this transparent to the client?
