On Mon, 2012-06-18 at 08:01 -0400, Jason Weden wrote: > Thanks for the response. Why would you recommend "fewer than 500" concurrent > connections for httpclient. I assume you are talking about high use of > resources when not using an asynchronous execution framework such as mine, > correct? > > Thanks, > > Jason >
Hi Jason 500 concurrent connections would also imply 500 worker threads which is quite a high number especially if all these threads are not constantly busy pumping data. Modern operating systems and JVMs are quite efficient at context switching. 500 worker threads with blocking connections are quite likely to outperform the equal number of selector based non-blocking connections. Beyond that number, however, other factors such CPU utilization may also need to be taken into consideration. Hope this helps Oleg > ----- Original Message ----- > From: Oleg Kalnichevski > Sent: 06/17/12 10:07 AM > To: HttpComponents Project > Subject: Re: Akka + httpclient vs httpasyncclient > > On Sun, 2012-06-17 at 09:16 -0400, Jason Weden wrote: > This week I had the > pleasure of wrapping my httpclient.execute() call of httpcomponents > httpclient in an akka future. I'm no expert but I think with this and the > oncomplete() callback, I made the sending of http requests and receiving of > the replies both asynchronous and non-blocking. (I'm using the > threadedclientconnmanager and hope to upgrade to poolingconmanager when I > move to version 4.2.) > > My question is why not pose this as a solution > rather than build httpasyncclient? Httpasyncclient doesn't appear to use akka > and so you don't get all the benefits and performance of akka. I am very > curious therefore to understand the benefits and drawbacks of my solution vs > that of httpasyncclient architecture. Thanks in advance and Happy Fathers Day > to the fathers on this list. > > Regards, > > Jason Weden Hi Jason A blocking > HTTP client used in conjunction with an asynchronous execution framework such > as Akka is a very reasonable ap > proach for a lot of applications. However, there are several special types > of applications (such as HTTP proxies and gateway) that often have to > maintain several thousand outgoing HTTP connections most of which stay idle > most of the time. In such a case the cost of context switching of several > thousand threads blocked in an I/O operation can become prohibitive. > Basically, HttpClient is a general purpose HTTP agent well suited for the > majority of applications where the total number of concurrent connections > remains relatively low (fewer than 500). HttpAsyncClient is a special purpose > HTTP agent primarily intended for HTTP proxies and HTTP gateways that need to > maintain over 2000 concurrent connections that stay idle most of the time. > Hope this helps somewhat. Oleg PS: Happy Fathers Day! > --------------------------------------------------------------------- To > unsubscribe, e-mail: [email protected] For additional commands, > e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
