Query regarding the performance of MULE over JBoss..

[nandan_tiwari]

Hi,

I am new to MULE. I have deployed an application of Mule over JBoss and testing its performance using JMeter.
First with the default thread pool size of JBoss(i.e., 10), I have evaluated the performance of Mule over JBoss. Then after, I increased the thread pool size to 500. But there is no improvement in the reponse time of the Http requests created by JMeter.

In another scenario, I have created a stateless session bean and deployed over JBoss. With the increase in the thread pool size from default(10) to 500, there is an improvement in the response time.

What can be the reason for this kind of behavior? Is MULE creating a bottleneck for the Http requests.
Can anyone help me regarding this? Immediate responses are appreciated.

Thanks
-Nandan

[Andrew Perepelytsya]

Interesting, why do you think posting the same question again without any details would yield any result? Performance tuning is a big subject and there's no config provided even. On a side note, it's not clear what kind of thread pool you had increased, there are many in Mule, and there's a component service pool. Jacking one up to 500 while leaving the other at 4 will not provide any improvement.

Andrew

[nandan_tiwari]

I have changed the thread pool size of JBoss in $JBOSS_HOME/server/default/conf/jboss-service.xml, under the basic thread pool section.
Mule is being used with all default configurations.

Andrew Perepelytsya wrote:

Interesting, why do you think posting the same question again without any
details would yield any result? Performance tuning is a big subject and
there's no config provided even. On a side note, it's not clear what kind of
thread pool you had increased, there are many in Mule, and there's a
component service pool. Jacking one up to 500 while leaving the other at 4
will not provide any improvement.

Andrew

[ddossot]

Do you use the servlet transport or the HTTP one?

On Wed, Mar 19, 2008 at 8:06 PM, nandan_tiwari <nandan.tiwari1@...> wrote:

I have changed the thread pool size of JBoss in
$JBOSS_HOME/server/default/conf/jboss-service.xml, under the basic thread
pool section.
Mule is being used with all default configurations.



Andrew Perepelytsya wrote:
>
> Interesting, why do you think posting the same question again without any
> details would yield any result? Performance tuning is a big subject and
> there's no config provided even. On a side note, it's not clear what kind
> of
> thread pool you had increased, there are many in Mule, and there's a
> component service pool. Jacking one up to 500 while leaving the other at 4
> will not provide any improvement.
>
> Andrew
>
>

--
View this message in context: http://www.nabble.com/Query-regarding-the-performance-of-MULE-over-JBoss..-tp16144404p16170638.html
Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[nandan_tiwari]

Hi,

We are using Http transport. The configuration for the http endpoint is mentioned below:
<inbound-router>
        <endpoint address="http://localhost:8888" transformers="HttpInboundTransformerFile" responseTransformers="ResponseTransformer"/>
</inbound-router>

When we increase the jboss thread pool size in case of mule application war over jboss, there is no improvement in the response time of mule. While in case of stateless session bean on jboss if we increase the jboss thread pool size, response time improves.

Could anybody help us in understanding why mule response time is not improving if we increase the jboss thread pool size.

Any reply will be appreciated as this problem is bottleneck to me.

greetings,
Nandan

ddossot wrote:

Do you use the servlet transport or the HTTP one?


On Wed, Mar 19, 2008 at 8:06 PM, nandan_tiwari <[e-mail]>
wrote:

>
> I have changed the thread pool size of JBoss in
> $JBOSS_HOME/server/default/conf/jboss-service.xml, under the basic thread
> pool section.
> Mule is being used with all default configurations.
>
>
>
> Andrew Perepelytsya wrote:
> >
> > Interesting, why do you think posting the same question again without
> any
> > details would yield any result? Performance tuning is a big subject and
> > there's no config provided even. On a side note, it's not clear what
> kind
> > of
> > thread pool you had increased, there are many in Mule, and there's a
> > component service pool. Jacking one up to 500 while leaving the other at
> 4
> > will not provide any improvement.
> >
> > Andrew
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Query-regarding-the-performance-of-MULE-over-JBoss..-tp16144404p16170638.html
> Sent from the Mule - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

