Extensible command syntax

[Tomash Brechko]

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