How well does your application perform? It is probably one of the toughest questions to answer accurately. It is not only a question of how many requests your application serves per second or per minute, but also how your application scales with respect to other performance metrics. It remains challenging to quantify application health quickly because there are a number of variables to consider. This article outlines the key terminologies associated with measuring Java 2 Enterprise Edition (J2EE) application performance. Importantly, this article also outlines best practices for creating a robust architecture and optimizing J2EE application performance.
When we discuss performance analysis terminology, it is not uncommon to find a variety of terms. The scope of application performance also varies depending on the application. Key performance terms follow.
RESPONSE TIME
Response time refers to the length of time required to complete a transaction. This is a primary factor for consideration from a user perspective. It is good practice to measure response time for each application component. This approach enables you to identify if a component's response time is longer than average and to look for coding or configuration problems that are causing the performance delays.
THROUGHPUT
Throughput measures application capacity, rather than user response time. It can be measured by the number of requests per second or number of pages per second that an application serves. Throughput is also measured by transactions or users per second.
SCALABILITY
Scalability denotes the ability to increase application capacity by expanding hardware and related resources that support the applications. There are two types of scalability: vertical and horizontal. Vertical scaling refers to the ability to install multiple instances on a single machine and thereby achieve maximum utilization of one machine. Horizontal scaling denotes the deployment of an application to additional computers.
These factors should be considered for current and future application uses to ensure successful deployments and expansions of new applications or services.
J2EE Application AnalysisJ2EE applications should be examined from the macro and micro perspectives to gauge application performance accurately. The micro view analyzes metrics for system-level hardware and software components to provide a granular measurement of each component. The micro perspective focuses on the application modules, classes, and methods deployed on application servers. The micro view typically includes performance analysis of J2EE components, such as Enterprise JavaBeans (EJBs), servlets, portlets, etc. The micro view enables you to calibrate each application component to ensure a high level of application performance.
Macro analysis, by contrast, takes a collective, global view of all components associated with an application. The macro view of an enterprise includes the analysis of proxy, application, and other servers. The macro analysis reflects the end user's perspective of an application's performance. A combined micro and macro analysis provides the granular component-level and broader enterprisewide perspectives required to calibrate J2EE application performance accurately to maintain a positive user experience.
J2EE Workload ManagementThe J2EE environment provides Java application programmers with a set of services used to solve business problems. There are several methods, classes, and interfaces used to leverage these services.
A workload is the set of methods invoked to satisfy a user's request. An application method calling sequence, for example, can be defined as a workload. These methods include the J2EE service classes. All workloads have well-defined start and end points.
One popular workload monitoring technique is to use logging to indicate when methods are invoked. The application using this technique would wrap any Java or J2EE method call. This simple solution, however, will not provide all of the information required to find a workload bottleneck because the J2EE services that also call other services would not be tracked.
To optimize application performance, you should tune applications based on the response times of external J2EE call behaviors in your enterprise environment. External J2EE calls to track include Java Database Connectivity (JDBC), Java Message Service (JMS), and J2EE Connector Architecture (JCA).
A standard way to instrument application performance is to deploy an agent that instruments the application byte code when the Java Virtual Machine (JVM) loads the application. Because application and J2EE classes are instrumented at load time, you need to identify specific system and application classes to instrument. Most instrumentation products use an Extensible Markup Language (XML) configuration file to identify the classes. The key with this approach is to minimize the overhead and not change the operation of the application. Therefore, care must be taken to capture only the data needed to identify bottlenecks. Most J2EE application performance monitoring vendors provide this type of instrumentation.
Advanced J2EE application performance monitoring products typically include an editor that reads Enterprise Archive (EAR), Java Archive (JAR), and Web Archive (WAR) files to simplify this task. You identify what you want to instrument, and the editor creates the XML file for you. This approach is optimal because most application projects involve teams of Java developers. These teams build their own classes, which may not be visible to the person doing the system performance testing. Naturally, J2EE resource classes are instrumented automatically for reporting.
You must also be able to turn this feature on and off at will. If an application was deployed and tuned to eliminate performance problems six months ago, this level of application performance monitoring is not currently necessary. However, you must be able to reload instrumentation tools onto applications that require workload monitoring to pinpoint the cause of application performance problems in the future.
Workload analysis is a powerful technique that can be used to quickly identify J2EE application bottlenecks. Key response-time measurements you should track include servlets, JavaServer Pages (JSPs), portlets, EJBs, and user-defined workloads. Further, J2EE application server components to track include CICS Transaction Gateway (CTG), Java Transaction APIs (JTA), JCA, JMS, Java Naming Directory Interface (JNDI), and Open Database Connectivity (ODBC) services. Allowing an application programmer to drill deeper into specific workloads to identify specific delays will help accelerate the identification and elimination of performance bottlenecks.
Case StudyOrganizations are continually working to streamline their procurement processes to increase the level of service to customers and partners. The example highlights an organization's Web site that provides customers with online access to an automotive parts catalog system. The organization used multiple design patterns to implement a consistent, well-understood architecture that streamlines operations and provides consistent J2EE application performance. The company deployed a Model View Controller (MVC) architecture to process order requests. Responses were processed using MVC JSPs that provide the appropriate data in Web browser responses (see Figure 1).
This system is supported by a strong EJB back-end system. That system managed the shopping cart, catalog, credit check, and pricing. Once customers have purchased their items, the system would send requests to an EJB workflow architecture component of the J2EE order fulfillment system.
Figure 2 illustrates the back-end system used to process customer orders. This represents a common application used today by Internet shoppers. Multiple design patterns were used to provide a consistent architecture. Design patterns include:
- Session facade for routing EJB requests
- Value object to pass data between the Web and EJB container
- Data access object to manage the catalog
Workload analysis instruments the JDBC drivers that have been loaded as system classes. This instrumentation captures dynamic and static Standard Query Language (SQL) commands. Several types of information can be made available using byte-code instrumentation. For example, an application developer can identify the longest-running workloads (see Figure 3). An SQL update is responsible for most of the time spent in this workload. Through more detailed analysis of the workload, the application developer would be able to identify the specific method making this SQL call. Developers that focus on workload delays in system classes are well positioned to identify and eliminate complex performance delays.
The "Ten Worst Average Response Times" graph quickly identifies the longest-running workload. The color-coded bar segments the graph into distinct system and user delays. The graph at the top of the screen and the table below clearly define the cause of the performance problem. In this case, SQL created the performance bottleneck. Further analysis is required to identify the source of the SQL delay. By drilling into the specific workload, you can see the specific method and SQL statement that caused the performance slowdown.
In the drill-down display, you see the specific method within the database update EJB that caused the delay. It identifies the specific method name, along with the corresponding SQL statement. You can use this information to optimize the SQL statement or change the database table to increase performance. Once the change is made, you can reload the application to instrument the changed method and verify the desired results. The same technique can quickly identify any performance bottleneck within a J2EE application.
ConclusionToday's J2EE application servers and corresponding testing tools provide robust functionality that simplifies application development and performance management. Design patterns used for architecture and detail implementation can minimize design and deployment missteps that can cause applications to perform poorly or not have the flexibility to address emerging business requirements. To tune J2EE applications properly, you should strongly consider tools that show specific workload delays and also enable you to drill down to the code level and eliminate the source of the bottleneck.
|
