On Feb 1, 9:38 am, Tomash Brechko <tomash.brec...@gmail.com> wrote:
> throw it away. But once the result is being thrown away, why send it > in the first place? This also hurts streaming greatly, as as of now > memcached pushes every "STORED" reply in a separate network packet... I agree with this -- if there's a way to assume things are stored, that's better since that's what's going to happen most of the time. > noreply is not everything for everyone, if you can't sleep knowing > that there's something that it not properly logged in your system yet, > then you better not using it. But logging aside, what your app does > when it receives "NOT STORED" from set? I'm not saying that you never > need a result from set, but I really wonder what real-world cases > might be, couldn't think of any myself. In my client, you never have to check the result of a set, but you can when you want to know. So let's consider that I can now create a multi-set command that complements the multi-get that we have right now. I can send many sets with the expectation that they will all succeed -- and they most certainly will almost all the time -- and be able to communicate to callers whether they were all successful, or which individual ones failed. That's not to say that there's no case at all for a "doubly-quiet" command, but I think the bulk of the savings are in suppressing the positive case and letting client authors decide what to do with the presumably rare failures. I suppose if someone has a real case where they are pushing out so many set failures that dropping the errors shows a significant performance gain, a SETQQ command can be added, but I'm really doubtful that such a case exists.
