memcached server loses set command when followed by quit

Tomash Brechko tomash.brechko at gmail.com
Mon Jan 28 17:58:47 UTC 2008


On Mon, Jan 28, 2008 at 09:38:19 -0800, Kevin Dalley wrote:
> Right now, I think that the quit command should read the socket until
> EOF is received, perhaps sucking out a large number of responses to
> previous requests which will be ignored by the client.

Yep, the replies you haven't yet read may prevent the server from
processing following commands (because there's no room to write their
replies to, all outgoing buffers are full), so the client should
always read everything to effectively "push" all pending non-blocking
requests.

On a side note, I recently saw the benchmarks of upcoming
Cache::Memcached::LibMemcached module (it uses libmemcached).  It had
reported "more than a million requests per second" speed in
non-blocking mode, which looked just insane to me (C::M::F is much
slower in its nowait mode, I'm biased person :)).  However, it turned
out that at least for C::M::LibMemcached 0.000006 + libmemcached 0.13
_nothing_ is being sent to the server during the benchmark, hence such
great noop speed.  It still sent nothing when I tried to execute get
after a sequence of sets.  Maybe the patches that you mentioned would
fix this?..


-- 
   Tomash Brechko


More information about the memcached mailing list