[PATCH 1/6] Allow running tests in a build directory different from source directory.

Tomash Brechko tomash.brechko at gmail.com
Thu Nov 8 18:39:37 UTC 2007


On Thu, Nov 08, 2007 at 09:52:48 -0800, dormando wrote:
> I assume this is the final patch series?

Yes.


> If no one merges these by tomorrow evening, I'll be testing them and 
> start merging some now. promise :)

In the protocol.txt, I put description of "noreply" to the wrong
place, I trust you to fix this (with the patch below ;)).


> Can't personally test 'noreply' speed on any of the sites here, so 
> someone will have to do a synthetic benchmark to test. I don't see 
> reason to exclude the last patch series if it doesn't break in testing 
> though...

I can't test it on real-world project either.  But if we accept
artificial micro benchmark, then for 500,000 iterations the loop from
04_noreply.t

  my $res;
  for (my $i = 0; $i < count; ++$i) {
      $res = $memd->set("key", $i);
  }

(i.e. when result is "used") takes on my machine

  Files=4, Tests=53, 88 wallclock secs (52.87 cusr + 19.80 csys = 72.67 CPU)

And

  for (my $i = 0; $i < count; ++$i) {
      $memd->set("key", $i);
  }

(i.e. void context) takes

  Files=4, Tests=53, 55 wallclock secs (43.00 cusr + 11.79 csys = 54.79 CPU)


This is for loopback interface.  I was getting even a bigger
difference when using simple

  print $sock "set noreply:foo 0 0 1 noreply\r\n2\r\n";

in a loop.

However for real-world project it would require lots of updates to see
the difference.


Tomash



diff --git a/trunk/server/doc/protocol.txt b/trunk/server/doc/protocol.txt
index 14cd1e3..6defa9f 100644
--- a/trunk/server/doc/protocol.txt
+++ b/trunk/server/doc/protocol.txt
@@ -129,7 +129,7 @@ First, the client sends a command line which looks like this:
 <command name> <key> <flags> <exptime> <bytes> [noreply]\r\n
 cas <key> <flags> <exptime> <bytes> <cas unqiue> [noreply]\r\n
 
-- <command name> is "set", "add", "replace", "append", "prepend", or "cas"
+- <command name> is "set", "add", "replace", "append" or "prepend"
 
   "set" means "store this data".  
 
@@ -146,9 +146,6 @@ cas <key> <flags> <exptime> <bytes> <cas unqiue> [noreply]\r\n
   "cas" is a check and set operation which means "store this data but
   only if no one else has updated since I last fetched it."
 
-  "noreply" optional parameter instructs the server to not send the
-  reply.
-
 - <key> is the key under which the client asks to store the data
 
 - <flags> is an arbitrary 16-bit unsigned integer (written out in
@@ -174,6 +171,9 @@ cas <key> <flags> <exptime> <bytes> <cas unqiue> [noreply]\r\n
   Clients should use the value returned from the "gets" command
   when issuing "cas" updates.
 
+- "noreply" optional parameter instructs the server to not send the
+  reply.
+
 After this line, the client sends the data block:
 
 <data block>\r\n


-- 
   Tomash Brechko


More information about the memcached mailing list