aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes A question on EJBs and Performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "A question on EJBs and Performance" Watch "A question on EJBs and Performance" New topic
Author

A question on EJBs and Performance

Andres Delrotti
Ranch Hand

Joined: Aug 11, 2005
Posts: 137
Hi everyone,

Currently, we have an application that makes use of EJBs, Stateless Session Beans to be more specific. It has a web component deployed in an application server and the ejb component is deployed in another application server. The web component remotely calls the ejb deployed in the other application server (through CORBA). Recently, there has been performance issues on the application that restarting the server would be the only solution to fix it. It had been recommended before that the web and ejb component of the application be consolidated in a single app server to possibly fix the performance issues. The two components (web and ejb) would just be combined into a single WAR file thus eliminating the use of EJBs. It would now just be a simple call to a business object.

My question is, would this really improve the performance? or what better solution would you recommend?

Thanks and I would appreciate your inputs on this.
Prabaharan Gopalan
Ranch Hand

Joined: Oct 16, 2009
Posts: 66

As I see it, there are three things where things could slow down.
1. Web
2. EJB
3. Communication between 1 and 2.

Unless bulk of the time is spent on 3, combining 1 and 2 wouldn't give you much of an improvement. And typically we would profile each of these individually and then attempt to fix it.

All the above not withstanding, if you can invest in rewriting your code, please do by all means.


Googling doesn't make you a genius. But not Googling makes you dumber.
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 468
    
    1

Hi Andres,

project I'm currently working on was originally thought in a very similar architecture to yours. The basic idea was to expose on a single node the 'web stuff' (I mean servlet, web pages and so on) and let web tier classes work with the 'business layer' deployed on 1 or more server. Since in the project startup phase a multi-server configuration would have been oversized, we build up project keeping WAR and EJB separated, but they were actually deployed on the same appserver instance. This scenario led us to poor performance; so we merged projects in a single EAR and started using only local interfaces (we were using EJB 2.1). Of course, the more data were exchanged between layers, the more performance gain was noticed, since the bottleneck was mainly CORBA / RMI serialization.

Removing EJBs may be or not a good idea. Why you were suggested to use POJOs instead of EJBs as business objects ? I can guess it's for avoiding XA transactions...


Andres Delrotti
Ranch Hand

Joined: Aug 11, 2005
Posts: 137
Claude Moore wrote:Hi Andres,

project I'm currently working on was originally thought in a very similar architecture to yours. The basic idea was to expose on a single node the 'web stuff' (I mean servlet, web pages and so on) and let web tier classes work with the 'business layer' deployed on 1 or more server. Since in the project startup phase a multi-server configuration would have been oversized, we build up project keeping WAR and EJB separated, but they were actually deployed on the same appserver instance. This scenario led us to poor performance; so we merged projects in a single EAR and started using only local interfaces (we were using EJB 2.1). Of course, the more data were exchanged between layers, the more performance gain was noticed, since the bottleneck was mainly CORBA / RMI serialization.

Removing EJBs may be or not a good idea. Why you were suggested to use POJOs instead of EJBs as business objects ? I can guess it's for avoiding XA transactions...




Thanks for the response Claude. Two questions...

1. In your project, how was it proven that the bottleneck was in CORBA/RMI serialization? Thats actually my answer to your question on why we are planning to convert it to POJOs instead. We think its because of CORBA although we still have to prove it.

2. Your response made me think on other possible options

a. Single ear using POJO
b. Single ear using local interface EJB
c. WAR and EJB as separate projects but in same server.

Could these three have different effects in performance? If yes what do you think causes it? Surely, every option is used for a specific purpose but thats still kinda unclear to me....like when is it necessary to use a, b or c? or when is using a be better than using b and vice versa.





Andres Delrotti
Ranch Hand

Joined: Aug 11, 2005
Posts: 137
Prabaharan Gopalan wrote:As I see it, there are three things where things could slow down.
1. Web
2. EJB
3. Communication between 1 and 2.

Unless bulk of the time is spent on 3, combining 1 and 2 wouldn't give you much of an improvement. And typically we would profile each of these individually and then attempt to fix it.

All the above not withstanding, if you can invest in rewriting your code, please do by all means.


Thanks Prabaharan. What do you think is the best way to profile number 3?
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 468
    
    1

1. In your project, how was it proven that the bottleneck was in CORBA/RMI serialization? Thats actually my answer to your question on why we are planning to convert it to POJOs instead. We think its because of CORBA although we still have to prove it.


Provided that my project is an ERP project, in which of course there are a lot of data to be passed and work on in each layer of our architecture, we did not run any performance test; we saw simply during debugging that passing data between layers involved significantly serialization of data via CORBA/RMI. We tried to use local interfaces instead of remote ones and we gained at least 80% in speed-up. Remember, the amount of data being passed was (and is) important. Maybe, if a few data are passed in your project, speed up you may gain would be negligible.


2. Your response made me think on other possible options

a. Single ear using POJO
b. Single ear using local interface EJB
c. WAR and EJB as separate projects but in same server.

Could these three have different effects in performance? If yes what do you think causes it?


I would guess that the "faster" (in terms of performance) would be solution a). Using EJBs in my humble experience always adds some overhead; another overhead is related to using transactions, which are always XA transaction with ejbs. Solution b) or c) may be the same.
Raghav Viswanathan
Greenhorn

Joined: Apr 26, 2012
Posts: 26

Hello Claude , Andres ,

As suggested by Prabaharan profiling would be a good place to start with. Yes I do agree that EJB's are heavy weight components. They come with a hefty price tag on performance but please do know that this is not the way you weigh EJB's. They are used for a reason. I will come back on that a bit later on that. When talking about EJB's and performance one culprit who eats away precious seconds is your Look up to the JNDI . a remote JNDI makes the matter even worse. See if you can use a Service locator pattern for caching the JNDI names. This would significantly decrease the look up time.

When to choose an EJB
1. Transactional system.
2. clustered environment with load balancing and fail over.


we have an application that has 10000+ java classes with 400+ ejb's. the application runs on Weblogic application server and we are heavily dependent on database(for update , insert ) of myultiple records in a transaction. We have succeeded in kepping the transaction time werll below 3 second level (maximum that is appriciated by our client).


I would still recommend profiling your actual application with EJB's and web components in different servers and see the results for various transactions as to where the applcation is taking time. I would also advise against using an EJB if you do not have the above two points at the top of your wish list.

Do let me know if you would need more help.

Thanks and regards
Raghav.V



Better late than never.
Claude Moore
Ranch Hand

Joined: Jun 24, 2005
Posts: 468
    
    1

Profiling, to detect bottlenecks, is always a good idea... I was reporting my own experience, when abandoning usage of remote intfs in favour of local ones led us to a good performance improvements, so good that we needn't make further investigation.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: A question on EJBs and Performance