debugging the server on OS X

Dave Roe david_roe at
Tue Nov 23 11:42:51 PST 2004

On Nov 22, 2004, at 10:57 PM, Brad Fitzpatrick wrote:

> I'd debug the server independently of the client.
> Telnet to the server and try doing:
> bradfitz at bini:~$ telnet localhost 11211
> <snip />
> And see what's slow.
> Maybe run memcached in the foreground with debugging on in one window, 
> and
> your telnet in anohter, and see where the delays are.
> If the server works, only then start using the client and debugging.

I ran "/usr/local/bin/memcached -p 11211 -m 64 -vv" in one window and 
"telnet localhost 11211" in another.

telnet connects at an expected speed, the incoming client connection is 
reported on the server immediately. I typed "set foo 0 0 3" and hit 
return and the server reports the incoming instruction immediately. I 
typed "bar" and hit return and the server reports "STORED" immediately, 
but there is a delay of a couple of seconds before "STORED" appears in 
telnet. I typed "get foo" and hit return and the server does its thing 
immediately, reporting "get foo, sending key foo, END", but again it 
takes a couple of seconds for the output to appear in telnet. The same 
thing happens if I type "stats".

So my guess so far is that it functionally works in this test, but that 
it takes too long to work and the Perl client fails because it only 
hangs around waiting for 1.0 seconds for a response. If the reason for 
the long delay can be found, the Perl client will work as expected. in 
fact, I added the arg select_timeout => 5.0 to my test and the set now 
no longer fails - it just takes a while to run.

Can you suggest where I should perhaps add further debug statements to 
the server code to try to find the delay?


More information about the memcached mailing list