Performance when changing the length of a keys value. (It gets really bad.)

[Alex Stapleton]

Sorry to bring this up again, but I have corrected the errors in the  
tummy python client causing slowdowns, and am now experiencing my  
original problem again.

Write 1000 128KB values, Is fast.
Write 1000 1 byte values, Is *very* slow.

I don't think this can be a client issue as if I restart the  
memcached server, writing 1 byte values is fast if it's the first  
thing I do and I have to restart python and edit my script to change  
the data sizes.

Can someone else try and verify this please?

On 14 Jul 2005, at 11:02, Alex Stapleton wrote:

>
> On 14 Jul 2005, at 10:55, Ivan Krstic wrote:
>
>
>> Alex Stapleton wrote:
>>
>>
>>> OK, Here are my tests running the tummy3 fork. Summary: It's a lot
>>> better than the danga version.
>>>
>>>
>>
>> Brad made it clear on the list that he has no interest in maintaining
>> the Python client, and wants to withdraw the one that's on Danga's  
>> site,
>> linking to the tummy one instead. I thought this was done, but it  
>> turned
>> out not to be. Brad: is there any reason not to do this?
>>
>>
>>
>>> It takes a lot longer. Doing tests with smaller samples (like 10-50
>>> instead of 5000) it suggests that it gets >100 times slower when  
>>> your
>>> block size gets that large.
>>>
>>>
>>
>> Have you profiled your code? Can you pinpoint where time is being  
>> spent?
>>  This doesn't sound like a problem with the memcached server, and  
>> given
>> that Danga no longer maintains the Python client, you will  
>> probably have
>> better luck taking it up with the tummy folks, or a general Python
>> discussion list.
>>
>> -IK
>>
>>
>>
>
> I have patched the tummy3 fork into working with large block sizes  
> (it writes out large chunks of the string). So I am happy now. I  
> will contact the tummy maintainer about it. Thanks for putting up  
> with me.
>