On 2007-11-08 01:41:07 -0800, Dustin Sallings wrote:
> On Nov 8, 2007, at 0:23, Tomash Brechko wrote:
> >>A get across a couple of thousand keys is a one line response in a
> >>case where none exist (or one message response in the binary
> >>protocol).
> >
> >I'd rather optimize for the "found" case.  Suppose your request has a
> >large number of keys, and only last one matches.  The client has to
> >wait till the very end (batch mode), while with pipelining it could
> >start the processing of not found entries right away.

Isn't that optimizing for the "not found" case? I think the current
design optimizes for the "found" case.


>       Ah, well in the general case, there's no processing to do for not  
> found keys.

I don't think that's true. If the key hasn't been found in memcached you
often need to look in the database (or whatever it is you are caching).
If you know of the cache misses earlier you can fire off the first
database requests while you are still receiving cache hits from
memcached. But I think this is possible with normal get requests, no
change to multiget required.

        hp


-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [EMAIL PROTECTED]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |    -- David Kastrup in comp.text.tex

Attachment: signature.asc
Description: Digital signature

Reply via email to