Performance when changing the length of a keys value. (It gets
alexs at advfn.com
Fri Jul 15 09:45:15 PDT 2005
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
>> linking to the tummy one instead. I thought this was done, but it
>> 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
>>> block size gets that large.
>> Have you profiled your code? Can you pinpoint where time is being
>> This doesn't sound like a problem with the memcached server, and
>> 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.
> 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.
More information about the memcached