wildfly-8.0.0.Final vs. jboss-eap-6.2 performance

[cstillwell]

We have an environment where server A calls server B which calls server C.  I have been running parallel tests between wildfly-8.0.0.Final and jboss-eap-6.2.  A set of tasks is generated each hour which are processed by 12 worker threads on server A.  In most cases the JBoss 7 environment outperforms the wildfly environment anywhere from 3% to 50% faster.  All the servers use the standalone-ha.xml configuration because normally these servers run in separate clusters.  I know that the EJB calls in wildfly are now going over http and wonder if that is where the slowdown occurs.  Has anybody else experienced this?  I did do a quick search of this forum, but didn't run across anything.

[ctomc]

Hi,

we kinda messed up default shipped settings for IO subsystem, that is going to be fixed in 8.0.1 release.

You should change IO subsystem worker settings to better match your running server.

configure it to

<worker name="default" io-threads="cpu count in your server * 2" task-max-threads="cpu count * 16"/>

This way you should get much better over all performance.

--

tomaz

[cstillwell]

Thanks, that seems to help some, but wildfly still seems slower.  Would there happen to be any other environment specific configuration options I should be looking at?

Chris

[ctomc]

You should really give us some more information on what your application is doing.

What technologies are you using and how.

As it goes for ejb remoting, it does not go over http, just initial request/response is over http, after that it is upgraded to "remoting" protocol, same as what was used in AS7.

This could cause some performance problems for you if you are always opening&closing connection to remote server for each request you are doing.

You can still configure old remoting without any http upgrade stuff, just configure ejb3 subsystem with standard connector.

[swd847]

Because of changes to the CDI spec Weld is now sometimes activated for deployments where it was not before, which can impact performance. If you application does not use weld try removing the weld subsystem from standalone.xml and see if that helps.

[gerry.matte]

It is very refreshing to see someone publicly admit they "messed up".  I appreciate your honesty Tomaz !

You set a very professional example for all of us developers who make human mistakes but may not be willing to admit it.

[cstillwell]

I removed weld from my standalone.xml configurations and that also seems to have helped.  By chance I also noticed that all of our Stateless SessionBeans were being constructed on every call.  I noticed that the standalone-ha.xml as distributed no longer defines a pool for the stateless session beans so I added the following:

<stateless>

   <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>

</stateless>

This resolved the issue of the SessionBeans being constructed on each call.

I also bumped up the max-threads count in the ejb3 subsystem to match the task-max-threads in the io subsystem which was caclulated as cpu count * 16, or in my case 128.

[ctomc]

You wouldn't need that big thread pool for ejb3 subsystem.

As goes for SLSB pooling, it was disabled by default as in many cases it was about 10-20% faster without pooling.

But that is varying factor from app to app.

In any case I doubt you need that big pool for it

Btw, how does performance compares to EAP 6.2 after all of this changes?