[ddossot]

If you tweak the thread pool size of the JBoss servlet container but do not use it in Mule (you use the HTTP transport and not the Servlet one), there is no change to expect in the performances of Mule.

I have no idea regarding the EJB performance gain you notice as you have not given any details on how your SLSBs are called.

D.

On Wed, Mar 19, 2008 at 9:55 PM, nandan_tiwari <nandan.tiwari1@...> wrote:

Hi,

We are using Http transport. The configuration for the http endpoint is
mentioned below:
<inbound-router>
       <endpoint address="http://localhost:8888"
transformers="HttpInboundTransformerFile"
responseTransformers="ResponseTransformer"/>
</inbound-router>

When we increase the jboss thread pool size in case of mule application war
over jboss, there is no improvement in the response time of mule. While in
case of stateless session bean on jboss if we increase the jboss thread pool
size, response time improves.

Could anybody help us in understanding why mule response time is not
improving if we increase the jboss thread pool size.

Any reply will be appreciated as this problem is bottleneck to me.

greetings,
Nandan

ddossot wrote:
>
> Do you use the servlet transport or the HTTP one?
>
>
> On Wed, Mar 19, 2008 at 8:06 PM, nandan_tiwari <nandan.tiwari1@...>
> wrote:
>
>>
>> I have changed the thread pool size of JBoss in
>> $JBOSS_HOME/server/default/conf/jboss-service.xml, under the basic thread
>> pool section.
>> Mule is being used with all default configurations.
>>
>>
>>
>> Andrew Perepelytsya wrote:
>> >
>> > Interesting, why do you think posting the same question again without
>> any
>> > details would yield any result? Performance tuning is a big subject and
>> > there's no config provided even. On a side note, it's not clear what
>> kind
>> > of
>> > thread pool you had increased, there are many in Mule, and there's a
>> > component service pool. Jacking one up to 500 while leaving the other
>> at
>> 4
>> > will not provide any improvement.
>> >
>> > Andrew
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Query-regarding-the-performance-of-MULE-over-JBoss..-tp16144404p16170638.html
>> Sent from the Mule - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Query-regarding-the-performance-of-MULE-over-JBoss..-tp16144404p16171612.html

Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Davide Piazza]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Interesting thread.
We also deploy our mule into JBoss. We use several transports (JMS, File, JBDB, FTP, etc...)  and we will soon face the performance tuning. My question is: is it sufficient to use Mule threading pooling in my case or also jboss one may help?

thanks
Davide.

2008/3/20, David Dossot <david@...>:

If you tweak the thread pool size of the JBoss servlet container but do not use it in Mule (you use the HTTP transport and not the Servlet one), there is no change to expect in the performances of Mule.

I have no idea regarding the EJB performance gain you notice as you have not given any details on how your SLSBs are called.

D.

On Wed, Mar 19, 2008 at 9:55 PM, nandan_tiwari <nandan.tiwari1@...> wrote:

Hi,

We are using Http transport. The configuration for the http endpoint is
mentioned below:
<inbound-router>
       <endpoint address="http://localhost:8888"
transformers="HttpInboundTransformerFile"
responseTransformers="ResponseTransformer"/>
</inbound-router>

When we increase the jboss thread pool size in case of mule application war
over jboss, there is no improvement in the response time of mule. While in
case of stateless session bean on jboss if we increase the jboss thread pool
size, response time improves.

Could anybody help us in understanding why mule response time is not
improving if we increase the jboss thread pool size.

Any reply will be appreciated as this problem is bottleneck to me.

greetings,
Nandan

