'noreply' over the wire
tomash.brechko at gmail.com
Sun Nov 11 09:22:20 UTC 2007
On Sat, Nov 10, 2007 at 11:15:29 -0800, Steven Grimm wrote:
> Your application never streams requests to memcached, does it? If you
> don't do that, any performance impact of replies coming over the wire
> are pretty much overwhelmed by network latency. And if you *do* stream
> requests, then your noreply proposal (which as I understand it is more
> of a "sometimesreply" option) is 100% useless because it will be
> impossible for a client to know which errors / responses go with which
What do you mean by streaming? How this can be done from
Cache::Memcached? Have you actually read my mail where I talk why
errors may be ignored for some applications? What errors are you
expecting form, say, 'delete'?
> In real-world clients, "get" requests are the vast, vast majority of
> requests -- over 99% in our case, and I don't imagine we're unusual in
> that respect -- and as you point out, you always need a reply to
Your notion of real-world is limited to your own projects. There are
applications where updates are no less frequent then queries. Yes,
'noreply' won't help your project if your estimate of 99-1 is correct.
But if it may help _other_ projects, and will not affect performance
of get-intensive projects like yours, will you allow the patches in?
> Making the parser code quite a bit more complicated to optimize
> for less than 1% of requests is, IMO, not a smart move, especially
> when the remaining <1% are not causing any trouble anyway. If you can
> make "get" faster (than the binary protocol under development, which
> will be the preferred choice for performance-sensitive applications)
> then I'm sure people will be all ears.
Binary protocol is there for someone, while text protocol is here for
everyone. Of course binary protocol won't be that great if we also
improve text protocol ;) (being binary is not any magic, everything is
binary in a sense). But can you provide the measurements that my
"complication of parser" actually affects performance? Because if it
really does, I'll spend some more days and show using the test case
you provide that GPerf will solve the issue (and actually squeeze more
bits of performance). Or I can hand-craft the parser as the last
resort. Current cascade of strcmp() has a room for improvement.
> It seems to me that this is a solution searching for a plausible
> problem to justify itself, not a response to an existing problem that
> needed to be solved. Maybe I'm wrong about that, though. What real-
> world problem were you having with memcached that this set of patches
> addresses? I would strongly oppose integrating this into the main
> source base unless there's a good answer to that question.
Well, all I actually heard thus far were airily arguments in the
spirit "I don't need this so why anyone would need this?". I don't
actually think I have to prove anything to anyone. And I can't add
anything to what I already said.
For a development list, posting patches is alright, so I didn't do any
harm :). If someone would find them useful, that would be great. If
they won't go to the mainline, so be it, perhaps they are not that
More information about the memcached