Trond Norbye's Weblog

noreply support in libmemcached - part two

In my previous post I described the implementation of noreply support in libmemcached, but Brian Aker commented that we should buffer the noreply packets as well to avoid sending a lot of packets over the wire.

Earlier today I pushed a patch that introduce a new function: memcached_return memcached_flush_buffers(memcached_st *).

So what does this mean for you as a developer? If we look at the following example:

  memcached_behavior_set(memc, MEMCACHED_BEHAVIOR_BUFFER_REQUESTS, 1);
  memcached_behavior_set(memc, MEMCACHED_BEHAVIOR_NOREPLY, 1);
  for (int x= 0; x < 100; ++x) {
    char key[10];
    size_t len= sprintf(key, "%d", x);
    memcached_response ret;
    ret= memcached_set(memc, key, len, key, len, 0, 0);
    if (ret != MEMCACHED_SUCCESS && ret != MEMCACHED_BUFFERED)
      abort();
  }
  [ ... Perform application logic ... ]
  
  char* value= memcached_get(memc, key, strlen(key),
                             &value_length, &flags, &rc);

Without the patch I added today, libmemcached would send out the command to the server for each invocation of memcached_set. With the the patch I added today, all of the commands would be sent to the server in chunks when the user calls memcached_get. Now this doesn't buy us much from what we had before I added the noreply support (just that we don't have to parse the reply codes from the server). Well, lets talk about the new function I added today: memcached_flush_buffers. Let's look at some source:

  memcached_behavior_set(memc, MEMCACHED_BEHAVIOR_BUFFER_REQUESTS, 1);
  memcached_behavior_set(memc, MEMCACHED_BEHAVIOR_NOREPLY, 1);
  for (int x= 0; x < 100; ++x) {
    char key[10];
    size_t len= sprintf(key, "%d", x);
    memcached_response ret;
    ret= memcached_set(memc, key, len, key, len, 0, 0);
    if (ret != MEMCACHED_SUCCESS && ret != MEMCACHED_BUFFERED)
      abort();
  }
  
  if (memcached_flush_buffers(memc) != MEMCACHED_SUCCESS)
    abort();
  

  [ ... Perform application logic ... ]
  
  char* value= memcached_get(memc, key, strlen(key),
                             &value_length, &flags, &rc);

Now memcached_flush_buffers will send all of the commands in the buffers to the memcached servers, so that the memcached server may start executing them. This means that the memcached server may start processing the commands while we perform application logic. When we invoke memcached_get the memcached server may already be finish executing the commands in the buffer, and process the get request immediately.

Posted at 12:00PM Jan 21, 2009 by trond in Memcached  |  Comments[0]

noreply support in libmemcached

The memcached textual protocol allows you to execute commands on the memcached server without sending the result back to you. Why would you want to do this? One case could be that you just want to store the item in the cache, and you don't really care if it is successful or not. Up until today you had two modes you could use to insert items in the cache: synchronous (default) and asynchronous.

If we look at the following code snippet:

  for (int x= 0; x < 100; ++x) {
    char key[10];
    size_t len= sprintf(key, "%d", x);
    if (memcached_set(memc, key, len, key, len, 0, 0) != MEMCACHED_SUCCESS)
      abort();
  }
  memcached_quit(memc);

During the execution of the above loop, libmemcached will send the set command to the server and wait for the response from the server before it sends the next command to the server etc. This is not very efficient, so you may use the asynchronous mode to queue up commands. To do that, we modify the code:

  memcached_behavior_set(memc, MEMCACHED_BEHAVIOR_BUFFER_REQUESTS, 1);
  for (int x= 0; x < 100; ++x) {
    char key[10];
    size_t len= sprintf(key, "%d", x);
    memcached_response ret;
    ret= memcached_set(memc, key, len, key, len, 0, 0);
    if (ret != MEMCACHED_SUCCESS && ret != MEMCACHED_BUFFERED)
      abort();
  }
  memcached_quit(memc);

With this modification, libmemcached will buffer multiple requests to the server and send them to the server when the buffer exceeds a configurable threshold.

Now this sounds pretty neat doesn't it? Well it is one problem with the model, and that is if we try to issue a get command. The problem now is that we need to flush the send buffer and let the server execute all of the commands in the send buffer before we can send the get request. If we are lucky the buffer is empty (or just contain a few commands), but it could potentially contain a lot of set commands and the memcached server could use some time processing all of those commands.

To solve this problem I implemented use of the noreply command (If you are interested in the glory details, take a look at the patch). So let me modify the source code once more:

  memcached_behavior_set(memc, MEMCACHED_BEHAVIOR_BUFFER_REQUESTS, 1);
  memcached_behavior_set(memc, MEMCACHED_BEHAVIOR_NOREPLY, 1);
  for (int x= 0; x < 100; ++x) {
    char key[10];
    size_t len= sprintf(key, "%d", x);
    memcached_response ret;
    ret= memcached_set(memc, key, len, key, len, 0, 0);
    if (ret != MEMCACHED_SUCCESS && ret != MEMCACHED_BUFFERED)
      abort();
  }
  memcached_quit(memc);

With this modification libmemcached will send the command to the memcached server immediately, but it also tells the server that it doesn't want a reply from the server so it doesn't wait for a response before it sends the next command. When I implemented this patch I noticed that the binary protocol didn't have support for all of the "noreply" variants of the commands, so I filed a bug report on memcached (and implemented it as well ;-)).

Posted at 06:46PM Jan 20, 2009 by trond in Memcached  |  Comments[1]

Trondheim OpenSolaris User Group

Det er med stor glede jeg kan fortelle at vi har startet opp Trondheim OpenSolaris User Group (TrOSUG). Vi (Knut Anders, Jan Ståle og meg selv) har noen tanker om hva vi vil oppnå med brukergruppen, men vi er veldig interessert i å høre hva du er interessert i. (Jan Ståle skrev en intro-mail til gruppen med noen forslag).

Posted at 12:39PM Jan 18, 2009 by trond in OpenSolaris  |  Comments[0]

DTrace probes in libmemcached on Mac OSX?

I have just pushed a patch to libmemcached that allows you to build libmemcached with the static DTrace probes. Please note that I haven't had the time yet to look at probes it contains (and if they are useful), but I am going to look into that :-)

So why don't you just go ahead and grab the latest source and try it out?

trond@mac > hg clone http://hg.tangent.org/libmemcached
trond@mac > cd libmemcached
trond@mac > ./config/bootstrap && ./configure --enable-dtrace --enable-64bit

Posted at 11:18PM Jan 07, 2009 by trond in Memcached  |  Comments[0]