ddossot wrote:
>
> Do you use the servlet transport or the HTTP one?
>
>
> On Wed, Mar 19, 2008 at 8:06 PM, nandan_tiwari <nandan.tiwari1@...>
> wrote:
>
>>
>> I have changed the thread pool size of JBoss in
>> $JBOSS_HOME/server/default/conf/jboss-service.xml, under the basic thread
>> pool section.
>> Mule is being used with all default configurations.
>>
>>
>>
>> Andrew Perepelytsya wrote:
>> >
>> > Interesting, why do you think posting the same question again without
>> any
>> > details would yield any result? Performance tuning is a big subject and
>> > there's no config provided even. On a side note, it's not clear what
>> kind
>> > of
>> > thread pool you had increased, there are many in Mule, and there's a
>> > component service pool. Jacking one up to 500 while leaving the other
>> at
>> 4
>> > will not provide any improvement.
>> >
>> > Andrew
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Query-regarding-the-performance-of-MULE-over-JBoss..-tp16144404p16170638.html
>> Sent from the Mule - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Query-regarding-the-performance-of-MULE-over-JBoss..-tp16144404p16171612.html

Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[ddossot]

JBoss servlet container thread tuning can help if you use the servlet transport, though by default it is already quite high. Similarly EJBs pool sizes tuning can help if you call EJBs from Mule.

D.

On Thu, Mar 20, 2008 at 1:46 AM, Davide Piazza <davide.piazza@...> wrote:

Interesting thread.
We also deploy our mule into JBoss. We use several transports (JMS, File, JBDB, FTP, etc...)  and we will soon face the performance tuning. My question is: is it sufficient to use Mule threading pooling in my case or also jboss one may help?

thanks
Davide.

2008/3/20, David Dossot <david@...>:

If you tweak the thread pool size of the JBoss servlet container but do not use it in Mule (you use the HTTP transport and not the Servlet one), there is no change to expect in the performances of Mule.

I have no idea regarding the EJB performance gain you notice as you have not given any details on how your SLSBs are called.

D.

On Wed, Mar 19, 2008 at 9:55 PM, nandan_tiwari <nandan.tiwari1@...> wrote:

Hi,

We are using Http transport. The configuration for the http endpoint is
mentioned below:
<inbound-router>
       <endpoint address="http://localhost:8888"
transformers="HttpInboundTransformerFile"
responseTransformers="ResponseTransformer"/>
</inbound-router>

When we increase the jboss thread pool size in case of mule application war
over jboss, there is no improvement in the response time of mule. While in
case of stateless session bean on jboss if we increase the jboss thread pool
size, response time improves.

Could anybody help us in understanding why mule response time is not
improving if we increase the jboss thread pool size.

Any reply will be appreciated as this problem is bottleneck to me.

greetings,
Nandan

ddossot wrote:
>
> Do you use the servlet transport or the HTTP one?
>
>
> On Wed, Mar 19, 2008 at 8:06 PM, nandan_tiwari <nandan.tiwari1@...>
> wrote:
>
>>
>> I have changed the thread pool size of JBoss in
>> $JBOSS_HOME/server/default/conf/jboss-service.xml, under the basic thread
>> pool section.
>> Mule is being used with all default configurations.
>>
>>
>>
>> Andrew Perepelytsya wrote:
>> >
>> > Interesting, why do you think posting the same question again without
>> any
>> > details would yield any result? Performance tuning is a big subject and
>> > there's no config provided even. On a side note, it's not clear what
>> kind
>> > of
>> > thread pool you had increased, there are many in Mule, and there's a
>> > component service pool. Jacking one up to 500 while leaving the other
>> at
>> 4
>> > will not provide any improvement.
>> >
>> > Andrew
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Query-regarding-the-performance-of-MULE-over-JBoss..-tp16144404p16170638.html
>> Sent from the Mule - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Query-regarding-the-performance-of-MULE-over-JBoss..-tp16144404p16171612.html

Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[PawanModi]

Hi,

I want to know how did you make test using Jmeter for Mule. I want to perform some test on Mule using Jmeter. Can you guide me the configuration for the same.

