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/pipelining/index.html > > 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? >> >
