On Thu, Nov 08, 2007 at 01:41:07 -0800, Dustin Sallings wrote: > I didn't say it was more flexible. I was just saying it's flexible > enough. > > It would make sense to have a separate command for updating the > flags or expiration of a record if that is really of interest.
Right. Fixed scheme may be faster, but when you have to issue several commands to get interesting results, this cancels all fixed advantages. Again, I'm not arguing against fixed commands for frequent use, I vote for flexible commands for infrequent use. > The strong desire to keep the commands small and orthogonal was > expressed at the first meeting where we were going over binary protocol. Orthogonal is the right word. Being forced to set exptime and flags when all I need is to update the data doesn't look like orthogonal to me. > I fail to see what I'm missing. As far as I can tell, you're > describing what I already do. See my write up on client optimization > and let me know what I'm missing. > > http://bleu.west.spy.net/~dustin/projects/memcached/optimization.html According to this page, when several threads issue [a], [b], [a, b, c], [a], [d], you combine this requests into the one, [a, b, c, d]. Alright, suppose you got the reply, [c, d]. How do you know what to reply to each thread? You have to compare keys in client side to know what results you have got. But if the reply was [nil, nil, c, d], you'll have to compare only numbers: first goes to t1, t3, t4, second goes to t2. t3, etc. What matters is _overall_ throughput, not solely server performance. If you optimize the server at the cost of additional work on all clients, it's not good. Note that sending NACK is not a big deal, as we do not say that each NACK should go into a separate network packet. You could even combine NACK ranges, like TCP does, this still would require less processing on client side than matching strings. > In the text protocol, a get with several keys only returns hits and > an end marker. The idea is that if you're issuing that request, > you're probably going to return some kind of dictionary structure to > something. This "probably" comes from no where, and is a bad assumption for the generic design. Client might not need to have the dictionary, and currently it is forced to have it. > Ah, well in the general case, there's no processing to do for not > found keys. As follows from your page, t1 that has requested [a] would have to wait until [d] is processed, while it could continue once [nil] for [a] has been returned. On the page you should also describe the drawbacks of single I/O-thread approach: that threads effectively block each other. For instance, high-priority t5 asking for small data for [d] would be blocked by low-priority t1 asking for large data for [a]. Anyways I think this discussion is a somewhat pointless at least until someone would explain how Brian's problem might be fixed with current protocol, or acknowledge that there's no way for that. -- Tomash Brechko
