Maybe anyone knows what are the optimal values for connections per host and total connectons ? Any idea or performance test ? :)
On 11/6/06, Tomek Sztelak <[EMAIL PROTECTED]> wrote:
On 11/6/06, Andres Bernasconi <[EMAIL PROTECTED]> wrote: > I'm glad to see this threa got good attention. > > Tomek: I am not directly usgin XFire's API, so I can't really do that unless > it is configurable through Spring, which I believe it is not, or at least do > not know how to do it. > > Also as a suggestion, I would set the number of connections per host equal > to the maximum total number of connections. And I would put those to the > number of "execute threads" on the application server. In the worst case, > you might have all threads calling we b services, and you do not want to be > delayed just because you did not asigned enough connections. > So setting max conns to the double of conns per host really makes no sense > to me: your conns per host will be the bottleneck. (worst-case scenario, > which usually happens in Production :P ) > > If you want, Tomek I can post more info on how I solved the issue, but it is > not a very clean solution since I'm coupled with XFire's inner workings. If you can, post here or attach to jira isse piece of code with httpclient config. If i will find some time, i'll try to fix this today. > Regards > Andrés Bernasconi > > > On 11/5/06, Hodges, Chris <[EMAIL PROTECTED]> wrote: > > I am new to XFire and I am having a similar problem. After reading this > conversation I went back to my code and tried creating my own HttpClient but > I am still getting a maximum of two Threads. Am I doing something wrong? > > > > Object webServiceClient = new > XFireProxyFactory().create(myService, myUrl); > > > > Client client = Client.getInstance(webServiceClient); > > > > MultiThreadedHttpConnectionManager manager = new > MultiThreadedHttpConnectionManager(); > > HttpConnectionManagerParams myParams = new HttpConnectionManagerParams(); > > myParams.setDefaultMaxConnectionsPerHost(25); > > myParams.setMaxTotalConnections(50); > > manager.setParams(myParams); > > HttpClient myHTTPClient = new HttpClient(manager); > > client.setProperty(CommonsHttpMessageSender.HTTP_CLIENT, > myHTTPClient); > > > > -----Original Message----- > > From: Tomek Sztelak [mailto:[EMAIL PROTECTED] > > Sent: Saturday, November 04, 2006 4:52 AM > > To: [email protected] > > Subject: Re: [xfire-user] Re: Urgent! How to change Maximum Number of > connections for HTTPClient through XFire > > > > You can create you own HttpClient, configure it as you want and set on > > client with client.setProperty(CommonsHttpMessageSender. HTTP_CLIENT, > > myHTTPClient ) > > > > On 11/4/06, Andres Bernasconi <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi guys,After a lot (LOT) of using XFire I recently realized that > there was a > > > problem with multiple threads running at the same time. My application > is > > > heavily WebService oriented, and all of my request will involve at LEAST > one web > > > service call. Also, most of those request will use the SAME web service > at a > > > certain point, thus I need to be able to query a single web service with > > > multiple threads at the same time. > > > > Strangely enough I noticed that I was only receving --TOPS-- two > requests at a > > > time when using an XFire client( I'm using XFire-1.1.2, with Spring and > aegis) > > > but I could get more throughput with another client (say SoapUI). > > > > Looking around I found out that the HttpClient library has by default > a value > > > of DEFAULT_MAX_HOST_CONNECTIONS set to two (2) by default, so I guess > this is > > > what is causing troubles.I am currently looking for a solution because > there is > > > NO WAY I can move into production with a max of 2 concurrent threads > running. > > > > Still I wanted to see if any of you could help me solve this problem > faster, > > > since even I can find out how to change that property on HttpClient, I > have no > > > direct access to it.Please any comments are more than welcome. > > > > Best Regards,Andrés Bernasconi > > > > > > > > > Ohhhhhhhhhh my...holy cow..... > > > > > > I've found that this is configured through the > > > MultiThreadedHttpConnectionManager class, using it's > own > > > HttpConnectionManagerParams class... I'm very afraid that > > > this is buried inside the guts of xfire-core, inside > > > CommonsHttpMessageSender, open() method, (line 73 in 1.1.2). > > > > > > I don't know if this has changed in newer versions, but the thing > > > is that the MultiThreadedHttpConnectionManager is > instantiated like > > > this: > > > client.setHttpConnectionManager(new > MultiThreadedHttpConnectionManager()); > > > > > > so I guess there is no "configuration" way of modifying this through > > > spring, right? > > > > > > This seems the only way to do it right now, and will have very > > > little impact on my code. > > > I will create an outhandler that will read from some configuration > > > source the max number of connections per host. > > > Then it will get the HttpClient from the channel, from the message > > > and it will get the ConnectionManager. Finally, "knowing" the type > > > of connection, I will set new params to it. > > > > > > this is REALLY ugly, I could say I hate it (I'm a very passionate man :P > ), but > > > can't afford a complex solution right now. And I hate it because if > > > anything changes on the implementation of the Channel or any underlying > > > objects, I'm screwed. (I had to cast two objects, which is sign of > > > very bad luck ;) HttpChannel + HttpClient (the last one is the > > > worst, i believe). > > > > > > I'll look more into this to see if there is another way but.... > > > in the mean time, does any of you have the same > > > problem as I do, or you can manage with 2 connections per host? > > > > > > Regards > > > Andres Bernasconi. > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe from this list please visit: > > > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > > > -- > > ----- > > When one of our products stops working, we'll blame another vendor > > within 24 hours. > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > ********************************************************************** > > HTC Disclaimer: The information contained in this message may be > privileged and confidential and protected from disclosure. If the reader of > this message is not the intended recipient, or an employee or agent > responsible for delivering this message to the intended recipient, you are > hereby notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by replying to the > message and deleting it from your computer. Thank you. > > > ********************************************************************** > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > -- ----- When one of our products stops working, we'll blame another vendor within 24 hours.
-- ----- When one of our products stops working, we'll blame another vendor within 24 hours. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
