Analyzing Performance in Enterprise JavaBeans
Analyzing performance is probably one of the most complex tasks in designing any application. It’s an imprecise science because there are many factors that come into play. These are augmented in Enterprise JavaBeans (EJB) applications, where performance largely depends on the implementation of the EJB container you use. The bottom line is that you can’t know if you’re making the right performance decisions until you test them.
Following are some issues that you should keep in mind when considering performance issues:
- Not all EJB containers are created equal. While each EJB container must conform to the EJB specification, vendors have wide latitude in implementing the EJB container. Their requirements focus on the outcomes of operations, not on an operation’s efficiency. Some vendors will do a better job with different portions of an EJB container. You must determine where efficiencies can be gained in an EJB container and where performance bottlenecks are going to occur. The only way to know that with certainty is to try before you buy. Even after you purchase a solution, major design decisions, such as whether or not to use EJB entity beans, should be tested.
- Performance can depend on the efficiency of your application. There are general rules that you can use to help determine which application designs are better than others. But these guidelines can be easily invalidated with a sloppy implementation. The best way to ensure you avoid sloppy implementations is to perform regular code reviews — that’s when you sit around with all your coding co-workers and have them review your work — during your EJB project. You should focus your code reviews on analyzing the source and ensuring that it’s both well designed and efficient. Code reviews offer a great opportunity for programmers to learn from each other.
- Develop a prototype to test your performance assumptions. Here’s a sample scenario. As an EJB application developer, you should decide early on whether or not to use entity beans to manage interaction with a database. Your two basic choices are to
• Create entity beans to manage database interaction. Entity beans can simplify your database interaction from an application programming perspective. But they can also exact a performance penalty. Some of that penalty can be controlled in the way that you implement entity beans — that is, by using local interfaces versus remote interfaces or by making entity beans coarse-grained objects.
• Code JDBC database calls directly into session beans and avoid the use of entity beans altogether. JDBC can be more difficult to work with than using entity beans with container-managed persistence. This course may also undermine your ability to take advantage of EJB container-managed transactions.
To determine which of the two courses is more appropriate, you can perform a simple test:
1. Create an entity bean and a session bean that both perform operations on the same set of data from a database.
2. Write a simple program that measures the amount of time required to invoke a set of inserts, updates, queries, and changes to the database.
This second program should invoke the session bean for one test and the entity bean for another test — performing the same set of operations on each.
3. Analyze the results to determine whether performance will be an issue.
If you want a more fine-grained performance analysis, you can time individual steps — to identify the most expensive operation — and then try modifying those operations to generate performance gains.
For an entity bean, you may want to measure performance on the following operations:
- How long does it take to obtain a reference to a remote interface or a local interface?
- What’s the difference in performance between performing an update on a remote interface and a local interface?
- What’s the difference between updating multiple rows in a database in JDBC and performing an update on multiple rows using the home method of an entity bean?
The answers to these questions will be different from EJB container to EJB container and will also be influenced by: a) the JDBC driver you choose; b) whether or not you use database connection pooling; and c) the efficiency of your implementations of the entity bean and the session bean. You will probably be surprised by some of the results you get — tests like these have a way of challenging your assumptions about the performance of entity beans.
When you’re tuning an EJB for performance, don’t make random changes. Instead, focus your attention on the steps in the application that cost the most in terms of performance.
Note:Performance measurements usually reveal that a business process has only one or two points where significant improvements can be made. This observation has been made often enough that it led to the creation of the Pareto 80-20 rule. That rule states that 80 percent of the execution time of a program is due to 20 percent of the code. Your goal should be to identify which 20 percent of the code is most expensive in terms of system resources and focus on optimizing that portion.