On May 9, 2008, at 4:54, Henrik Schröder wrote:
Out of pure curiosity, have you benchmarked the difference between your single-connection client and a comparable multi-connection one with a connection pool?
I've done various small benchmarks and profiling, but I've not done massively large-scale testing. I don't have a lot of computer hardware to throw at a test cluster at the moment.
I've been planning on building some test plans against EC2, but other than availability zones, I don't have much control over the network, so it might be able to show me when something is bad, but I don't expect it to show me when something is good.
And have I understood it correctly that the reason your version is as fast as or faster than a multi-connection one because memcached in itself is single-threaded and will process requests in a serialized fashion anyway?
That was the initial idea, yeah. I had a branch a while back that would run over multiple connections, but I didn't notice much of a difference -- again within the hardware I had available at the time.
What I have seen is that the IO thread can saturate a CPU well before it saturates the network interface. There are a couple of reasons for this, the biggest being that decompression and deserialization are both processed as part of the IO thread. I'm hoping to find a good solution to this problem first (one that doesn't require me to reimplement HashMap anyway, although it may come down to that).
So the next thing is to fire up multiple IO threads. Some users do this already by just having more than one client instance. While this isn't a particularly terrible hack, I'm hoping that I can make something a bit more convenient here.
-- Dustin Sallings
