Extensible command syntax

[Dustin Sallings]

On Nov 8, 2007, at 2:35, Tomash Brechko wrote:

>> 	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.

	In the binary protocol, you do only use numbers (keys aren't  
returned).  In the text protocol, you do string compares on the  
results.  In both cases I use a hash table.  If it ever bubbles up in  
my profiler, I might try to make it more efficient, but in the  
meantime, it doesn't seem to matter much.

> 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.

	If you optimize the server at the cost of additional work on the  
clients, you're optimizing the more centralized resource at the cost  
of the less centralized resource.  The server absolutely has to be the  
most optimal part of the whole thing for this very reason.

	That's not to say the optimization of other components should be  
ignored, but I have not found any dissatisfaction in my ability to  
optimize things with the existing protocol.

>> 	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.

	Does any client out there do a multi-get for a series of keys and not  
return values mapped to those keys?

>> 	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].


	I don't see that as a drawback.  If you actually had different  
priorities for different request types and determined that you were  
actually running into a blocking condition as such that caused a  
latency problem, you could just use different client instances and  
it'd go away immediately.  Alternatively, if anyone cared, I could  
implement a priority concept for requests.

	It had been suggested that I allow multiple connections per  
destination per client to reduce latency.  I experimented with a  
branch doing that, but I wasn't able to measure a difference (I think  
you need more computers than I have available for such a test).

	Whichever way you look at it, it's only a drawback to the single IO  
thread approach if you can demonstrate that my IO thread is somehow  
limiting the throughput.

	It seems like memcached has historically been single threaded for  
most installations, and as far as I can tell, when it's multithreaded  
it's not because one thread can't keep IO buffers full.

-- 
Dustin Sallings