Home > Articles > Programming > Java

J2EE Performance Tuning, Part 2

  • Print
  • + Share This
Steven Haines details a robust tuning methodology that you can use to tune your J2EE applications and application servers. He describes the process of generating a load on your application server and lists what performance metrics you need to observe in your J2EE environment (as well as ways to get them).
From the author of

From the author of

Whether it is tuning a J2EE application, a database, or your own custom-built architecture, it is always best to start by defining the methodology that you will use, analyzing that methodology to ensure that it accurately solves your problem, and determining the requirements of that methodology. Although the first article in this series introduced you to J2EE performance tuning and the goals in tuning a J2EE environment, this article defines a tuning methodology you can use in your environment and the information you will need to apply this methodology.

Recall (from the previous article) that our goals in performance tuning are to maximize current users, throughput, and reliability through the systematic tuning of our application, application server, platform, and external dependencies.

Methodology Defined

I wish I could tell you that tuning a J2EE environment is as easy as adjusting a few parameters to specific values that I can list in one small table; unfortunately, it is far more complex and requires an intimate knowledge of your application as well as the way users will use your application. Figure 1 shows the entire tuning environment and methodology workflow graphically.

Figure 1Figure 1 Tuning methodology overview.

The first thing we need to look at is the user; we need to answer the following question: How will the user use my system? The answer will lead to a set of transactions that we can apply to the system (the term transaction in this context refers to a set of requests made by a user). Note that these transactions must be representative of expected end-user transactions because we will tune our system specifically to support these transactions!

Next, we need to generate these transactions inside the context of a load tester that can control such things as number of simultaneous users, think time, startup delay, and so on.

Once we have a load of users testing our application, we need to gather runtime performance metrics from the following sources:

  • Application
  • Application server
  • Underlying platform
  • External resources

And finally, once we have all of these metrics, we need to correlate, analyze, and present them.

  • + Share This
  • 🔖 Save To Your Account