That's correct, the server won't block. But it will stay in
conn_write state until TRANSMIT_COMPLETE, while next request may be
read only in conn_read state, so the client will block. The following
script shows this (though you may have to increase $count):
Yeah, I completely misunderstood
Separate on/off are 100% safe only when on/off itself has a reply,
hence the overhead.
Currently 'noreply' will still send the error if the command has wrong
number of tokens, and thus no attempt is made to parse it (though I
could parse it, I think that wouldn't be right). To help this
On Thu, Nov 15, 2007 at 22:32:24 +0300, Tomash Brechko wrote:
Currently 'noreply' will still send the error if the command has wrong
number of tokens, and thus no attempt is made to parse it (though I
could parse it, I think that wouldn't be right). To help this a bit
we may add a startup
On Thu, Nov 15, 2007 at 09:47:46 -0800, dormando wrote:
Sure, I guess it's a great way to OOM the machine (I'd be very impressed
if someone actually did this!) since iov bytes aren't presently limited
by anything, but it doesn't presently deadlock like you say it does.
Hmm, maybe I don't get
Hmm, maybe I don't get the code, but I think the server may switch
from conn_write to conn_read only on TRANSMIT_COMPLETE, i.e. it pushes
full responce before reading the next request. The test case could
tell, but lazy to write one.
I didn't map the whole thing out, but it'll just create a
You can implement streaming with select()/poll() magic, not using any
threads. All you have to do is to send commands and _simultaneously_
read the replies. But to implement this as a library, like Perl
module for instance, where there's one call per command, you'll have
to complicate the
On Thu, Nov 15, 2007 at 10:29:04 -0800, dormando wrote:
Hmm, maybe I don't get the code, but I think the server may switch
from conn_write to conn_read only on TRANSMIT_COMPLETE, i.e. it pushes
full responce before reading the next request. The test case could
tell, but lazy to write one.
Tomash Brechko wrote:
On Tue, Nov 13, 2007 at 17:52:31 -0800, Brian Aker wrote:
Is there a benchmark showing that the multi delete performs multi key
delete any faster then issuing single delete commands?
None that I know about ;). But you may experiment with mdelete.t in
the server,
There is no need for server or wire protocol changes to do multidelete. We
have a C client that does multiupdates and multideletes. Facebook's
SocialAds uses it heavily and was in fact the first use case for multiset
support.
[Getting this client open-sourced is on my list of things to do]
Hi!
On Nov 13, 2007, at 5:28 AM, Tomash Brechko wrote:
and Cache::Memcached::delete_multi() Perl binding. Both are analogous
to get and Cache::Memcached::get_multi(), their purpose is to delete
several keys in one command. There are both 'reply' and 'noreply'
versions.
Is there a
10 matches
Mail list logo