i want my jms publisher & consumer will run from Jmeter. I will run my mule-config.xml which will create connection to ActiveMQ server. Now finally i want to provide connection between my Jmeter publisher to running mule & from mule to Jmeter consumer.

I tried using Jmeter publisher & consumer sampler but don't know how to provide connection between Jmeter & mule.

Please help me.

Thanks in advance.

With regards,
Pawan Modi

nandan_tiwari wrote:

Hi,

I am new to MULE. I have deployed an application of Mule over JBoss and testing its performance using JMeter.
First with the default thread pool size of JBoss(i.e., 10), I have evaluated the performance of Mule over JBoss. Then after, I increased the thread pool size to 500. But there is no improvement in the reponse time of the Http requests created by JMeter.

In another scenario, I have created a stateless session bean and deployed over JBoss. With the increase in the thread pool size from default(10) to 500, there is an improvement in the response time.

What can be the reason for this kind of behavior? Is MULE creating a bottleneck for the Http requests.
Can anyone help me regarding this? Immediate responses are appreciated.

Thanks
-Nandan

[Hatta]

Hi dossot

I m trying to stress test mule on jboss with ActiveMQ as the jms provider. My stress tool is Jmeter.

My objective is to reach a high number of http connection request made from mule to an external web service.

Based on the result of my stress test, from 100 until 1000 http request going thru a jms queue and being sent again via Rest Servlet thru http post - the maximum number of threads I can achieve is 8.

How I got the value is by tracing the number of request made on a particular IP thru netstat utility.

Is there any way I can break the limit? Which configuration do I have to change?


Below is my configuration:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE mule-configuration PUBLIC "-//MuleSource //DTD mule-configuration XML V1.0//EN"
                                "http://mule.mulesource.org/dtds/mule-configuration.dtd">

