setMulti implementation for Java client?

[Greg Whalin]

Kevin Burton wrote:
> Greg Whalin wrote:
> 
>> Kevin Burton wrote:
>>
>>> About a month ago  I benchmarked the Java client implementation.
>>>
>>> I noticed that using 1 getMulti instead of 1000 individual gets 
>>> yielded a BIG performance improvement (which of course makes a lot of 
>>> sense).
>>>
>>> The problem is that in my cache implementation I needed to do a lot 
>>> of individual sets and since there was no setMulti implementation I 
>>> was actually seeing that my memcached implementation was 8x slower 
>>> than my native mysql only implementation.
>>>
>>> I'm trying to build a cache for our Torque OM layer (which has since 
>>> been tricked out and I'd like to OSS some day) where our objects 
>>> would be kept in memcached but with the current individual put 
>>> implementation it was about 8x SLOWER ...
>>>
>>> Anyway.. If there aren't any plans for this I might end up 
>>> implementing it.
>>>
>>> Kevin
>>>
>>
>> Are you saying you want a multi-key set in the API?  Or are you saying 
>> you want the java client to support a setMulti method, which will 
>> stream the sets across in one session?  The 2nd one would be simple to 
>> add and should give a performance boost assuming the slowdown is in 
>> getting a connection from the pool.
>>
> I want this in the Java client.... basically the same way its doing with 
> getMulti...  The protocol has no getMulti support but in the client its 
> provided by multiple get and then parse.
> 
> Doing the same thing with set would improve performance significantly.
> 
> Kevin
> 

The protocol DOES indeed have getMulti support, which the java client 
uses when you call its getMulti() method.

get key1 key2 key3 key4

as opposed to

get key1
get key2
get key3

Very different things.

Greg