Jboss performance

[twutort]

Hello,

I'm doing some testing for my company to determine if we should switch to JBoss over Weblogic. I'm runnig the same application with the in the same environment on both servers. It seems that Weblogic is outperforming JBoss by a lot.

A lot of our http request are timing out with a lot less load than we are running on Weblogic. We can't even get 50 users to run that well on JBoss. I've changed a lot of configuration options, Everything from changing the commit options to running the entity beans under the Instance Per Transaction configuration. Besides some changes we made to run on the JBoss platform we are running the same exact queries on both servers. We use about 60% beans and 40% straight JDBC calls.

I need to file my report in the next week. Are there any configuration options I may be able to try that would help? I've tried commit option B and it seems to run slower than with A, for obvious reasons. So then I tried to configure my beans using the Instance Per Transaction configuration and that got worse results. I've read through the documentation I have and can't seem to find any other settings that would help. I'm a fan of JBoss but we won't be able to switch unless I can prove that the same code on JBoss will run the same load under the same conditions. Any suggestions would be appreciated.

Thanks,
Tim

[nickman]

Bill Burke posted a very useful disertation on tuning for performance here: http://jboss.org/jbossBlog/blog/bburke/?permalink=Optimizing+JBoss%3A+Experiences+with+SPECj2002.html

More information on exactly what you are seeing would be helpful.

Also consider the following:

1. Review your Tomcat configuration. There is nearly always room for optimization there, and the defaults are not universally adequate.
2. Some obvious things like Xms and Xmx settings.......make sure you are giving JBoss enough RAM.
3. Post your descriptors. Perhaps it will jog something.

Cheers.

//Nicholas

[triathlon98]

Simple note, but do compare them both using the same JVM.

[marc.fleury]

hey twutort,

it is difficult to optimize out of the blue wihtout knowing your app and what it does, there is no secret formula or we would call it the "run faster" button which would come pre-pressed :)

that being said a big discrepancy between JBoss and BEA IS NOT NORMAL. And something really silly is usually going on. JBoss well tuned runs faster than BEA in RFP's we participate in as JBoss inc. Did you read the bill stuff? do you have time to go to training? I would hate to see you make the wrong decision for you and your companie's dollars for lack of time.

Good luck anyway

[twutort]

Hello, thanks for all your post. I realize that without knowing my configuration you can't help me out. I was just hoping someone could steer me towards some articles or point me to something I may need to look into. I'm going to check out the link above. I appreciate all the help. As far as training I'm not being sent to training. I'm pretty much on my own.

The only thing I'm seeing now is that when I run a lot of users our load test is timing out beause we have the timeout on the script set to 120 seconds. So the more users we get the longer it is taking to get a return to our script. We consider that a failure.

[slaboure]

Are you sure this is not a CMP configuration issue?

[twutort]

We have also paid for JBoss support. So far they have been unable to help me.

Just some simple configuration notes without getting into a lot of detail. We are using JRockit 8.1 to run. We are also using SQL 7 to test. The database sits on another server. We are running both weblogic and JBoss on a server with a dual CPU and 512 MB of RAM. I've adjusted the heap size and have noticed some difference in speed, but not a lot. Is there any suggested JVM to run with JBoss? We are using JBoss version 3.2. Thanks.

[twutort]

We are using BMP. JBoss support advised me to try the Instance Per Transaction configuration. It did help but still didn't get me up to the speed of Weblogic. I really prefer JBoss so I'm going to read the article that was posted above and see if it helps. Thanks.

[bill.burke]

Hey, that article I wrote was for use with commit option 'b' or 'c'. If you are fine with no caching, then read that article.

But, that being said, you really need to analyze PER Entity Bean your caching, locking, and tuning strategies as each Entity has different requirements.

Bill

[bill.burke]

One more thing, Instance Per Transaction can only be run with Commit B or C.

[bill.burke]

Sorry, one more thing.....

Use JBoss 3.2.3 or higher. Alex Loubyansky did a huge amount of performance improvements in the CMP engine. Adrian and I did a lot of improvements in the datapooling and Local Interfaces area.

Bill

[twutort]

Thanks! We had some locking issues in the past and we used the Instance Per Transaction configuration to clear it up. I can overwrite the global commit option by placing a commit option in each descriptor for an entity bean, correct?

[twutort]

I updated my JBoss version to 3.2.3. I also implemented most of the changes on the link from Bill Burke. It seems to be a little faster by not by much. Is there any suggestions you having for speeding up JDBC calls outside of beans? I added the <prepared-statement-cache-size> to my datasource and set it to 100. JDBC calls seem to be our biggest problem. Thanks.

[amayingenta]

You might want to check the JDBC calls that the CMP engine (turn on DEBUG logging for the CMP engine in conf/log4j.xml - there should be examples of how to do this elsewhere in the forums).
It's possible that JBoss is not making the same calls as WebLogic was, and you may need to tune the queries (extra indexes etc) it uses.

[twutort]

I've implemented a lot of these suggestions and they have made performance better, thanks! I'm still a little worried about JBoss. I can run a test with the same amount of users I'm running on Weblogic and it works fine. I simply restart the server with the same configuration and sometimes it will not handle the load at all and throw a lot of errors. I have to give a report this week so hopefully I can get it stable by the end of the week.