<mule-configuration id="CONN_TEST" version="1.0">
    <description>
                HTTP CONNECTION TEST
                The purpose of this configuration is to check whether the threading can be configured on Mule
                with the simplest model.

                Note:(This model will be reusing the existing queue component). Dont forget to change the configuration
                        at the web.xml level in epis-espkb-queue
    </description>
    <mule-environment-properties serverUrl="tcp://localhost:61105">
    </mule-environment-properties>

    <container-context className="org.mule.extras.spring.SpringContainerContext"
                   name="spring">
            <properties>
                <property name="configFile" value="activemq-spring.xml"/>
            </properties>
     </container-context>

    <agents>
    <agent name="JmxAgent" className="org.mule.management.agents.JmxAgent" />
    </agents>

        <connector name="StreamConn" className="org.mule.providers.stream.SystemStreamConnector"/>

        <connector name="TcpConn" className="org.mule.providers.tcp.TcpConnector">
                <properties>
                        <property name="numberOfConcurrentTransactedReceivers" value="10" />
                </properties>
        </connector>

        <connector name="HttpConn1" className="org.mule.providers.http.HttpConnector">
       <properties>
      <property name="timeout" value="5000"/>
      <property name="backlog" value="700"/>
      <property name="numberOfConcurrentTransactedReceivers" value="10" />
    </properties>
    <threading-profile id="receiver" maxThreadsActive="50" maxThreadsIdle="50" threadTTL="60000" poolExhaustedAction="RUN" threadWaitTimeout="30" maxBufferSize="0" doThreading="true"/>
    </connector>
        <connector name="jmsConn" className="org.mule.providers.jms.JmsConnector">
            <properties>
                <property name="specification" value="1.1"/>
                <property name="persistentDelivery" value="true" />
                <property name="numberOfConcurrentTransactedReceivers" value="10" />
                <container-property name="connectionFactory"
                                    reference="activeMqConnectionFactory"
                                    container="spring"/>
            </properties>
            <threading-profile id="receiver" maxThreadsActive="50" maxThreadsIdle="50" threadTTL="60000" poolExhaustedAction="RUN" threadWaitTimeout="30" maxBufferSize="0" doThreading="true"/>
        </connector>

        <transformers>
                <transformer name="HttpRequestToString" className="com.cdc.epis.testcase.HttpRequestToString">
        <properties>
        <property name="dataparam" value="Data"/>
        <property name="msgcodeparam" value="MsgCode"/>
        <property name="queueidparam" value="QueueId"/>
        </properties>
        </transformer>
    <transformer name="MessagePropertiesTransformer" className="org.mule.transformers.simple.MessagePropertiesTransformer" >
            <properties>
                                <list name="deleteProperties">
                                   <entry value="JMSReplyTo"/>
                                </list>
            </properties>
        </transformer>
        <transformer name="JmsToString" className="org.mule.providers.jms.transformers.JMSMessageToObject"/>
        <transformer name="StringToJms" className="com.cdc.epis.transformers.ObjectToJMSMessage" returnClass="javax.jms.TextMessage"/>
        <transformer name="QueryStringToStringArray" className="com.cdc.epis.testcase.QueryStringToStringArray"/>
        </transformers>


    <model name="HTTP_TEST">

             <mule-descriptor name="HttpReceiver" implementation="org.mule.components.simple.BridgeComponent">
                    <inbound-router>
                    <endpoint  address="http://172.16.50.62:8801/ttbs" connector="HttpConn1" synchronous="true" transformers="HttpRequestToString"/>
                    </inbound-router>
                    <outbound-router>
                        <router className="org.mule.routing.outbound.OutboundPassThroughRouter">
                              <endpoint address="jms://inbound.queue" connector="jmsConn" transformers="StringToJms MessagePropertiesTransformer"/>
                        </router>
                    </outbound-router>
             </mule-descriptor>

        <mule-descriptor name="HttpController" implementation="org.mule.components.simple.BridgeComponent" initialState="stopped">
            <inbound-router>
            <endpoint address="jms://inbound.queue" connector="jmsConn" transformers="JmsToString QueryStringToStringArray"/>
            </inbound-router>
            <outbound-router>
            <router className="org.mule.routing.outbound.ChainingRouter">
            <endpoint address="vm://simulator"/>
                                        <endpoint address="stream://System.out" connector="StreamConn"/>
                                </router>
            </outbound-router>
        </mule-descriptor>

        <mule-descriptor name="HttpDispatcher" implementation="org.mule.components.rest.RestServiceWrapper">
            <inbound-router>
                <endpoint address="vm://simulator"/>
            </inbound-router>
            <properties>
                <property name="serviceUrl" value="http://172.16.50.62:8080/epis-espkb-simulator/servlet/IBGatewayManual2"/>
                <list name="payloadParameterNames">
                    <entry value="Data"/>
                    <entry value="MsgCode"/>
                </list>
                <property name="httpMethod" value="POST"/>
            </properties>
        </mule-descriptor>


     </model>

</mule-configuration>

[ddossot]

I honestly do not have time to go through the specific of your configurations, but have several questions/remarks:

• What do you mean by "the maximum number of threads I can achieve is 8"?
• numberOfConcurrentTransactedReceivers is not a valid property of TCP nor HTTP connectors.
• Since you run in JBoss, you would better use the servlet connector and not the stock HTTP one for inbound endpoints (this way you will leverage JBoss web container threading model).
  

All in all I find your test pretty convoluted: you intend to max out the number of HTTP requests issued simultaneously by the REST service wrapper but have a complex chain of asynchronous services / polling mechanism before it to effectively throttle the load. I am unclear with what you try to achieve.

D.

PS. As a side note, you might want to read this very good post on SEDA from Nick Zhu.

On Tue, Jul 22, 2008 at 1:44 AM, Hatta <rmi_jndi@...> wrote:

Hi dossot

I m trying to stress test mule on jboss with ActiveMQ as the jms provider.
My stress tool is Jmeter.

My objective is to reach a high number of http connection request made from
mule to an external web service.

Based on the result of my stress test, from 100 until 1000 http request
going thru a jms queue and being sent again via Rest Servlet thru http post
- the maximum number of threads I can achieve is 8.

