Chapter 5. The ITSO EWLM scenario 133
9.12.4.142 - - [14/May/2004:14:09:50 -0400] "GET /PlantsByWebSphere/servlet/Imag
eServlet?action=getimage&inventoryID=A0001 HTTP/1.1" 200 75023
9.12.4.142 - - [14/May/2004:14:09:50 -0400] "GET /PlantsByWebSphere/servlet/Shop
pingServlet?action=shopping&category=3 HTTP/1.1" 200 8528
9.12.4.142 - - [14/May/2004:14:09:50 -0400] "GET /PlantsByWebSphere/servlet/Imag
eServlet?action=getimage&inventoryID=A0002 HTTP/1.1" 200 70368
9.12.4.54 - - [14/May/2004:14:09:50 -0400] "GET /trade/app?action=home HTTP/1.1"
200 13415
9.12.4.142 - - [14/May/2004:14:09:50 -0400] "GET /PlantsByWebSphere/servlet/Imag
eServlet?action=getimage&inventoryID=A0003 HTTP/1.1" 200 74635
9.12.4.54 - - [14/May/2004:14:09:50 -0400] "GET /trade/app?action=account HTTP/1
.1" 200 3057
9.12.4.142 - - [14/May/2004:14:09:50 -0400] "GET /PlantsByWebSphere/servlet/Imag
eServlet?action=getimage&inventoryID=A0004 HTTP/1.1" 200 77269
9.12.4.142 - - [14/May/2004:14:09:50 -0400] "GET /PlantsByWebSphere/servlet/Imag
eServlet?action=getimage&inventoryID=A0005 HTTP/1.1" 200 76553
We created a simple shell script named analyzelog as shown in Example 5-3. It extracts and
prints out the context root, servlet name, and action parameter in tab-delimited format from
the IBM HTTP Server access log file.
Example 5-3 The analyzelog script
#!/bin/sh
LOGFILE=$1
awk '/?/{print $7}' ${LOGFILE} |
perl -pe 's//([^/]*)/([^?]*)?.*action=([^&]*)&?.*/$1t$2 $3/' | sort | uniq
exit 0
Example 5-4 shows how the analyzelog script works. We found that we can separate work
requests by context root and action parameter, instead of servlet name.
Example 5-4 Extracting context root, servlet name and action parameter
[root]# ./analyzelog access.log
PlantsByWebSphere servlet/AccountServlet account
PlantsByWebSphere servlet/AccountServlet login
PlantsByWebSphere servlet/AccountServlet register
PlantsByWebSphere servlet/ImageServlet getimage
PlantsByWebSphere servlet/ShoppingServlet gotocart
PlantsByWebSphere servlet/ShoppingServlet initcheckout
PlantsByWebSphere servlet/ShoppingServlet orderinfodone
PlantsByWebSphere servlet/ShoppingServlet productdetail
PlantsByWebSphere servlet/ShoppingServlet register
PlantsByWebSphere servlet/ShoppingServlet shopping
trade app account
trade app buy
trade app home
trade app logout
trade app portfolio
trade app quotes
trade app register
trade app sell
trade app update_profile
134 IBM Enterprise Workload Manager
After that, we look into which action parameter corresponds to which customer transaction in
both Trade3 and Plants by WebSphere by executing them manually using Internet Explorer,
and collect the result as shown in Table 5-10. As most action parameters represent business
functions explicitly, you can predict the usage of them, but we recommend that you verify all
customer’s usage manually or using interviews with the application designer or application
developer. This usage information is important when you map the transaction classes to the
service class described in “Mapping transaction classes to service class” on page 136 or
group the service classes into the workload described 5.4.3, “Grouping service classes into a
workload” on page 138.
Table 5-10 List of identified transactions for Trade3 and Plants by WebSphere
Application name Action parameter Customer’s usage
Trade3 account View account information
buy Buy stocks
home Go to home page
logout Log out from Trade3
portfolio View portfolio
quotes Quote stocks
register Register to Trade3
sell Sell stocks
update_profile Update account profile
Plants by WebSphere addtocart Add product to shopping cart
getimage Get products’ image
gotocart View shopping cart
initcheckout Start checkout
login Log in to Plants by WebSphere
productdetail Show product detail information
register Register to Plants by WebSphere
shopping View procucts by category
Tip: You can use action mappings defined in struts-config.xml to identify transactions if
your Web application uses the Apache Struts Web Application Framework. For more
information about this framework, refer to the Apache Struts Web Application Framework
homepage at:
http://jakarta.apache.org/struts/
Chapter 5. The ITSO EWLM scenario 135
Defining transaction classes
A transaction class defines a group of similar transactions; they are combined into a service
class for reporting. The work request can be identified by a pattern or by a specific identifier
called filter defined within the transaction class.
Although we could have defined a transaction class at a more generic level, we defined
transaction classes for each identified transaction. Table 5-11 shows our definition of
transaction classes. Refer to “Naming convention” on page 121 for details about naming rules
we used in this table.
Note: The workload we used in the ITSO configuration was mainly a three tier workload
with the “edge” hop as HTTP and we used the default definitions for workload that could be
generated on the WebSphere Application Server or DB2 application, such as the
WebSphere Admin activity. In your configuration, you might have workloads that have
either WebSphere or DB2 as an edge hop. In such a situation, the filters for the
classification of your transaction will be different and will depend upon the application.
For the WebSphere Application Server you can use:
? EJB Name
? EWLM:URI for servlets
? Port
? QueryString
For DB2 you can use:
? DB2 Platform
? Database Name
? Program Name
? Client Protocol
? Application Hostname
? System Auth Id
? Execution Id
? Application Id
136 IBM Enterprise Workload Manager
Table 5-11 Definition of transaction classes
Note that TC_Trade3_general and TC_Plants_general do not correspond to any action
parameter of the query string. These transaction classes are used for work requests which
correspond to requests for static content such as HTML pages or images. If, for example,
home transaction does not need to be monitored by EWLM, remove the definition of
TC_Trade3_home and it will be classified to TC_Trade3_general. We discuss this general
transaction class in more detail in “Defining filters for transaction classes” on page 141.
Mapping transaction classes to service class
A service class is a group of transaction classes that have similar performance goals or
business requirements. We define eleven service classes and map our transaction classes to
these service classes. This is shown in Table 5-12.
As an example, we assume that TC_Trade3_buy and TC_Trade3_sell should have the same
performance goal since these transaction classes represents similar customer usage: buy
stocks and sell stocks. We verify the validity of these groupings in 5.6.2, “Verifying service
class definition” on page 148.
Application
name
Action
parameter
Transaction class name Transaction class description
Trade3 account TC_Trade3_account View account information
buy TC_Trade3_buy Buy stocks
home TC_Trade3_home Go to home page
logout TC_Trade3_logout Log out from Trade3
portfolio TC_Trade3_portfolio View portfolio
quotes TC_Trade3_quotes Quote stocks
register TC_Trade3_register Register to Trade3
sell TC_Trade3_sell Sell stocks
update_profile TC_Trade3_update_profile Update account profile
N/A TC_Trade3_general General Transaction class for
Trade3.
Plants by
WebSphere
addtocart TC_Plants_addtocart Add products to cart
getimage TC_Plants_getimage Get products’ image
gotocart TC_Plants_gotocart View shopping cart
initcheckout TC_Plants_initcheckout Start checkout
login TC_Plants_login Log in to Plants
productdetail TC_Plants_productdetail Show product detail information
register TC_Plants_register Register to Plants
shopping TC_Plants_shopping View products by category
N/A TC_Plants_general General transaction class for
Plants
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.