J2EE Performance Tuning
- What Is Performance Tuning?
- What Can You Tune?
- Summary
- What's Next?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Java 2 Enterprise Edition, or J2EE, has become one of the great buzzwords and acronyms of recent years. Although many can use the term in conversation, few can develop its applications and even fewer can develop its applications properly. J2EE itself is a collection of specifications for various technologies, including the familiar Servlets and JavaServer Pages (JSP) as well as Enterprise JavaBeans (EJBs) and the entire infrastructure to support building an enterprise application. Several implementations of the specifications exist in products such as the following:
- BEA WebLogic
- IBM WebSphere
- Oracle Application Server
- JBoss
Like any technology, there is an art in architecting a robust and scalable application that performs optimally, and there is an art in tuning the environment in which the application is to run. Uncovering this art is an exercise in application analysis, infrastructure analysis, and a considerable amount of run-time observation.
This is the first in a series of articles focused on the performance tuning of J2EE applications and application servers. This article introduces you to performance tuning, discusses what it means in the context of a J2EE application, and identifies the tunable facets in a J2EE environment.
What Is Performance Tuning?
Before diving in to tuning J2EE applications and their underlying application servers, we need to quantify what performance tuning means, which may be different to different people. For the purposes of this discussion, the goal of performance tuning is to maximize
- Concurrent users
- Throughput
- Reliability
In other words, we want to service more users faster and not break down in the process (see Figure 1).
)
Figure 1 Performance tuning overview.
When company employees deploy an application and it does not meet performance service level agreements (SLAs), where do they start tuning? When do they determine to add more hardware? When can they just adjust a couple of application server parameters and get twice the performance improvement they would have if they had doubled their hardware?
Sadly, if most companies see their application performing poorly knowing that it was properly architected, they throw more hardware at it. This improves performance, but increases the maintenance cost and complexity of the hardware architecture (not to mention the cost incurred by software licenses and the physical hardware itself!).
Your goal will be to squeeze every last bit of performance out of your applications and application servers before adding more hardware to the environment. Adding hardware is rarely a good long-term solution: It may patch the symptoms of the current problem, but the problem will nonetheless still exist and may manifest itself when the load yet again increases.
Concurrent Users
You will load test the application running in your application server and estimate the number of concurrent users it can support before requests start failing and/or the response time does not meet your requirements. Response times can be defined by Service Level Agreements, or SLAs, which specify the maximum time that a request can take before it is considered unacceptable. The important thing when load testing an application is to ensure that you have representative transactions that reflect the real use of your application. In the end, you will tune your application to support the simulated load; if it is not representative, there are no guarantees that your application will stand up to real users.
Throughput
The throughput of an application and application server can be reported as the number of transactions performed per second. It is a measure of the internal health of both the application server and application and under load indicates the capacity of the server. Your goal is to maximize the throughput of the server, again by properly tuning both the application and application server.
Reliability
Not only must your applications support the maximum number of users and respond in an acceptable time period, it must minimize the number of failed requests. All web servers will have some level of fallout, mostly due to network latency or timeouts (even Yahoo occasionally returns a "Try again in 10 minutes" message), but a major portion of our tuning efforts is in ensuring that the user receives the information he requests.