[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