| < Day Day Up > |
|
This section discusses how to implement and configure the J2EE components in a BEA Weblogic application server environment.
In this section, we introduce the Pet Store sample business application and demonstrate drill down into all the business processes step by step. In addition, front-end as well as back-end reports are provided for all activities, in order to illustrate how IBM Tivoli Monitoring for Transaction Performance Version 5.2 standard components can be applied to a Weblogic environment to:
Measure real-time Web transaction performance
Measure synthetic end-user time
Identify bottlenecks in the e-business processes
This section contains the following:
8.8.1, "The Java Pet Store sample application" on page 308
8.8.2, "Deploying TMTP components in a Weblogic environment" on page 310
8.8.3, "J2EE discovery and listening policies for Weblogic Pet Store" on page 312
8.8.4, "Event analysis and online reports for Pet Store" on page 316
The WebLogic Java Pet Store application is based on the Sun Microsystems Java Pet Store 1.3 demo. The Java Pet Store 1.3 is a J2EE sample application. It uses a combination of Java and J2EE technologies, including:
The JavaServer Pages (JSP) technology
Java servlets, including filters and listeners
The Java Message Service (JMS)
Enterprise JavaBeans, including Container Managed Persistence (CMP), Message Driven Beans (MDB), and the EJB Query Language (EJB QL).
A rich client interface built with the Java Foundation Classes (JFC) and Swing GUI components
XML and Extensible Style Sheets for Transformation (XSLT), a reusable Web application framework.
The welcome dialog is provided in the window shown in Figure 8-57 on page 309, and technical details are available at:
Figure 8-57: Pet Store application welcome page
http://java.sun.com/features/2001/12/petstore13.html
The Pet Store application uses a PointBase database for storing data. It will populate all demonstration data automatically when an application is run for the first time.
Once installed, you can log in to Weblogic Administration console (see Figure 8-58 on page 310) to see details for the Pet Store application components and configuration.
Figure 8-58: Weblogic 7.0.1 Admin Console
To start the Pet Store application from the Windows Desktop, select Start → Programs → BEA Weblogic Platform 7.0 → Weblogic Server 7.0 → Server Tour and Examples → Lunch Pet Store.
The deployment of the IBM Tivoli Monitoring for Transaction Performance Version 5.2 Management Agents and monitoring components is similar to the procedures already described for deployment and configuration in a WebSphere Application Server environment. Please refer to the following sections for the specific tasks.
4.1.4, "Installation of the Management Agents" on page 130
8.4, "STI recording and playback" on page 241
8.5, "Quality of Service" on page 257
8.6, "The J2EE component" on page 278
Table 8-3 provides the details of the Pet Store environment needed to configure and deploy the needed TMTP components, and Figure 8-59 shows the details of defining/deploying the Management Agent on a Weblogic 7.0 application server.
Figure 8-59: Weblogic Management Agent configuration
Field | Default value |
---|---|
Application Server Name | petstoreServer |
Application Server Home | c:\bea\weblogic700 |
Domain | petstore |
Java Home | c:\bea\jdk131_03 |
Start with Script | check |
Domain Path | c:\bea\weblogic700\samples\server\config\petstore\ |
Path and file name | c:\bea\weblogic700\samples\server\config\petstore\startPetStore.cmd |
After successful installation of the Management Agent onto the Weblogic application server, the next steps are creating the agent groups, schedules, and discovery and listening policies.
For details on how to create discovery and listening policies, please refer to 8.6.2, "J2EE component configuration" on page 282.
We have created discovery policy petstore_j2ee_dis with the following configuration capturing data from the Pet Store application that generated by all users:
URI Filter | http://.*/petstore/.* |
User name | .* |
In addition, a schedule for discovery and listening policies has been created. The name of the schedule is petsore_j2ee_dis_forever, and it runs continuously.
Note | Before creating the listening policies for the J2EE applications, it is important to create a discovery policy and browse the Pet Store application and generate some transactions. |
The J2EE listening policy named petstore_j2ee_lis has been defined to listen for Pet Store transactions to the URI http://tivlab01.itsc.austin.ibm.com:7001/petstore/product.screen?category_id=FISH, as shown in Figure 8-60 on page 313.
Figure 8-60: Creating listening policy for Pet Store J2EE Application
The average response time reported by the discovery policy is 0.062 seconds (see Figure 8-61 on page 314).
Figure 8-61: Choose Pet Store transaction for Listening policy
A threshold is defined for the listening policy for response times 20% higher than the average reported by the discovery policy, as shown in Figure 8-62.
Figure 8-62: Automatic threshold setting for Pet Store
To define a QoS listening policy for the Pet Store application (pestore_qos_lis), we used the following transaction filter:
http:\/\/tivlab01\.itsc\.austin\.ibm\.com:80\/petstore\/signon_welcome\.screen.*
Settings for the Back-End Service Time threshold are shown in Figure 8-63.
Figure 8-63: QoS listening policies for Pet Store automatic threshold setting
In addition, we provided the J2EE settings for the QoS listening policy shown in Figure 8-64 on page 316 in order to ensure correlation between the QoS front-end monitoring and the back-end monitoring provided by the J2EE component.
Figure 8-64: QoS correlation with J2EE application
If we analyze the Pet Store business process from login to submit from the Pet Store Web site, we have a total of nine steps:
Log in to Pet Store site
Select pet
Select product category
Select/view items for this product category
Add to cart
View the shopping cart
Proceed to checkout
Supply order information
Submit
We want to find the User Experienced Time and the Back-End Service Time for end-users buying pets the e-business way. Since we cannot control the behavior of users, STI is used to run the same transaction consistently.
To facilitate this, an STI playback policy is created to run a simulated Pet Store transaction named petstore_2_order. Petstore_2_order is configured to allow correlation with the back-end J2EE monitoring.
The Transaction with Subtransaction report shown in Figure 8-65 shows that the total simulated end-user response time for Pet Store playback policy is 8.12 sec. It also shows that five subtransactions has been executed, and that subtransaction number 3 is responsible for the biggest part of the total response time. This report is very helpful to in order to identify, over a longer period of time, which subtransaction traditionally contributes most to the overall response time.
Figure 8-65: Pet Store transaction and subtransaction response time by STI
From the Page Analyzer Viewer report shown in Figure 8-66 on page 318, we can see that the enter_order_information_screen subtransaction takes longer (2.4 seconds) to present the output to the end user. By using Page Analyzer Viewer, we can find out (for STI transactions) which subtransactions take a long time and what type of function is involved. Among the functions that can be identified are:
DNS resolution
Connection
Connection idle
Socket connection
SSL connection
Server response error
Figure 8-66: Page Analyzer Viewer report of Pet Store business transaction
The topology view in Figure 8-67 on page 319 shows how the STI transactions propagates to the J2EE Application Server and shows the parent/child relationship with the Pet Store simulated transaction and various J2EE application components.
Figure 8-67: Correlation of STI and J2EE view for Pet Store application
With respect to the thresholds defined for the QoS and J2EE listening policies in this scenario, we see from Figure 8-68 on page 320 (the aggregate topology view) that threshold violations have been identified and reported (Most_violated) in the report.
Figure 8-68: J2EE dofilter() methods creates events
We want to identify the performance characteristics of different J2EE application components (such as Pet Store JSP, Servlets, EJB, and JDBC) during business hours, especially during peak hours. In addition we want to identify the application's bottleneck and the component responsible in order to figure out if the application is under- or over-provisioned. Furthermore, we want to find the real Back-End Service Time for all back-end components and the Round Trip Time for an end-user.
A J2EE listening policy is created and named petstore_j2ee_lis to capture specific Pet Store business transactions.
A QoS listening policy is created and named petstore_qos_lis to capture the real response time with the J2EE application components response for specific transactions against the Pet Store site.
Please refer to 7.1, "Reporting overview" on page 212 for details on how to use the online reports in IBM Tivoli Monitoring for Transaction Performance Version 5.2.
From the J2EE topology view shown in Figure 8-69, we see that SessionEJB indicates an alert. If we drill down in the SessionEJB, we realize that the getShoppingClienFacade method is responsible for this violation, as shown in see Figure 8-70 on page 322.
Figure 8-69: Problem indication in topology view of Pet Store J2EE application
Figure 8-70: Topology view- event violation by getShoppingClientFacade
From the topology view, we can jump directly to the Response Time View for the particular application component, as shown in Figure 8-70 on page 322, in order to get the report shown in Figure 8-71 on page 322.
Figure 8-71: Response time for getShoppingClienFacade method
Finally, the real-time transaction performance (total Round Trip Time and Back End Service Time) of the Pet Store site, as well as J2EE components response time, are shown in Figure 8-72.
Figure 8-72: Real-time Round Trip Time and Back-End Service Time by QoS
| < Day Day Up > |
|