thanks, todd and toru's words give me insight from todd, does that mean the mencached's "internal logic" is single- threaded, but the "network/socket" (sending, receiving data) are "multi-threaded" ? (sorry, the question may be silly, but i want to have a bit more detail)
and if memcached is enabled for "multi-threaded" (no matter it is 1.2.6 or future 1.3), this will not require the change of client? On 10月15日, 上午4時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?
