Hey,
No actually... in -t 1 mode the only producer/consumer is between the
accept thread and the worker thread. Once a connection is open the socket
events are local to the thread. Persistent connections would remove almost
all of the overhead aside from the futexes existing.
There's also work we
I agree that if you have futexes on your platform and you don't contend
(i.e. don't even have to call into the kernel) the overhead is small(er),
however, there is also the overhead between the producer-consumer contexts,
namely the event base and the `-t 1' thread (again, unless I misread the
code
We took it out for a reason, + if you run with -t 1 you won't really see
contention. 'Cuz it's running single threaded and using futexes under
linux. Those don't have much of a performance hit until you do contend.
I know some paper just came out which showed people using multiple
memcached instan
The current memcached-1.4.5 version I downloaded appears to always be
built with multithreaded support (unless something subtle is happening
during configure that I haven't noticed). Would it be OK if I
submitted a patch that allows a single-threaded memcached build? Here
is the rationale: instead
