[mule-transport-jersey-user] deployment of jersey-mule based service and performance question

[gabriele renzi-5]

hi everyone,

we have a working service based on mule, where some parts of it are
published as simple restful services implemented with the jersey
transport, which was really pleasant to develop with, thank you :) .

We deployed a standalone mule server on a 8 core machine, but we are
having issues understanding the performance side of it: it appears
that up to a concurrency of a few users (tested using the "ab" tool)
everything works fine with fast response times, but if we raise the
concurrency the largest part of the requests get dropped, and the
strange thing is the mule process resource consumption does not seem
to increase much.

We thought this might be a problem connected to the default mule
threading profile (16 maxThreadsActive per service, if I recall
correctly),  so we tried raising the number of threads:

                <service name="RestApi">
                        <inbound>
                                <inbound-endpoint address="jersey:http://localhost/" synchronous="true" />
                        </inbound>
                        <threading-profile maxThreadsActive="50"
maxThreadsIdle="20" maxBufferSize="10"/>
                </service>

But we did not see any difference.

The application does not make many accesses to external services as it
caches everything on the first calls, so I have (for now) excluded IO
boundness, but before diving into a long profile session I thought it
would be a good idea to ask if we are doing anything terribly wrong
or if we should just change the threading profile a bit (I recall
tomcat runs with 200 threads or something).

And as a general deployment suggestion, we are wondering if it makes
sense to keep this kind of deploy (load balanced standalone mule
instances) or we should instead look into putting mule inside
tomcat/tcat/some other app server.

Thanks in advance for any suggestions.


--
blog en: http://www.riffraff.info
blog it: http://riffraff.blogsome.com

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

    http://admin.muleforge.org/manage_email



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MuleForge Dev" group.
To post to this group, send email to muleforgedev@...
To unsubscribe from this group, send email to muleforgedev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/muleforgedev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Dan Diephouse-2]

Hi Gabriele,

I have heard of a similar problem from one other user, but despite my best effort I have not been able to reproduce the problem. 

Can you post your whole config? What type of component do you have? Did you try increasing your receiver threads? I'm not sure that the <service> threading profile change will make a difference for your situation as I think (and don't quote me on this) that it only applies to threads for the component.

Dan

On Fri, Nov 6, 2009 at 11:44 AM, gabriele renzi <rff.rff@...> wrote:

hi everyone,

we have a working service based on mule, where some parts of it are
published as simple restful services implemented with the jersey
transport, which was really pleasant to develop with, thank you :) .

We deployed a standalone mule server on a 8 core machine, but we are
having issues understanding the performance side of it: it appears
that up to a concurrency of a few users (tested using the "ab" tool)
everything works fine with fast response times, but if we raise the
concurrency the largest part of the requests get dropped, and the
strange thing is the mule process resource consumption does not seem
to increase much.

We thought this might be a problem connected to the default mule
threading profile (16 maxThreadsActive per service, if I recall
correctly),  so we tried raising the number of threads:

               <service name="RestApi">
                       <inbound>
                               <inbound-endpoint address="jersey:http://localhost/" synchronous="true" />
                       </inbound>
                       <threading-profile maxThreadsActive="50"
maxThreadsIdle="20" maxBufferSize="10"/>
               </service>

But we did not see any difference.

The application does not make many accesses to external services as it
caches everything on the first calls, so I have (for now) excluded IO
boundness, but before diving into a long profile session I thought it
would be a good idea to ask if we are doing anything terribly wrong
or if we should just change the threading profile a bit (I recall
tomcat runs with 200 threads or something).

And as a general deployment suggestion, we are wondering if it makes
sense to keep this kind of deploy (load balanced standalone mule
instances) or we should instead look into putting mule inside
tomcat/tcat/some other app server.

Thanks in advance for any suggestions.


--
blog en: http://www.riffraff.info
blog it: http://riffraff.blogsome.com

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

   http://admin.muleforge.org/manage_email

--
Dan Diephouse
http://mulesource.com | http://netzooid.com/blog

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MuleForge Dev" group.
To post to this group, send email to muleforgedev@...
To unsubscribe from this group, send email to muleforgedev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/muleforgedev?hl=en
-~----------~----~----~----~------~----~------~--~---

