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
Comment #4 on issue 105 by asankalakmal: curr_items stats seem wrong
http://code.google.com/p/memcached/issues/detail?id=105
(No comment was entered for this change.)
Attachments:
plant4.jpg 206 KB
Hey,
A common issue folks have are when clients give inexplicable timeout
errors. You ask the client "what were you doing? why do you hate me so?"
but it won't answer you.
http://code.google.com/p/memcached/wiki/Timeouts
I wrote a little utility while helping a friend diagnose similar issues.
So