How I got the value is by tracing the number of request made on a particular
IP thru netstat utility.

Is there any way I can break the limit? Which configuration do I have to
change?


Below is my configuration:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE mule-configuration PUBLIC "-//MuleSource //DTD mule-configuration
XML V1.0//EN"

"http://mule.mulesource.org/dtds/mule-configuration.dtd">

<mule-configuration id="CONN_TEST" version="1.0">
   <description>
               HTTP CONNECTION TEST
               The purpose of this configuration is to check whether the threading can be
configured on Mule
               with the simplest model.

               Note:(This model will be reusing the existing queue component). Dont
forget to change the configuration
                       at the web.xml level in epis-espkb-queue
   </description>
   <mule-environment-properties serverUrl="tcp://localhost:61105">
   </mule-environment-properties>

   <container-context
className="org.mule.extras.spring.SpringContainerContext"
                  name="spring">
           <properties>
               <property name="configFile" value="activemq-spring.xml"/>
           </properties>
    </container-context>

   <agents>
       <agent name="JmxAgent" className="org.mule.management.agents.JmxAgent"
/>
   </agents>

       <connector name="StreamConn"
className="org.mule.providers.stream.SystemStreamConnector"/>

       <connector name="TcpConn" className="org.mule.providers.tcp.TcpConnector">
               <properties>
                       <property name="numberOfConcurrentTransactedReceivers" value="10" />
               </properties>
       </connector>

       <connector name="HttpConn1"
className="org.mule.providers.http.HttpConnector">
           <properties>
               <property name="timeout" value="5000"/>
               <property name="backlog" value="700"/>
               <property name="numberOfConcurrentTransactedReceivers" value="10" />
       </properties>
       <threading-profile id="receiver" maxThreadsActive="50"
maxThreadsIdle="50" threadTTL="60000" poolExhaustedAction="RUN"
threadWaitTimeout="30" maxBufferSize="0" doThreading="true"/>
   </connector>
       <connector name="jmsConn" className="org.mule.providers.jms.JmsConnector">
           <properties>
               <property name="specification" value="1.1"/>
               <property name="persistentDelivery" value="true" />
               <property name="numberOfConcurrentTransactedReceivers" value="10"
/>
               <container-property name="connectionFactory"
                                   reference="activeMqConnectionFactory"
                                   container="spring"/>
           </properties>
           <threading-profile id="receiver" maxThreadsActive="50"
maxThreadsIdle="50" threadTTL="60000" poolExhaustedAction="RUN"
threadWaitTimeout="30" maxBufferSize="0" doThreading="true"/>
       </connector>

       <transformers>
               <transformer name="HttpRequestToString"
className="com.cdc.epis.testcase.HttpRequestToString">
               <properties>
                       <property name="dataparam" value="Data"/>
                       <property name="msgcodeparam" value="MsgCode"/>
                       <property name="queueidparam" value="QueueId"/>
               </properties>
       </transformer>
       <transformer name="MessagePropertiesTransformer"
className="org.mule.transformers.simple.MessagePropertiesTransformer" >
           <properties>
                               <list name="deleteProperties">
                                  <entry value="JMSReplyTo"/>
                               </list>
           </properties>
       </transformer>
       <transformer name="JmsToString"
className="org.mule.providers.jms.transformers.JMSMessageToObject"/>
       <transformer name="StringToJms"
className="com.cdc.epis.transformers.ObjectToJMSMessage"
returnClass="javax.jms.TextMessage"/>
       <transformer name="QueryStringToStringArray"
className="com.cdc.epis.testcase.QueryStringToStringArray"/>
       </transformers>


   <model name="HTTP_TEST">

            <mule-descriptor name="HttpReceiver"
implementation="org.mule.components.simple.BridgeComponent">
                   <inbound-router>
                       <endpoint  address="http://172.16.50.62:8801/ttbs"
