Hi Andrea, Of course, if the webservice is implemented using CXF and hosted on SMX using the smx-cxf-se, then you can achieve optimal performance by simply communicating with it via the NMR, no binding components required.
- Ron ----- Original Message ---- From: Andrea Zoppello <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, September 23, 2008 11:04:09 AM Subject: Re: channel.send() - Performance problems??? Hi Guillaume, Yeah after a lot of test it seems this is the way to go, i've had improvements with your suggestion but i've other considerations it could be helpful to the community. I've try this two configuration: 1) The server with servicemix and the server exposing the webservice are deployed in the same physical machine, ( i've made this test to eliminate network times ), in that configuration the pure webeservice call ( misured time before the http method execute and after ) is obviously improved but in that case thiw will probably result in more concurrent load in channel.send() that introduce some time to go, bu it's acceptable. 2) In the other configuration the server with servicemix and the server with webeservice are different machine, in that case i've the time to execute the webservice increased and the channel.send() method has no impact ( 0 - 10 ms ) Hope this help, It could be useful prvovide some guide about that. I would like to achieve a situation where i've deployed servicemix, and the webservices on one machine, and the channel.send() reduced in terms of millisecond. Andrea Guillaume Nodet ha scritto: > Yeah, you may want to try with the 130k soap response and only enable > the seda flow: > > <sm:broker> > <sm:securedBroker authorizationMap="#authorizationMap"> > <sm:flows> > <sm:sedaFlow /> > </sm:flows> > </sm:securedBroker> > </sm:broker> > > On Tue, Sep 23, 2008 at 1:56 PM, Andrea Zoppello <[EMAIL PROTECTED]> wrote: > >> Hi Guillaume, >> >> First of all, thank you for your response. I see there's a book about >> activemq by manning. >> Do you think this could be util when working with smx?? >> >> If a book about make production ready configuration with servicemix will be >> available, i think >> i've not problem in buying it. >> >> I'll try with your suggestion and let you know, i'm trying this >> configuration, but what is very strange >> is that if i reduce the soap response to 10k instead of 130k performance >> bost, for this reason, i >> expect there's some relation of performance degrading with the payload size. >> >> 1) I've substituted AMQ 4 with AMQ 5.1 >> >> 2) servicemix.corePoolSize = 256 >> servicemix.maximumPoolSize = -1 >> servicemix.queueSize = 65536 >> >> 3) There's no listener active >> >> 4) All loggers are at WARN level >> >> 5) The only doubt i've is about the flow, now i've configured the >> servicemix.xml as follow: >> >> <sm:broker> >> <sm:securedBroker authorizationMap="#authorizationMap"> >> <sm:flows> >> <sm:sedaFlow /> >> <sm:jmsFlow jmsURL="${activemq.url}" /> >> <sm:jcaFlow connectionManager="#connectionManager" >> jmsURL="${activemq.url}" /> >> </sm:flows> >> </sm:securedBroker> >> </sm:broker> >> >> >> Guillaume Nodet ha scritto: >> >>> It really depends on a whole lot of things: >>> * flow used >>> * thread pool config >>> * debug logging turned off >>> * listeners registered (i'm thinking about some listeners that could >>> serialize the whole exchange to a DB for example) >>> The channel.send() method time will depends on those 4 parameters (at >>> least), so I would suggest the following: >>> * only enable SEDA flow >>> * raise thread pools >>> * make sure logging is at INFO level >>> * use a trimmed configuration (no audit, no spagic listeners, etc...) >>> >>> On Fri, Sep 19, 2008 at 3:21 PM, Andrea Zoppello <[EMAIL PROTECTED]> >>> wrote: >>> >>> >>>> Hi all, >>>> >>>> After investigating some performance problem using an eip pipeline under >>>> a >>>> load of >>>> 20 concurrent client, i've found enablig some detailed tracing of time >>>> for >>>> each instruction of >>>> "org.apache.servicemix.http.processors.Processor" class ( I've modified >>>> the >>>> source to add detailed time level logging ) and >>>> i've discovered the problem is in channel.send() method. >>>> >>>> This is probably because the external webservice have a big soap >>>> response. >>>> >>>> At the moment i've think the problem was in Unmarshalling phase but after >>>> detailed ( debug level ) >>>> tracing, i diecovered the problem is in the send method. >>>> >>>> I've time of 19, 20 seconds for sendig message, i've not measured the >>>> size >>>> of soap response, i'll trace >>>> the size and let you know, but it seem that big messages are not handled >>>> in >>>> very efficient way. >>>> >>>> Any idea about that?? >>>> >>>> Andrea >>>> >>>> >>>> >>> >>> >>> >> > > > >
