The Speed of memcached
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
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.
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
> >>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