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
