Performance issues in multithreaded scenario

[Dennis]

Dear All,

we develop an application with the use of ironjacamar to utilize it behind a JBoss AS (EAP 6.2). 

So we ran into performance issues when using the system under some (multithreaded) load, we cannot explain. 

Here’s a brief summary what we do - we recreate the scenario with your hello world example:

At first we connect a client application to a remote bean and call a service method (helloWorld()) in parallel.

final String binding = "ejb:/helloworldbean/HelloWorldBean!org.jboss.jca.samples.helloworld.bean.HelloWorld“;
…
service.helloWorld();

On the remote end a HelloWorldBean is receiving the request - here the code is mostly borrowed from the jca/ironjacamar examples.

Now we do some measurements on the client side and this is worrying: we got a significant growth on each run. 

The more threads we add, the more it's rising. Here are some traces:

20 threads in parallel:

ending call: ClsTester-0, Sun Apr 24 14:27:57 CEST 2016, took 20 ms

ending call: ClsTester-10, Sun Apr 24 14:27:57 CEST 2016, took 17 ms

ending call: ClsTester-3, Sun Apr 24 14:27:57 CEST 2016, took 25 ms

ending call: ClsTester-4, Sun Apr 24 14:27:57 CEST 2016, took 29 ms

ending call: ClsTester-13, Sun Apr 24 14:27:57 CEST 2016, took 29 ms

ending call: ClsTester-5, Sun Apr 24 14:27:57 CEST 2016, took 32 ms

ending call: ClsTester-16, Sun Apr 24 14:27:57 CEST 2016, took 34 ms

ending call: ClsTester-18, Sun Apr 24 14:27:57 CEST 2016, took 36 ms

ending call: ClsTester-8, Sun Apr 24 14:27:57 CEST 2016, took 36 ms

ending call: ClsTester-17, Sun Apr 24 14:27:57 CEST 2016, took 38 ms

ending call: ClsTester-1, Sun Apr 24 14:27:57 CEST 2016, took 42 ms

ending call: ClsTester-9, Sun Apr 24 14:27:57 CEST 2016, took 42 ms

ending call: ClsTester-2, Sun Apr 24 14:27:57 CEST 2016, took 46 ms

ending call: ClsTester-12, Sun Apr 24 14:27:57 CEST 2016, took 47 ms

ending call: ClsTester-15, Sun Apr 24 14:27:57 CEST 2016, took 48 ms

ending call: ClsTester-7, Sun Apr 24 14:27:57 CEST 2016, took 51 ms

ending call: ClsTester-14, Sun Apr 24 14:27:57 CEST 2016, took 50 ms

ending call: ClsTester-11, Sun Apr 24 14:27:57 CEST 2016, took 51 ms

ending call: ClsTester-6, Sun Apr 24 14:27:57 CEST 2016, took 52 ms

ending call: ClsTester-19, Sun Apr 24 14:27:57 CEST 2016, took 53 ms

25 threads in parallel:

ending call: ClsTester-13, Sun Apr 24 14:27:57 CEST 2016, took 11 ms

ending call: ClsTester-11, Sun Apr 24 14:27:57 CEST 2016, took 14 ms

ending call: ClsTester-4, Sun Apr 24 14:27:57 CEST 2016, took 16 ms

ending call: ClsTester-18, Sun Apr 24 14:27:57 CEST 2016, took 11 ms

ending call: ClsTester-14, Sun Apr 24 14:27:57 CEST 2016, took 12 ms

ending call: ClsTester-24, Sun Apr 24 14:27:57 CEST 2016, took 15 ms

ending call: ClsTester-20, Sun Apr 24 14:27:57 CEST 2016, took 17 ms

ending call: ClsTester-6, Sun Apr 24 14:27:57 CEST 2016, took 21 ms

ending call: ClsTester-22, Sun Apr 24 14:27:57 CEST 2016, took 14 ms

ending call: ClsTester-2, Sun Apr 24 14:27:57 CEST 2016, took 24 ms

ending call: ClsTester-19, Sun Apr 24 14:27:57 CEST 2016, took 21 ms

ending call: ClsTester-12, Sun Apr 24 14:27:57 CEST 2016, took 20 ms

ending call: ClsTester-3, Sun Apr 24 14:27:57 CEST 2016, took 27 ms

ending call: ClsTester-23, Sun Apr 24 14:27:57 CEST 2016, took 23 ms

ending call: ClsTester-17, Sun Apr 24 14:27:57 CEST 2016, took 22 ms

ending call: ClsTester-7, Sun Apr 24 14:27:57 CEST 2016, took 31 ms

ending call: ClsTester-21, Sun Apr 24 14:27:57 CEST 2016, took 27 ms

ending call: ClsTester-9, Sun Apr 24 14:27:57 CEST 2016, took 30 ms

ending call: ClsTester-8, Sun Apr 24 14:27:57 CEST 2016, took 31 ms

ending call: ClsTester-16, Sun Apr 24 14:27:57 CEST 2016, took 28 ms

ending call: ClsTester-5, Sun Apr 24 14:27:57 CEST 2016, took 32 ms

ending call: ClsTester-0, Sun Apr 24 14:27:57 CEST 2016, took 34 ms

ending call: ClsTester-10, Sun Apr 24 14:27:57 CEST 2016, took 31 ms

ending call: ClsTester-15, Sun Apr 24 14:27:57 CEST 2016, took 32 ms

ending call: ClsTester-1, Sun Apr 24 14:27:57 CEST 2016, took 37 ms

In our sample scenario the numbers are quite low, but in our productive system the cycle time is soaring. 

A call that takes avg. 40ms in our EIS behind the JCA facade quickly rises to 300-500ms which is a serious problem.  

Do you have some ideas to research into the problem? 

We also have a working sample code that we can provide very quickly. How can I send it to you?

Kind Regards,

Dennis 

[Stefano Maestri]

​Hi Dennis,

please send me the sample code w/ detailed instruction to run it and get the performance issue and I'll try to dig into. You can use my email visible as sender in this post.

regards

S.​

--
You received this message because you are subscribed to the Google Groups "IronJacamar Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ironjacamar-us...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.