HttpAsyncClient Configuration Help Requested

[Graeme Wallace <gr...@farecompare.com>]

Hi,

We just starting using the Http Async client package last month.

So far its worked out really great in our development lab - thanks for all
the work that's been put into it !

I had some questions about best practices around configuring up the package
for a production deployment.

We have a farm of machines that we use to make requests to airline and,
online travel agency APIs
One user search on our site may result in us having to make requests to 10
or more vendors to gather back different priced itineraries.

My thinking on this so far has been to use a ExecutorService to handle
a) building the HTTP request that is then delegated thru Async Http Client
b) process the response once it has been read

In order to do b), i have another ExecutorService that is dedicated to just
reading the
HttpResponse. So when the FutureCallback::completed method is called it
simply wraps
the HttpResponse in a Runnable and throws it to the ExecutorService. The
idea being
that the IOReactor threads would then be decoupled from having to process
the actually IO.

Does this make sense ?

One the content is read its thrown to the original ExecutorService for
final processing and the results
meander their way back to the user.

Assuming i haven't missed the mark.

What sizes should i make the IOReactor thread pool size, and my reading
response executor service  ?

What else should i be thinking about in terms of configuration ?

Apologies for such a long first post,



-- 
Graeme Wallace
CTO
FareCompare.com
O: 972 588 1414
M: 214 681 9018

Re: HttpAsyncClient Configuration Help Requested

[Oleg Kalnichevski <ol...@apache.org>]

On Tue, 2015-01-20 at 13:58 -0700, Graeme Wallace wrote:
> Hi,
> 
> We just starting using the Http Async client package last month.
> 
> So far its worked out really great in our development lab - thanks for all
> the work that's been put into it !
> 
> I had some questions about best practices around configuring up the package
> for a production deployment.
> 
> We have a farm of machines that we use to make requests to airline and,
> online travel agency APIs
> One user search on our site may result in us having to make requests to 10
> or more vendors to gather back different priced itineraries.
> 
> My thinking on this so far has been to use a ExecutorService to handle
> a) building the HTTP request that is then delegated thru Async Http Client
> b) process the response once it has been read
> 
> In order to do b), i have another ExecutorService that is dedicated to just
> reading the
> HttpResponse. So when the FutureCallback::completed method is called it
> simply wraps
> the HttpResponse in a Runnable and throws it to the ExecutorService. The
> idea being
> that the IOReactor threads would then be decoupled from having to process
> the actually IO.
> 
> Does this make sense ?
> 

Yes, it does. The downside of this approach is that content of HTTP
messages must be buffered in memory. 

> One the content is read its thrown to the original ExecutorService for
> final processing and the results
> meander their way back to the user.
> 
> Assuming i haven't missed the mark.
> 
> What sizes should i make the IOReactor thread pool size,

The number of CPU cores, which is default anyway. 

>  and my reading
> response executor service  ?

Hard to say. It probably really depends on how may concurrent response
messages the system must be able to handle.

Hope this helps

Oleg



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org