The Speed of memcached

Brad Fitzpatrick brad at danga.com
Wed Oct 12 13:16:10 PDT 2005


Yes, you'll want to use TCP_NODELAY, disabling the Nagel algorithm.

Otherwise you can cork/uncork (push/nopush on BSD) which immediately
sends, but makes little sense in such a protocol as memcached without lots
of data.

Or I believe (?) you can just send(), which never does Nagel, at least on
Linux, which is iirc why the Perl client doesn't have NODELAY in it.

- Brad



On Wed, 12 Oct 2005, Peter Alberer wrote:

> hm, no i cannot set that option from tcl for the socket as far as i know
> :(
> do you mean i should try to use it or not?
>  i have not seen that perl or phyton clients use TCP_NODELAY...
>
> >If you rolled your own client, are you doing TCP_NODELAY?  That tends to
> >be the first thing to bite people.
> >
> >
> >On Wed, 12 Oct 2005, Peter Alberer wrote:
> >
> >
> >
> >>Hi there,
> >>
> >>i have created a simple tcl-based client api to memcached for use in the
> >>aolserver webserver. after the completion of the client api, my first
> >>tests showed
> >>that the memcached server is quite slow when saving values, compared to
> >>my database (postgresql 8.0). i would like to mention, that i only open
> >>the communication sockets once for all the
> >>operations and cache it in the api.
> >>
> >>i created a test-loop that saves 100 different keys (test1-100) with the
> >>same value (value length is about 1000 characters) to 2 different
> >>memcached servers (50 each),
> >>rereads all of the values and deletes all of them afterwards. (no multi
> >>get, just 100 single get commands)
> >>
> >>Here are the results measured in ms:
> >>
> >>Memcache SET: Processed 100 items in 4060 ms
> >>
> >>Memcache GET: Processed 100 items in 438 ms
> >>
> >>Memcache DELETE: Processed 100 items in 82 ms
> >>
> >>The set command is quite slow, compared to the get and delete command.
> >>are the numbers i am getting here reasonable? interestingly,
> >>the VERY FIRST set command completes in 0-1 ms, but ALL of the
> >>subsequent ones take 40-41ms. this is something i can even see when i
> >>manually
> >>set keys via telnet. the first set command returns STORED immediately,
> >>but after that a very small delay is visible for every set command.
> >>changing the length of the value
> >>does not  affect the 40ms for storing the value, just the get operation
> >>gets faster.
> >>
> >>have others measured the performance of the different memcached operations?
> >>
> >>i would be very glad to hear about your observations!
> >>
> >>TIA, peter
> >>
> >>ps: the system where the memcached daemon is running is a power5-redhat
> >>AS4 server. kernel=2.6.9-11.EL
> >>
> >>
> >>
> >>
>
>


More information about the memcached mailing list