On Fri, 2012-06-15 at 18:07 +0200, Joan Balaguero wrote: > Hello, > > Then having 1 pool is perfect. My proxy is a reverse proxy. All incoming > requests of these 20 webservices are load-balanced by our proxy to 15 > servers. So I only have 15 ips, because port is always 8080. All requests are > http (no https), no security credentials and no proxies in the middle of > communication. > > In this conditions I suppose that connections will be shared. Is it true? > > Anyway, I'll enable debug to check that. > > Thanks, > Joan. >
I believe so, but you should check nonetheless. Oleg > > -----Mensaje original----- > De: Oleg Kalnichevski [mailto:[email protected]] > Enviado el: viernes, 15 de junio de 2012 17:58 > Para: HttpClient User Discussion > Asunto: RE: Question about pools > > On Fri, 2012-06-15 at 17:52 +0200, Joan Balaguero wrote: > > Hello Oleg, > > > > Then, if I have one webservice pointing to http://ip1:port1/webservice1 and > > another one pointing to http://ip1:port1/webservice2, connections of ws1 > > can be shared with connections of ws2? > > > > Yes > > > What are the conditions for sharing 2 connections? Just the same ip and > > port? Or exactly the same url (end point)? > > > > They must have the same route (host, port, security guarantees, and > intermediate proxy hops). Path and query parts of the request URI make no > difference for connection pooling. > > Oleg > > > Thanks, > > > > Joan. > > > > -----Mensaje original----- > > De: Oleg Kalnichevski [mailto:[email protected]] Enviado el: viernes, > > 15 de junio de 2012 17:41 > > Para: HttpClient User Discussion > > Asunto: Re: Question about pools > > > > On Thu, 2012-06-14 at 13:08 +0200, Joan Balaguero wrote: > > > Hello, > > > > > > > > > > > > I have a servlet that acts as a http proxy. It manages 20 > > > webservices, and each webservice has its own Multithreaded pool. The > > > total number of concurrent connections is not higher than 2.000. > > > > > > > > > > > > I’m thinking to use just one pool for all 20 webservices. > > > > > > > > > > > > I’ve not made any tests yet, but what would be the advantages and > > > disadvantages of using just one pool? > > > > > > > > > > > > I suppose that I’ll earn resources (thread pools, etc) but this 2000 > > > requests, that now are shared among 20 pools, they’ll be served by > > > just one pool. Can I find any lock contentions or something that > > > makes this change not recommendable? Anyone using a pool with 2000 > > > (or more) concurrent requests? Or maybe I should try asyncHttpClient with > > > this level of requests. > > > > > > > > > > > > > Joan > > > > It really depends on several factors. Connections pools in HttpClient 4..x > > are protected with one global lock per pool. So, the larger the pool the > > more likely are chances of lock contention. However, as long as the number > > of worker threads is approximately the same as the max number of > > connections per route, the lock should get acquired and released reasonably > > fast. > > > > At the same time if all your web services are hosted on different hosts > > with distinct connection routes, connections cannot be shared between > > endpoints, so you might as well have separate pools of connections for each > > individual service. > > > > Oleg > > > > > > > > > Thanks, > > > > > > Joan. > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > ----- > > No se encontraron virus en este mensaje. > > Comprobado por AVG - www.avg.com > > Versión: 2012.0.2180 / Base de datos de virus: 2433/5070 - Fecha de > > publicación: 06/14/12 > > > > > > --------------------------------------------------------------------- > > 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] > > > ----- > No se encontraron virus en este mensaje. > Comprobado por AVG - www.avg.com > Versión: 2012.0.2180 / Base de datos de virus: 2433/5070 - Fecha de > publicación: 06/14/12 > > > --------------------------------------------------------------------- > 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]
