memcached for win32, new java api
gwhalin at meetup.com
Tue Nov 30 10:34:06 PST 2004
Gregory Block wrote:
> On 29 Nov 2004, at 23:12, Greg Whalin wrote:
>> Here I am confused? We don't make any assumption about this running
>> in a single thread. Since we are pulling all sockets from a pool,
>> this method should be as easily parallelized as any other method in
>> the client. Are you saying you have found a case where our client is
>> not thread safe? If so, please, by all means let me know. I can say
>> that we run the client in a pretty heavily parallelized environment
>> with a single instance and have had no problems, but tracking
>> threading bugs can always be a bit tricky, so if you know something we
>> don't, share the love. :)
> Now I'm going to have to go back and review that assumption. :) I was
> sure it was one of those situations where using getMulti() could use up
> all available connections, but now that I'm sitting here thinking about
> it, that doesn't make a whole lot of sense, as you're right, the pool
> should go ahead and create additional connections for others.
> Could have been.. Actually, am totally wrong on this. Thanks for the
> heads up. :) You're right.
Good good! Scared me a bit thinking we had some thread safety issue
that we had not noticed. I did not think this to be the case, but never
hurts to have outside verification.
>> A nice thing about using a connection pool and a parallelized
>> environment, is that there is much less of a benefit to using
>> getMulti() (you save a bit in network bandwidth at the cost of more
>> parallelization). This is of course, assuming no optimizations on the
>> server side to using getMulti(), which I honestly have to profess my
>> ignorance. Anyhoo, this is a bit off topic.
> Totally. There should be a minor benefit to getMulti(), at least in the
> previous implementation, as it should push all of the requests onto the
> network before retrieval; assuming multiple servers are in use,
> getMulti() should reduce request latency.
> (On the other hand, when you know some entries won't have contents in
> cache, you then have to do a bunch of processing to figure out which
> bits did and didn't have answers, and fetch real objects for the keys
> which returned no data from cache when requested. The only good way
> I've found of doing that is to go with a key->id map, retrieve the
> key->value map via getMulti(), step through it looking for missing data,
> and look up the information you needed on the way in via the key->id map
> to construct; and at the moment, that's single-threaded (though I'm
> about to take a whack at JOMPing that code, methinks.)
I personally am not sure this belongs in the realm of responsibility of
the client. I would say this is the duties of the calling code to
parrallelize the checking/repopulating of the data. But yes, I agree,
this is a potential slow area.
>> Again, we only ever have one instance of the client, which uses a pool
>> of sockets. If you are only ever gonna have one connection open to
>> the server, then a pool of clients should work as well.
> You're dead to rights on this. I can now see no point in not switching
> away from our current pooled-client implementation (unless there are
> performance issues related to synchronization, which I gather from your
> usage is unlikely).
Yeah, only synchronized code is in the pool when getting a new
connection. Should not be a big slowdown IMO.
More information about the memcached