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
>>>
>>>
>>
>>
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://open.iona.com
