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
