Level: Intermediate Tony Lau (tktlau at ca.ibm.com), DB2 Performance Engineer, IBM
15 Jul 2004 SPEC provides a generic user guide on how to set up the SPECjAppServer2004 application. The technology coverage of the benchmark has been significantly extended from the benchmark released in 2002 in order to cover more aspects in a J2EE™ 1.3 enivornment. Vendor-specific information is not included in the documentation. This article provides the instructions and sample scripts for setting up SPECjAppServer2004 on IBM® DB2® Universal Database™ (UDB) and WebSphere®. The scripting approach can turn the setup task from a whole day of struggling to a single enjoyable learning hour.
Introduction
From the SPEC Web site, the "Standard Performance Evaluation Corporation (SPEC) is a non-profit corporation formed to establish, maintain, and endorse a standardized set of relevant benchmarks that can be applied to the newest generation of high-performance computers. SPEC develops suites of benchmarks and also reviews and publishes submitted results from our member organizations and other benchmark licensees." The suites of benchmarks developed by SPEC are widely used by different vendors and consultants both as a platform for verifying their solutions and as a vehicle for show-casing their products.
As the industrial leader in e-business, IBM WebSphere Application Server and DB2 UDB have published the world's first SPECjAppServer2004-compliant result. The benchmark results and the full disclosure report are posted on the Standard Performance Evaluation Corporation (SPEC) website [1].
In the last article, we introduced a scripting approach to accelerate the setup of SPECjAppServer2002. SPEC has significantly extended the technology coverage in the SPECjAppServer2004 benchmark. Scripting becomes more important. We have rewritten all the sample scripts to cover the new benchmark. This article takes you through the steps required to set up a single-node sandbox SPECjAppServer2004 environment on the IBM platform from loading the database with test data to stress testing the Web site. New users should get a quick start with the J2EE 1.3 performance benchmark for learning purposes. This article provides the readers with a solid foundation so that they can understand the issues well enough to move on to more advanced J2EE topologies and performance tuning concepts.
Goals
We will touch on the following major objectives:
- To provide SPECjAppServer2004 setup instructions for IBM products. SPEC provides a generic user guide [1] on how to set up the SPECjAppServer2004 application. Vendor-specific information is not included in the documentation, but we provide the instructions for setting up the application on WebSphere and DB2 UDB.
- To simplify configuration and improve efficiency. The benchmark kit contains a thousand files. Setting up the kit involves editing many files in roughly 50 different places. There is an old saying that one picture means a thousand words. In the world of enterprise computing, one script saves days of work. We propose the use of script automation to simplify the tasks. Sample scripts are provided for references. My experience is that the scripting approach can cut the setup time from a day to an hour.
- To provide cookbook instructions to the new users. IBM has comprehensive documentation on WebSphere and DB2 UDB administration from setting up a test system to building a huge cluster with high-availability support. One of the goals of this article is to deliver specific instructions on how to set up the benchmark in the simplest possible configuration for learning purposes. This will serve as a basis for those who are interested in moving on to more advanced J2EE topologies and performance work.
Prerequisites
Hardware
For learning purposes, any model Intel Windows® desktop machine will do. Listed below is the hardware we used in this article:
- IBM eServer™ x345
- 2 x 2.8 GHz CPUs
- 6 x SCSI disks
- 4 GB memory
Software
Listed below is the software we used in this article:
The SPECjAppServer2004 benchmark
SPECjAppServer2004 tests performance for a representative J2EE application and the components that make up the application environment, including hardware, application server software, JVM software, database software, JDBC drivers, and the system network.
The performance metric in SPECjAppServer2004 is called JOPS (jAppServer Operations Per Second). The metric is derived by adding the operations per second in the dealer domain to the work orders per second in the manufacturing domain. The metric allows J2EE vendors to compare systems of different hardware and software in the J2EE performance community.
The workload is an application that simulates message flow among an automobile dealership, manufacturing, supply chain management, and an inventory system. The SPECjAppServer2004 benchmark extends the SPECjAppServer2002 specification to exercise more capabilities of J2EE application servers. The SPECjAppServer2004 load driver drives the application through the Web interface for the automotive dealership and through Enterprise Java Beans (EJBs) for the manufacturing domain. The new benchmark also measures performance for the Web tier and messaging infrastructure.
Install IBM DB2 UDB
DB2 UDB has a very easy-to-use installation program. For our purpose, choose the Typical installation option. To keep things simple, install the product to C:\SQLLIB. If you use a response file, make sure that you have the keys shown below.
Listing 1. DB2 install options
FILE=C:\SQLLIB\
INSTALL_TYPE=TYPICAL
|
To verify the installation, open a DB2 Command Window and issue the commands shown below.
Listing 2. Verify DB2 installation
C:\GettingStartedWithSpecJ2004>db2level
DB21085I Instance "DB2" uses "32" bits and DB2 code release "SQL08016" with
level identifier "02070106".
Informational tokens are "DB2 v8.1.6.544", "s040517", "WR21340", and FixPak
"6".
Product is installed at "C:\SQLLIB".
C:\GettingStartedWithSpecJ2004>db2stop
06-06-2004 13:42:28 0 0 SQL1064N DB2STOP processing was successful.
SQL1064N DB2STOP processing was successful.
C:\GettingStartedWithSpecJ2004>db2start
06-06-2004 13:42:33 0 0 SQL1063N DB2START processing was successful.
SQL1063N DB2START processing was successful.
C:\GettingStartedWithSpecJ2004>db2sampl
C:\GettingStartedWithSpecJ2004>db2 list db directory
System Database Directory
Number of entries in the directory = 1
Database 1 entry:
Database alias = SAMPLE
Database name = SAMPLE
Database drive = C:\DB2
Database release level = a.00
Comment =
Directory entry type = Indirect
Catalog database partition number = 0
|
This will make sure that the basic functionalities of starting the database manager, stopping the database manager, and creating the database are all working correctly.
Install IBM WebSphere Application Server, IBM HTTP Server, and WebSphere MQ
WebSphere Application Server provides a straightforward installation program that installs the application server, HTTP server, and message server in one single install wizard. During the installation, choose the Full install option. To make life easier, install the application server in C:\was51\b0344.02., HTTP server in C:\was51\b0344.02_http. and message server in C:\was51\b0344.02_mq. If you prefer to use a response file, make sure that you have the keys set as shown below:
Listing 3. WebSphere install directories
-P wasBean.installLocation="C:\was51\b0344.02"
-P ihsFeatureBean.installLocation="C:\was51\b0344.02_http"
-P mqSeriesServerBean.installLocation="C:\was51\b0344.02_mq"
|
Before going on to the next step, make sure you test the installation. To verify the installation, open a command window and issue the commands shown below. Below is some sample test output.
Listing 4. Verify WebSphere installation
C:\was51\b0344.02\bin>startserver server1
ADMU0116I: Tool information is being logged in file
C:\was51\b0344.02\logs\server1\startServer.log
ADMU3100I: Reading configuration for server: server1
ADMU3200I: Server launched. Waiting for initialization status.
ADMU3000I: Server server1 open for e-business; process id is 2368
C:\was51\b0344.02\bin>ivt
IVTL0095I: defaulting to host tktlau04 and port 9080
IVTL0010I: Connecting to the WebSphere Application Server tktlau04 on port: 9080
IVTL0015I: WebSphere Application Server tktlau04 is running on port: 9080
IVTL0050I: Servlet Engine Verification Status - Passed
IVTL0055I: JSP Verification Status - Passed
IVTL0060I: EJB Verification Status - Passed
IVTL0070I: IVT Verification Succeeded
IVTL0080I: Installation Verification is complete
C:\was51\b0344.02\bin>stopserver server1
ADMU0116I: Tool information is being logged in file
C:\was51\b0344.02\logs\server1\stopServer.log
ADMU3100I: Reading configuration for server: server1
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server server1 stop completed.
|
To verify the HTTP installation, start the HTTP server service and navigate to the http://<hostname>/ test page.
Listing 5. Verify HTTP server installation
C:\was51\b0344.02_http>apache -v
Server version: IBM_HTTP_SERVER/1.3.28 Apache/1.3.28 (Win32)
Server built: Oct 9 2003 16:16:55
C:\was51\b0344.02_http>net start "IBM HTTP Server 1.3.28
The IBM HTTP Server 1.3.28 service is starting.
The IBM HTTP Server 1.3.28 service was started successfully.
|
To verify the basic functionality of MQ, issue the commands shown below.
Listing 6. Verify WebSphere MQ installation
C:\was51\b0344.02_mq\bin>mqver
Name: WebSphere MQ
Version: 530.4 CSD04
CMVC level: p530-04-030617
BuildType: IKAP - (Production)
C:\was51\b0344.02_mq\bin>crtmqm q1
WebSphere MQ queue manager created.
Creating or replacing default objects for q1.
Default objects statistics : 31 created. 0 replaced. 0 failed.
Completing setup.
Setup completed.
C:\was51\b0344.02_mq\bin>strmqm q1
WebSphere MQ queue manager 'q1' started.
C:\was51\b0344.02_mq\bin>endmqm -w q1
Waiting for queue manager 'q1' to end.
Waiting for queue manager 'q1' to end.
WebSphere MQ queue manager 'q1' ended.
C:\was51\b0344.02_mq\bin>dltmqm q1
WebSphere MQ queue manager 'q1' deleted.
|
This will ensure that all the components are installed successfully.
Obtain the SPECjAppServer code
The latest SPECjAppServer2004 code is available from the SPECjAppServer2004 result Web page [1]. For our case, we will use the code in the full disclosure archive submitted by IBM in May 2004. Copy the two EAR files into C:/was51/b0344.02/installableapps.
Listing 7. SPECjAppServer2004 code
04/23/2004 10:50a 86,803 Emulator_V1.01_Cluster.ear
05/05/2004 11:00a 2,428,206 SPECj2004_v1.01.3_Cluster_WAS51.ear
|
The SPECjAppServer EAR file is the benchmark application, which will be deployed on the application server.
Install the SPECjAppServer benchmark kit
The SPECjAppServer CD (available from SPEC [1] with a nominal fee) comes with an InstallShield program, setup.exe. If the install program does not locate any JVM, browse to the one that comes with DB2, C:\SQLLIB\java\jdk\bin\java.exe. To keep things simple, install the kit under C:\SPECjAppServer2004. Inside the kit are the benchmark facilities for loading the database and driving the benchmark.
Install PERL
We need to use PERL to make the installation process easier. Any standard PERL will serve our purpose. The following listing shows the version of PERL we are using [2].
Listing 8. PERL version
C:\SPECjAppServer2004\script>perl –v
This is perl, v5.8.0 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)
Copyright 1987-2002, Larry Wall
Binary build 806 provided by ActiveState Corp. http://www.ActiveState.com
|
Unpack the configuration scripts
Download the ZIP file attached to this documentation and extract the content into C:\SPECjAppServer2004\script. There are four user files in the package.
- setenv.pl
- specjdbsetup.pl
- specjdrvsetup.pl
- specjwassetup.pl
The setenv.pl file consists of the parameters for the setup. The specjdbsetup.pl script is used to create the SPECjAppServer database. The specjwassetup.pl script handles all the deployment tasks of the application. The specjdrvsetup.pl script takes care of the SPECjAppServer benchmark driver setup.
Provide the configuration parameters
The setenv.pl file comes with a set of default parameters. If you followed the instructions in the previous sections closely, most of the default values should be good enough.
In the first block of the parameters, we have the directory information of the products installed. Customize them if necessary.
Listing 9. Server install directories
#---------------------------------------------
# Server install directories
#---------------------------------------------
$SpecjKitHome='c:/SPECjAppServer2004';
$JavaHome='c:/SQLLIB/java/jdk';
$WasHome='c:/was51/b0344.02';
$WasNode='pizza43'; #Hostname
$Db2Home='c:/SQLLIB';
$WinHome='c:/WINNT';
$Login='spec';
$Password='spec';
|
The second block of parameters describes the location of the data. Customize them if desired.
Listing 10. Database and log directories
#---------------------------------------------
# Database and log directories
#---------------------------------------------
$SpecjDbDir='c:\specdb';
$SpecjLogDir='c:\speclog';
$SpecjPipe='c:/temp';
|
The parameters in the last blocks point to the location of the SPECjAppServer code and the emulator.
Listing 11. EAR install parameters
#---------------------------------------------
# EAR install parameters
#---------------------------------------------
$SpecjEar='c:/was51/b0344.02/installableapps/SPECj2004_v1.01.3_Cluster_WAS51.ear';
$EmulatorEar='c:/was51/b0344.02/installableapps/Emulator_V1.01_Cluster.ear';
$SpecjEarDeployed='c:/was51/b0344.02/installedapps/SPECj2004.ear';
$EmulatorEarDeployed='c:/was51/b0344.02/installedapps/SPECj2004_Emulator.ear';
|
Create the SPECjAppServer database
To create the SPECjAppServer database, simply run perl specjdbsetup.pl in a DB2 Command Window. The script will not only create the database, but also dumps out information for problem determination. It is always wise to pipe the output to a file for problem determination, if applicable.
The script will create a user with login name and password specified in the setenv.pl file. Make sure that they are allowed by your Local Security Policy.
Listing 12. Users in the system
Administrator db2admin dssadmin
Guest spec TsInternetUser
The command completed successfully.
|
The SPECjAppServer database consists of 20 user tables in total. Once the database is created, the script will list all the tables in the database.
Listing 13. All tables in the database
list tables
Table/View Schema
------------------------------- ---------------
C_CUSTOMER SPEC
C_CUSTOMERINVENTORY SPEC
C_PARTS SPEC
C_SITE SPEC
C_SUPPLIER SPEC
M_BOM SPEC
M_INVENTORY SPEC
M_LARGEORDER SPEC
M_PARTS SPEC
M_WORKORDER SPEC
O_ITEM SPEC
O_ORDERLINE SPEC
O_ORDERS SPEC
S_COMPONENT SPEC
S_PURCHASE_ORDER SPEC
S_PURCHASE_ORDERLINE SPEC
S_SITE SPEC
S_SUPP_COMPONENT SPEC
S_SUPPLIER SPEC
U_SEQUENCES SPEC
20 record(s) selected.
|
Then the script will configure the database loader and load the data into the database. Once we have everything, the script will establish a connection to the database and issue a query to the customer table as a sanity check.
Listing 14. Query to the customer table
select count(*) from C_CUSTOMER
1
-----------
15000
1 record(s) selected.
|
The diligent reader should look into the script to understand what exactly is happening behind the scene.
Deploy the SPECjAppServer application
To deploy the SPECjAppServer application, simply issue perl specjwassetup.pl from a DB2 Command Window. Be sure to pipe the output to a file for further study.
To start, the script will make sure that all the aliases specdelivery, specemulator, and specdb just created are all reachable. The specdelivery alias represents the IP address of the WebSphere system. The specemulator alias represents the address of the SPECjAppServer benchmark driver or emulator. The specdb alias represents the address of the DB2 UDB server. In our case, everything is local to us and goes through the 127.0.0.1 address.
Listing 15. Aliases specdelivery
Pinging specdelivery [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Ping statistics for 127.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
|
Moreover, a DB2 JDBC™ provider and data sources are created through WebSphere JACL scripting. Note that a Type 2 driver was used in the publication, as the Type 4 driver was not certified at that time. For those who are interested in using different JDBC drivers, please refer to the WebSphere InfoCenter [3].
Listing 16. Create DB2 JDBC provider and data sources
Getting Server Name
Getting Adapter Name
Creating JDBC Driver and SPECj DataSources with the following configuration
CellName pizza43
NodeName pizza43
Database Driver ClassPath c:/SQLLIB/java
Database User spec
Database Password spec4spec
DatabaseProvider Name DB2 Universal JDBC Driver Provider (XA)
Database Implementation Class COM.ibm.db2.jdbc.DB2XADataSource
Database Name specdb
DataSource Name SPECDB
DataSource JNDI jdbc/SPECDB
Relational Adapter "WebSphere Relational Resource Adapter
(cells/pizza43/nodes/pizza43:resources.xml#builtin_rra)"
WAS Cell pizza43(cells/pizza43:cell.xml#Cell_1)
WAS Node pizza43(cells/pizza43/nodes/pizza43:node.xml#Node_1)
Creating JAAS AuthData SPECjDataSourceAuthData
Create DB2 Universal JDBC Driver Provider (XA) on pizza43
(cells/pizza43/nodes/pizza43:node.xml#Node_1)
Create SPECDB
{name SPECDB} {description "SPECjAppServer2004 DB2 JDBC Datasource"}
Creating Datasource Properties
Creating Connection Factory
Create SPECUtilDB
{name SPECUtilDB} {description "SPECjAppServer2004 Util DB2 JDBC Datasource"}
Creating Datasource Properties
Creating Connection Factory
Saving Config
|
And then, the JMS Connections and destination are also created from JACL script.
Listing 17. Create JMS connections and destination
WASX7209I: Connected to process "server1" on node pizza43 using SOAP connector;
The type of process is: UnManagedProcess
------------------------------------------
Creating JMS Connections, Destination
with the following configuration:
NodeName pizza43
JMS Server Name Internal JMS Server
JMS Provider Name WebSphereJMSProvider
Queue Connection Factory QueueConnectionFactory
Queue Connection JNDI name jms/QueueConnectionFactory
------------------------------------------
Target Node Found: pizza43(cells/pizza43/nodes/pizza43:node.xml#Node_1)
Server Found: server1(cells/pizza43/nodes/pizza43/servers/server1:
server.xml#Server_1)
Create Queue Provider and MQ Queue name for Queues
JMS Resource setup using provider "WebSphere JMS Provider
(cells/pizza43/nodes/pizza43:resources.xml#builtin_jmsprovider)"
Setting Internal JMS Server(cells/pizza43/nodes/pizza43/servers/server1:
server.xml#JMSServer_1) initial state to START
JMS Queue BuyerQueue not found. Adding to Internal JMS Server
(cells/pizza43/nodes/pizza43/servers/server1:server.xml#JMSServer_1)
Create QueueConnectionFactory
Queue Connection Factory: QueueConnectionFactory
(cells/pizza43/nodes/pizza43:resources.xml#WASQueueConnectionFactory_1086875314625)
Create BuyerQueue
Create FulfillOrderQueue
Create LargeOrderQueue
Create ReceiveQueue
Create BuyerPort
Create StateManageable: initialState = START
Create FulfillOrderPort
Create StateManageable: initialState = START
Create LargeOrderPort
Create StateManageable: initialState = START
Create ReceivePort
Create StateManageable: initialState = START
Save Admin changes
|
Finally, the script deploys and installs the SPECjAppServer Web application and benchmark emulator.
Listing 18. Install the EARs
ADMA5013I: Application SPECjEmulator installed successfully.
…
ADMA5013I: Application SPECjAppServer installed successfully.
…
|
The WebSphere administrative (wsadmin) scripting program is a powerful, non-graphical command interpreter environment that enables you to execute administrative operations in a scripting language. The specjwassetup.pl script is an excellent example of using the program.
Set up the SPECjAppServer benchmark driver
To set up the SPECjAppServer benchmark driver, simply issue perl specjdrvsetup.pl at the DB2 Command Window.
The setup script will copy all the deployed classes to the SPECjAppServer benchmark kit. The Jar files contain the objects used in the application.
Listing 19. Copy the deployed classes
corp.jar
mfg.jar
orders.jar
supplier.jar
util.jar
xercesImpl.jar
xmlParserAPIs.jar
7 file(s) copied.
|
The script will then modify various files in the benchmark driver directories to provide parameters to the driver. Now, the driver should be able to create the agents and start the benchmark.
Listing 20. Start a run
The following environment settings are in effect for SPECjAppServer2004
* ========================= *
JAVA_HOME=c:/was51/b0344.02/java
JAS_HOME=c:/SPECjAppServer2004
CONFIG_DIR=c:/SPECjAppServer2004/config
APPSSERVER=default
ENVFILE=c:/SPECjAppServer2004\config\default.env
* ========================= *
Driver Host: PIZZA43
Binding controller to //pizza43/Controller
Controller: Registering M1 on machine 9.26.99.1
Controller: Registering L1 on machine 9.26.99.1
DriverDebug: DealerAgent <propsFile> <agentName> <masterMachine>
Controller: Registering O1 on machine 9.26.99.1
Calling switchLog as master
RunID for this run is : 3
Output directory for this run is : c:/SPECjAppServer2004/output\3
TTF1 = 103
ttf = 103
Configuring 1 DealerAgent(s)...
DealerAgent O1, Thread 0 started
DealerAgent O1, Thread 1 started
DealerAgent O1, Thread 2 started
DealerAgent O1, Thread 3 started
DealerAgent O1, Thread 4 started
DealerAgent O1, Thread 5 started
DealerAgent O1, Thread 6 started
DealerAgent O1, Thread 7 started
DealerAgent O1, Thread 8 started
DealerAgent O1, Thread 9 started
DealerAgent O1, Thread 10 started
DealerAgent O1, Thread 11 started
DealerAgent O1, Thread 12 started
DealerAgent O1, Thread 13 started
DealerAgent O1, Thread 14 started
DealerAgent O1, Thread 15 started
DealerAgent O1, Thread 16 started
DealerAgent O1, Thread 17 started
DealerAgent O1, Thread 18 started
DealerAgent O1, Thread 19 started
Configuring 1 MfgAgent(s)...
MfgAgent M1, Thread 0 started
MfgAgent M1, Thread 1 started
MfgAgent M1, Thread 2 started
MfgAgent M1, Thread 3 started
MfgAgent M1, Thread 4 started
MfgAgent M1, Thread 5 started
Configuring 1 LargeOLAgent(s)...
sleeptime is 26891 note this is time in excess needed for trigger
MfgAgent L1, Thread 0 started
Starting O1:0: at 30656 EndRampUp is at 130656
Starting O1:1: at 30765 EndRampUp is at 130656
Starting O1:2: at 30859 EndRampUp is at 130656
Starting O1:3: at 30968 EndRampUp is at 130656
Starting O1:4: at 31046 EndRampUp is at 130656
Starting O1:5: at 31156 EndRampUp is at 130656
Starting O1:6: at 31265 EndRampUp is at 130656
Starting O1:7: at 31359 EndRampUp is at 130656
Starting O1:8: at 31453 EndRampUp is at 130656
Starting O1:9: at 31562 EndRampUp is at 130656
Starting O1:10: at 31656 EndRampUp is at 130656
Starting O1:11: at 31750 EndRampUp is at 130656
Starting O1:12: at 31859 EndRampUp is at 130656
Starting O1:13: at 31953 EndRampUp is at 130656
Starting O1:14: at 32046 EndRampUp is at 130656
Starting O1:15: at 32156 EndRampUp is at 130656
Starting O1:16: at 32250 EndRampUp is at 130656
Starting O1:17: at 32359 EndRampUp is at 130656
Starting O1:18: at 32453 EndRampUp is at 130656
Starting O1:19: at 32562 EndRampUp is at 130656
Gathering DealerStats ...
Gathering MfgStats ...
summary file is c:/SPECjAppServer2004/output\3\SPECjAppServer.summary
Calling getLog as master
|
All the results are stored under the c:\SPECjAppServer2004\output directory. Now, you can go and check out your first set of results.
Create a bigger database
In the SPECjAppServer2004 benchmark, the size of the system is specified by the injection rate. An injection rate of 1 maps roughly to 13 concurrent clients. During the setup in the previous sections, a database that is supporting a small number of users (injection rate 2) has been created and the corresponding load has been applied to the system for functional testing purpose. Although the details of how to run the benchmark is out of the scope of our discussion, it is still worth going through some of the key aspects.
The size of the database is determined at the point where we load the database. To load the database, we use the loaddb.bat script where the injection rate is passed in as a parameter. For example, the commands below will delete the data in the database and load the database supporting an injection rate of 10:
Listing 21. Example loading database
cd c:\SPECjAppServer2004\bin
setenv.bat
loaddb.bat 10
|
Before we kick-off a run, we have to specify the load and the duration of the run. To start a run, we use the driver.bat script, which reads the run parameters from the run.properties file. The txRate parameter is the injection rate. The rampUp, stdyState, and rampDown parameters correspond to the run durations in seconds. For example:
Listing 22. Example run.properties fragment
txRate = 10
rampUp = 300
stdyState = 600
rampDown = 300
|
and the command below will start a run:
Listing 23. Example starting a run
cd c:\SPECjAppServer2004\bin
driver.bat
|
Database performance tuning is very important when we have a larger database and more users. One way to obtain a good starting point for the DB2 configuration parameter values is to use the DB2 Configuration Advisor. The Configuration Advisor will determine the best values for DB2 configuration parameters based on a few questions it asks you related to your DB2 UDB server like the memory available, type of workload, etc.
Conclusion
In this article, we take the reader through the steps required to set up a single node SPECjAppServer2004 application. The experiences built up here should help the readers to move on to more advanced J2EE topologies and performance tuning concepts. With the help of the configuration scripts used in this article, setting up SPECjAppServer2004 benchmark on DB2 UDB and WebSphere Application Server can be easy. One picture means thousand words. In this case, one script saves days of work. It is our experience that the scripting approach can turn the task from a whole day of struggling to a single enjoyable learning hour.
Acknowledgements
The author would like to thank Peter Shum, the manager of DB2 WebSphere Performance team for his expert advice on benchmarking.
The author would like to thank the WebSphere Performance Benchmark Sample developers. The sample JACL scripts were built upon the scripts in the benchmark kit.
The author also wants to thank Meng Fu from the DB2 Performance team for his help with ironing out the scripts and the input to the documentation.
Download | Name | Size | Download method |
|---|
| script_ga.zip | 35 KB | FTP |HTTP |
Resources
- Standard Performance Evaluation Corporation (SPEC) information at SPEC.org
- Find official SPECjAppServer2004 results at the SPEC Website.
- ActiveState at ActiveState ActivePerl.
- Websphere InfoCenter at WAS Information Center Reference Library.
About the author | | | Tony Lau is an IBM certified Systems Expert. He is a software engineer in IBM Toronto Lab. He had been research assistant at the parallel programming and distributed systems laboratory at the University of Waterloo. He is an active member in UW Alumni. His current focus is DB2 performance for WebSphere. |
Rate this page
| 