[gabriele renzi-5]

On Sun, Nov 8, 2009 at 1:49 AM, Dan Diephouse
<dan.diephouse@...> wrote:
> Hi Gabriele,
> I have heard of a similar problem from one other user, but despite my best
> effort I have not been able to reproduce the problem.
> Can you post your whole config?

Yes, well, I will try to reproduce it with a minimal setup as soon as possible

> What type of component do you have?

I'm not sure I understand the question, the servlet is a spring
singleton component relying on a few other singletons, nothing fancy.

> Did you
> try increasing your receiver threads? I'm not sure that the <service>
> threading profile change will make a difference for your situation as I
> think (and don't quote me on this) that it only applies to threads for the
> component.

ah, yes, this makes sense, as we only defined this endpoint inline,
and all the configuration we have is the one I posted for it.
I will attempt to define a theading-profile in a <connector> stanza,
and let you know what I find, thanks for the reply and sorry for late
responding.

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

    http://admin.muleforge.org/manage_email



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MuleForge Dev" group.
To post to this group, send email to muleforgedev@...
To unsubscribe from this group, send email to muleforgedev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/muleforgedev?hl=en
-~----------~----~----~----~------~----~------~--~---

[gabriele renzi-5]

On Mon, Nov 9, 2009 at 4:34 PM, gabriele renzi <rff.rff@...> wrote:
> On Sun, Nov 8, 2009 at 1:49 AM, Dan Diephouse

>> Did you
>> try increasing your receiver threads? I'm not sure that the <service>
>> threading profile change will make a difference for your situation as I
>> think (and don't quote me on this) that it only applies to threads for the
>> component.
>
> ah, yes, this makes sense, as we only defined this endpoint inline,
> and all the configuration we have is the one I posted for it.
> I will attempt to define a theading-profile in a <connector> stanza,
> and let you know what I find, thanks for the reply and sorry for late
> responding.

this appears to have done the trick, I am now able to make much more
concurrent requests and I see no failures. It still seems that cpu
load is not very heavy on my machine so I will try to load even more
threads, but I believe now the bottleneck is on our code. So it
appears we were actually doing something wrong, thanks :)



--
blog en: http://www.riffraff.info
blog it: http://riffraff.blogsome.com

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

    http://admin.muleforge.org/manage_email



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MuleForge Dev" group.
To post to this group, send email to muleforgedev@...
To unsubscribe from this group, send email to muleforgedev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/muleforgedev?hl=en
-~----------~----~----~----~------~----~------~--~---

[Dan Diephouse-2]

That's great to hear. Thanks!

On Tue, Nov 10, 2009 at 3:56 PM, gabriele renzi <rff.rff@...> wrote:

On Mon, Nov 9, 2009 at 4:34 PM, gabriele renzi <rff.rff@...> wrote:
> On Sun, Nov 8, 2009 at 1:49 AM, Dan Diephouse

>> Did you
>> try increasing your receiver threads? I'm not sure that the <service>
>> threading profile change will make a difference for your situation as I
>> think (and don't quote me on this) that it only applies to threads for the
>> component.
>
> ah, yes, this makes sense, as we only defined this endpoint inline,
> and all the configuration we have is the one I posted for it.
> I will attempt to define a theading-profile in a <connector> stanza,
> and let you know what I find, thanks for the reply and sorry for late
> responding.

this appears to have done the trick, I am now able to make much more
concurrent requests and I see no failures. It still seems that cpu
load is not very heavy on my machine so I will try to load even more
threads, but I believe now the bottleneck is on our code. So it
appears we were actually doing something wrong, thanks :)



--

blog en: http://www.riffraff.info
blog it: http://riffraff.blogsome.com

---------------------------------------------------------------------

To unsubscribe from this list, please visit:

   http://admin.muleforge.org/manage_email

--
Dan Diephouse
http://mulesource.com | http://netzooid.com/blog

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MuleForge Dev" group.
To post to this group, send email to muleforgedev@...
To unsubscribe from this group, send email to muleforgedev+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/muleforgedev?hl=en
-~----------~----~----~----~------~----~------~--~---