• Post Reply Bookmark Topic Watch Topic
  • New Topic

Application Server vs JUnit Performance Issue  RSS feed

 
Ted Rodgers
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All

I have a J2EE application running on JBoss 4.0.2, with what appears to be a very serious performance issue, possibly EJB related?:

When I run the application whilst running in JBoss, a thread is invoked, which in turn uses a Session Bean to invoke a class (POJO) on the business tier.

When the performance of the the business class is measured (the time it takes to execute from start to finish) while running in JBoss, there is about a 65% overhead when compared to invoking the class directly from a JUnit test (the JUnit test

bypasses the thread and EJB and invokes the class on the business tier directly). This equates to the JUnit test running the business class approximately 3 times faster than when it is running in JBoss.

The question is, is there a performance issue with EJBs running in application servers/containers or could this be a JBoss running threads or/and EJBs issue?, or could it be a general application server vs. standalone Java application issue?

Many thanks.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Welcome to JavaRanch!

First, a bit of business: you may not have read our naming policy on the way in. It requires that you use a full, real (sounding) first and last name for your display name. Obviously fake names, nicknames and "handles" aren't acceptable at the Ranch. You can change your display name here. Thanks!

Now, as to your question: there is a lot of overhead associated with running in an app server; much of it is just the time it takes for the remote method call to be marshalled, transmitted, and unmarshalled. As a percentage of business method time, it obviously will seem worse for tiny methods than it would for more substantial ones.

But in any case, it isn't really a fair comparison to compare a direct method call to a remote one, because, obviously, there's some essential overhead just to doing the network transmission itself. A more fair comparison would be between app servers, or EJB vs. SOAP vs. straight RMI.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:
But in any case, it isn't really a fair comparison to compare a direct method call to a remote one, because, obviously, there's some essential overhead just to doing the network transmission itself.


Well, it is fair in the sense that it should make you think very hard about whether you actually *need* the remote method call.

That is, why are you using EJBs, anyway? Do you have a really good reason for that?
 
Ted Rodgers
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks.

I appreciate there will be an overhead for remote method calls, but I am taking timings for the execution (start to finish) of the business class itself, not how long it takes to invoke it.
 
Rahul Mahindrakar
Ranch Hand
Posts: 1869
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

Please note that if the client for the ejb is located within the application server then it could be possible that there is no remote call. This is the case at least in BEA Weblogic which "optamizes" this.

I am not sure what type of client accesses the EJB. Is it a servlet or a JSP or a Java Application.

Plus the fact how you are testing this is the testing "in container" or from "outside the container".
 
Ted Rodgers
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rahul Mahindrakar,

The JUnit test is ran from outside the container i.e. the test is ran on the application before it is deployed.

Thanks
 
Paul Clapham
Sheriff
Posts: 22509
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ted Rodgers:
The JUnit test is ran from outside the container i.e. the test is ran on the application before it is deployed.
So you are comparing two applications that are running on different machines, in different environments, with different applications running on them. Quite likely the difference can be attributed to one or more of those differences.
 
Ted Rodgers
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is only one application, which is being run and tested on 1 machine.
 
Rahul Mahindrakar
Ranch Hand
Posts: 1869
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ted

My basic contentention is as follows

1) If you are undertating the tests "outside the container" which would mean that a Java client ->> EJB then there is a remote call existing

2) If however you are undertaking a test from a Java Client like a Servlet which is "in container" -> POJO then there is no remote call.

Could this be the reasons for the performance statistics is the question.
[ July 17, 2006: Message edited by: Rahul Mahindrakar ]
 
manuel aldana
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
some stuff to get it right:

-your business class is a POJO?
-what is it doing, does it call any other classes/objects, maybe it calls database or similar? if so, are you overcoming these couplings (mocks, stubs), when testing outside container?
-how do you measure: with getTimeMillis() directly in your POJO or with a profiler? are you doing this same measuring both out and in-container?
-your measurements ONLY takes the time between POJO-method entry and exit (i.e. no EJB-time involved, no network stack etc.)

some (unlikely) guesses:
-wrong heap settings of appserver: gc slows down application.
-appserver is busy with other heavy-running or parallel running parts of your app: so it cannot spend all resources for your POJO.

without more information about source/design, no idea, what it could be else...


besides some other tips:
why do you think this POJO is the application bottleneck? you should try a profiler which measures execution time of one of your use-cases (e.g. interface methods of your facade). and then incremently find out the bottleneck.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!