debugging the server on OS X
Dave Roe
david_roe at mac.com
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?
/dave
More information about the memcached
mailing list