On 06/07/2016 09:51 AM, Matt Chambers wrote:
There is actually a lot to gain performance wise, depending on how long the
call is going to take it can be 1 or 2 orders of magnitude faster to use thread
local connections. Linux also tends to get angry if you have thousands of
processes opening sockets at a high rate.
I use boost thread local on the client side, this is pretty much all you need
to do:
PlowClient* getClient()
{
static boost::thread_specific_ptr<PlowClient> instance;
if(!instance.get())
{
instance.reset(new PlowClient);
}
return instance.get();
}
Then I just have a macro I use everywhere.
#define PLOW_SERVICE plow::v1::getClient()->getService()
For Java, its slightly more complex but I can post an example later.
-Matt
For sure, I didn't mean to suggest that it wouldn't be useful or have
anything to gain... I imagine that pooling will definitely reduce the
number of object allocations and the frequency of garbage collection. I
just meant that if you look at the implementation of THttpClient in
Java, there's a good chance you'll be establishing a new connection per
request unless you intentionally take steps to configure it otherwise,
which probably would also significant overhead. I also didn't mean to
suggest that the client, protocol, and transport objects are thread
safe; they are not, so creating new instances or using
ThreadLocal/pooling is necessary.