connector="HttpConn1" synchronous="true"
transformers="HttpRequestToString"/>
                   </inbound-router>
                   <outbound-router>
                       <router
className="org.mule.routing.outbound.OutboundPassThroughRouter">
                             <endpoint address="jms://inbound.queue"
connector="jmsConn" transformers="StringToJms
MessagePropertiesTransformer"/>
                       </router>
                   </outbound-router>
            </mule-descriptor>

       <mule-descriptor name="HttpController"
implementation="org.mule.components.simple.BridgeComponent"
initialState="stopped">
           <inbound-router>
               <endpoint address="jms://inbound.queue" connector="jmsConn"
transformers="JmsToString QueryStringToStringArray"/>
           </inbound-router>
           <outbound-router>
               <router className="org.mule.routing.outbound.ChainingRouter">
                       <endpoint address="vm://simulator"/>
                                       <endpoint address="stream://System.out" connector="StreamConn"/>
                               </router>
           </outbound-router>
       </mule-descriptor>

       <mule-descriptor name="HttpDispatcher"
implementation="org.mule.components.rest.RestServiceWrapper">
           <inbound-router>
               <endpoint address="vm://simulator"/>
           </inbound-router>
           <properties>
               <property name="serviceUrl"
value="http://172.16.50.62:8080/epis-espkb-simulator/servlet/IBGatewayManual2"/>
               <list name="payloadParameterNames">
                   <entry value="Data"/>
                   <entry value="MsgCode"/>
               </list>
               <property name="httpMethod" value="POST"/>
           </properties>
       </mule-descriptor>


    </model>

</mule-configuration>

--
View this message in context: http://www.nabble.com/Query-regarding-the-performance-of-MULE-over-JBoss..-tp16144404p18584924.html

Sent from the Mule - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Hatta]

Hi again,

Dossot, I appreciate your time in responding to my queries.

What do you mean by "the maximum number of threads I can achieve is 8"?

It means, based on the number of queues which I have filled up (ie: 1000), the RestServiceWrapper is only able to create 8 threads to process the 1000 data to be sent over to the webservice channel.

I was expecting more than 8 threads. Is there a way for me to do this?

   - numberOfConcurrentTransactedReceivers is not a valid property of TCP
   nor HTTP connectors.
   
   OK, noted. I thought it may increase the number of threads.

   - Since you run in JBoss, you would better use the servlet connector and
   not the stock HTTP one for inbound endpoints (this way you will leverage
   JBoss web container threading model).

   Ok, noted.

All in all I find your test pretty convoluted: you intend to max out the
number of HTTP requests issued simultaneously by the REST service wrapper
but have a complex chain of asynchronous services / polling mechanism before
it to effectively throttle the load.

I will remove the chainingRouter if that is the cause for me not to achieve more than 8 threads.

I have read the article you provided. SEDA can support mass transmission if it is configured properly.

regards
Hatta




I honestly do not have time to go through the specific of your
configurations, but have several questions/remarks:

   - What do you mean by "the maximum number of threads I can achieve is 8"?
   - numberOfConcurrentTransactedReceivers is not a valid property of TCP
   nor HTTP connectors.
   - Since you run in JBoss, you would better use the servlet connector and
   not the stock HTTP one for inbound endpoints (this way you will leverage
   JBoss web container threading model).

All in all I find your test pretty convoluted: you intend to max out the
number of HTTP requests issued simultaneously by the REST service wrapper
but have a complex chain of asynchronous services / polling mechanism before
it to effectively throttle the load. I am unclear with what you try to
achieve.

D.

PS. As a side note, you might want to read this very good post on
SEDA<http://www.zoochee.com/2008/07/seda.html>from Nick Zhu.

[ddossot]

In order to eliminate all possible side effects from the inbound HTTP and ActiveMQ, have you tried a limited configuration with only the "HttpDispatcher" in it? Then, with this reduced scenario, tune the connector and component pooling and threading profiles until you reach your target.

D.