Silkperformer 2010: Tutorials

Tutorials
Tutorials
SilkPerformer 2010
Borland Software Corporation 4 Hutton Centre Dr., Suite 900 Santa Ana, CA 92707
Copyright 2010 Micro Focus (IP) Limited. All Rights Reserved. SilkPerformer contains derivative works of Borland Software Corporation, Copyright 1992-2010 Borland Software Corporation (a Micro Focus company). MICRO FOCUS and the Micro Focus logo, among others, are trademarks or registered trademarks of Micro Focus (IP) Limited or its subsidiaries or affiliated companies in the United States, United Kingdom and other countries. BORLAND, the Borland logo and SilkPerformer are trademarks or registered trademarks of Borland Software Corporation or its subsidiaries or affiliated companies in the United States, United Kingdom and other countries. All other marks are the property of their respective owners. March 2010
Contents
Introduction
Overview . . . . . . . . Workflow Bar . . . . . . Where to Go. . . . . . . Multi-Protocol Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1 1 2 3
Chapter 5 Load Testing a CORBA Application
121
Chapter 1 Load Testing a Web Application 5 Chapter 2 Load Testing a Database through ODBC
Overview . . . . . . . . . . . . . . . . . . . . Tutorial 1: Running a predefined test . . . . . . Tutorial 2: Creating a script with the Recorder . Tutorial 3: Customizing the generated test script Tutorial 4: Replaying the customized script . . . Tutorial 5: Viewing the results of your load test .
Overview . . . . . . . . . . . . . . . . . . . 121 Tutorial 1: Running a sample load test . . . . 122 Tutorial 2: Creating a script with the Recorder 126 Tutorial 3: Customizing the generated test script133 Tutorial 4: Replaying the customized script . . 137 Tutorial 5: Viewing the results of your load test 145
7
.7 .8 13 21 26 35
Chapter 6 Load Testing a TUXEDO Application
151
Chapter 3 Load Testing an Oracle OCI7 Database 41

Overview . . . . . . . . . . . . . . . . . . . . Tutorial 1: Running a predefined test . . . . . . Tutorial 2: Creating a script with the Recorder . Tutorial 3: Customizing a generated test script . Tutorial 4: Replaying a customized script . . . . Tutorial 5: Viewing the results of your load test . 41 42 47 56 67 75
Chapter 7 Load Testing a Jolt Application 183

Chapter 4 Load Testing an Oracle OCI8 Database 81

Overview . . . . . . . . . . . . . . . . . . . Tutorial 1: Running a predefined test . . . . . Tutorial 2: Creating a script with the Recorder Tutorial 3: Customizing a generated test script Tutorial 4: Replaying a customized script . . . Tutorial 5: Viewing the results of a load test . . 81 . 82 . 87 . 95 .107 . 115
Chapter 8 Load Testing a COM Application 215

Overview . . . . . . . . . . . . . . . . . . . 215 Tutorial 1: Running a sample load test . . . . 216 Tutorial 2: Creating a script with the Recorder 220 Tutorial 3: Customizing the generated test script228 Tutorial 4: Replaying the customized script . . 232 Tutorial 5: Viewing the results of your load test 240 SilkPerformer Tutorials iii
Chapter 9 Load Testing an ADO Application
Appendix A Setup and Configuration 245

245 246 250 252 258 260 268
335
Overview . . . . . . . . . . . . . . . . . . . . Tutorial 1: Setting up an application profile. . . Tutorial 2: Creating a sample database . . . . Tutorial 3: Creating a script with the Recorder . Tutorial 4: Customizing a generated test script. Tutorial 5: Replaying a customized script . . . Tutorial 6: Viewing the results of a load test . .
Setting up the Person1 application . . . . . . . 336 Setting up the PersonPB application . . . . . . 338 Setting up the SilkCentral Performance Manager WAP sample application . . . . . . . . . . . 340
Chapter 10 Load Testing a WAP Application 273

Overview . . . . . . . . . . . . . . . . . . . . 274 Tutorial 1: Running a sample load test . . . . . 274 Tutorial 2: Creating a test script with the Recorder. 280 Tutorial 3: Customizing the generated test script293 Tutorial 4: Replaying the customized test scripts296 Tutorial 5: Viewing the results of your load test 305
Chapter 11 Load Testing a Jacada Application
309
Chapter 12 Load Testing IBM Mainframe Applications 311

Overview . . . . . . . . . . . . . . . . . . . . 311 Tutorial 1: Creating a Script with the Recorder . 312 Tutorial 2: Customizing the Generated Test Script . 319 Tutorial 3: Replaying the Customized Script . . 322
Chapter 13 Load Testing VT 100+ Applications
323
Overview . . . . . . . . . . . . . . . . . . . . 323 Tutorial 1: Creating a Script with the Recorder . 324 Tutorial 2: Customizing the Generated Test Script . 331 Tutorial 3: Replaying the Customized Script . . 334
iv
SilkPerformer Tutorials
Introduction
About this manual
This book provides a series of tutorials designed to ease you into the process of load testing with SilkPerformer, and to get you up and running with load testing as quickly as possible. This chapter contains the following sections:
Section Page
What you will learn
Overview Workflow Bar Where to Go Multi-Protocol Recording
1 1 2 3
Overview
SilkPerformer is now easier than ever to use, with a new Workflow bar that guides you through the complete load-testing process. Using these tutorials will help you to take full advantage of this ease of use, and to exploit the leadingedge functionality embodied in the load-testing tool of choice in the world of ebusiness. You can go directly to the chapter that best suits your needs. Each chapter contains a stand-alone set of tutorials for the most important types of interface in use in e-business today, including Web, database, and middleware applications.
Workflow Bar
The key to load testing with SilkPerformer is the Workflow bar at the top of SilkPerformers main window. These icons are your personal guide. They take
INTRODUCTION Where to Go
you right through the load-testing process from the very beginning of your project to when you view your test results. Every load test is part of a project. Start by sketching the broad outlines of your project give it a name, add a short description, and choose the kind of application you want to test. Every load test uses a set of instructions for what is to happen during the test; these instructions are contained in test scripts. You create a script usually by modeling one on some real-world behavior; you can also use sample scripts or write your own. You now do a trial run of your script not a real load test, just a try-out to make sure that the script works properly and that it is driving your application the way you want. If you use your present script, you will be running an identical set of instructions many times, and this will not create a realistic test. You need to create lifelike traffic in your load test by customizing your test script. Before you run your full load test, you need to know the ideal, basic performance that your application is capable of. You find this baseline performance by running a minimal load test; it also serves as a try-out of your customized script. To confirm that you have identified the performance you want from your application, you look at the results from your baseline test. This is the time also prepare for your full load test. Now you are going to select your workload model and configure your load test in conjunction with your accepted baseline results. You now run your full load test to assess the performance of your application, using the customized script and the full complement of agent computers and virtual users. There are lots of ways to watch the action as it happens! To view the results of your load test, use SilkPerformers incredible array of graphic and reporting facilities. Finally, to reuse a project you can upload it to SilkCentral Test Manager.
Where to Go
Go straight to the tutorials that you need.
INTRODUCTION Multi-Protocol Recording
If you are going to use SilkPerformer to load test your Web application, proceed to Load Testing a Web Application. To get started with database load testing, either proceed to Load Testing a Database through ODBC (if your database server and client communicate via ODBC) or to Load Testing an Oracle OCI7 Database (if you are using Oracle software). These tutorials may also be of interest to you if you are first going to run end-to-end load tests of your Web application and then test separate application modules, like database servers. If you are going to test your CORBA-based distributed application, proceed to Load Testing a CORBA Application. If the application that you are going to test uses middleware like TUXEDO, proceed to Load Testing a TUXEDO Application. Afterwards, Load Testing a Jolt Application might be of interest to you. If you are going to test your COM application, proceed to Load Testing a COM Application.
Setup and configuration instructions for all the sample applications used in the tutorials are provided in Setup and Configuration.
Multi-Protocol Recording
SilkPerformer supports multi-protocol recording. Protocol-recording settings are configured using SilkPerformer's Application Profile dialog box , located in Settings/System.../System Settings - Recorder/Application Profiles/(Add button)/. Refer to the SilkPerformer Online Help for full details regarding multi-protocol recording.
INTRODUCTION Multi-Protocol Recording
1
1e rh C t p a
Load Testing a Web Application

This chapter is available as a separate tutorial book in PDF format. SilkPerformer Web Load Testing Tutorial guides you through all the steps in successfully completing a Web load testing project. You can find this tutorial in the Doc subfolder of your SilkPerformer start menu folder and in the Doc subfolder of your local SilkPerformer installation. If you do not have the installation CD available, contact Customer Care. The sample application used in this tutorial is called ShopIt and is contained on the installation CD in the folder Extras.
Introduction
1 LOAD TESTING A WEB APPLICATION
2
2e rh C t p a
Load Testing a Database through ODBC

This chapter contains a series of tutorials that will help you to start load-testing a database through ODBC with SilkPerformer. This chapter contains the following sections:
Section Page
Introduction What you will learn
Overview Tutorial 1: Running a predefined test Tutorial 2: Creating a script with the Recorder Tutorial 3: Customizing the generated test script Tutorial 4: Replaying the customized script Tutorial 5: Viewing the results of your load test
7 8 13 21 26 35
Overview
Each of the following tutorials provides step-by-step instructions for important SilkPerformer tasks. You should perform these tutorials in order, since each tutorial builds on what you have learned in the previous ones.
You will learn how to do the following:
Execute a predefined load test on your local machine. Create a test script by recording COM traffic using the Recorder. Customize the recorded test script. Use reporting tools to view multiple and selected throughput and response time information.
2 LOAD TESTING A DATABASE THROUGH ODBC Tutorial 1: Running a predefined test Sample: Person1
These tutorials use a sample database application called Person1. This application is included on your SilkPerformer CD-ROM (\Extras\Person1Setup.exe) and is available for download from http:// sso.borland.com/download/. After logging in, download the version of the installer that corresponds to the latest version of SilkPerformer you have purchased. You should run this setup prior to beginning the tutorials. See Setting up the Person1 application.
Tutorial 1: Running a predefined test

In this tutorial you will learn to create a load-testing project and execute sample scripts that are provided with SilkPerformer. You will run one of the sample scripts with a single virtual user on your local machine. You will use the test script LoadPers.bdf, which is included in the Working\Samples\Database folder in your SilkPerformer installation. This script will create the tables that the Person1 application requires and insert into your database the data that you will need for the remaining tutorials.
Creating a load-testing project

For each server you load test with SilkPerformer, you have to create a project file. A project file administers all the settings that are associated with a series of load tests, like the test type and a number of database-specific options.
Creating a project
Procedure To create your load-testing project: 1 Open SilkPerformer If you did not close the project you last worked on, SilkPerformer will open with that project. 2 3 Close any open projects. In the Workflow bar, click Start here.
2 LOAD TESTING A DATABASE THROUGH ODBC Tutorial 1: Running a predefined test
The Workflow Outline Project dialog box opens.
4 5
In the Project name text box, enter Person1 as the name for your loadtesting project. In the Project description edit field, enter a short description for your project. This description is for your own project management purposes only. In the Application type list, select the ODBC option. Click OK. SilkPerformer will create a new load-testing project called Person1 with the default settings profile and your local computer as the only agent.
6 7
Adding a load-testing script

Each project contains a number of load-testing scripts. A test script defines different groups of virtual users and all the actions that these users have to perform. To be able to execute a load-testing script, you have to add it to your project.
Adding a test script
Procedure To add a predefined script to your project 1 In the SilkPerformer workflow bar, click Model Script.
The Workflow Model Script dialog box opens.
In the Script area, select the Sample script option in order to open one of the scripts that accompany SilkPerformer and add it to your current project. Click OK. The Open dialog box opens. Navigate to the Working\Samples\Database folder in your SilkPerformer installation and select the LoadPers.bdf script. Click Open. A SilkPerformer Message dialog box opens. This dialog box asks you whether you want to add the test script to your load-testing project.
3 4 5
Click Yes to add the selected test script to your project. SilkPerformer adds the LoadPers.bdf test script to the Scripts folder of your current project and displays the script in a new editor window.
Configuring load test settings

Each project contains a number of profiles, one of which is activated. A profile is a collection of settings that determine the type of test to be performed, the workload model, and particular options that depend on the server being tested. By default, there is one profile included and activated in your project, the Profile1 profile.
Configure load test settings
Procedure To configure settings for the load test: 1 In the Project window, expand the Profiles folder.
10
2 3 4
Right-click the Profile1 profile and select Edit Profile. The Profile [Profile1] Simulation dialog box opens. In the shortcut list on the left side, select the Replay category and click the Database icon. Click the ODBC High-Level tab. You see the following.
From the Data Source Name list box, select the ODBC data source of the database that you want to use for the load tests in these tutorials. This should be the local repository in the SQL server database, to avoid any problems. The test script will create tables and insert data into the database you select here.
6 7 8
In the User ID text box, enter the user name that you want to use for accessing the database. In the Password text box, enter the password for the user name that you have specified. Click OK.
Executing the test script

In the LoadPers test script, three different user groups are set up:
11
Creator: A virtual user of this group will create all the tables that the Person1 application requires. Loader: A virtual user of this group will load sample data into the database so that the Person1 application can be load tested under conditions of real-world use. Dropper: A virtual user of this group will remove the sample data and delete the tables that were created earlier for the Person1 application.
To create the tables and insert the sample data for the remaining tutorials, you will first run a virtual user of the Creator group and then a user of the Loader group.
Procedure To execute the LoadPers test script: 1 2 In the Active Script window, expand the User Groups folder. In the User Groups folder, right-click Creator and select Run User Creator. SilkPerformer runs a virtual user, performing all the actions defined in the test script, that is, creating the tables in the database that the Person1 application requires. While the virtual user is being run, you can watch progress in the Monitor window, for example, the number of transactions executed, the response time of the last transaction, and the average response time. 3 Monitor the load test and wait until the virtual user has finished executing its tasks. a In the top part of the Monitor window, select an agent computer or a user group that you want to monitor. In the bottom part of the Monitor window, SilkPerformer displays overview information about all the virtual users running on the selected agent computer or belonging to the selected user group. b In the bottom part of the Monitor window, right-click a virtual user for which you want to view detailed information and select Show Output. SilkPerformer displays detailed run-time information about the selected user in the Virtual User window at the bottom, for example, the transactions and functions the user executes, and the data that the user sends to and receives from the server. The type of information displayed depends on the options that you select at the top of the Monitor window.
12
2 LOAD TESTING A DATABASE THROUGH ODBC Tutorial 2: Creating a script with the Recorder
Display Errors. Select this button to display an appropriate error message indicating the probable reason whenever a user-related error occurs. Display Transactions. Select this button to display a message when a user has finished executing a transaction; the message indicates whether the transaction was successful or not. Display Functions. Select this button to display a message for each function call a given user performs, including the function name and all its parameters. Display Info. Select this button to display messages containing additional information about the current action a given user performs. Display Data. Select this button to show data exchanged with the server. Display all Errors of all Users. Select this button to display error messages for all errors of all users. Each error message will indicate user, agent and probable cause of the error. 4 5 From the menu bar, select File/Close to close the Monitor window. In the User Groups folder, right-click Loader and select Run User Loader. SilkPerformer runs a virtual user that inserts sample data into the previously created tables.
What you have learned
In Tutorial 1, you learned how to: Create a load-testing project Add a predefined script to the project Execute the script with one virtual user View progress information for the load test
Tutorial 2: Creating a script with the Recorder

The SilkPerformer Recorder allows you to capture database traffic transferred between a client application and a server. After you record database traffic, you can save it as a test script. You can then easily customize the script and replay the script to simulate a large number of virtual users. Recording, customizing, and replaying a script will be covered separately in Tutorials 2, 3, and 4. In Tutorial 5, you will analyze the results of the load test you ran. This tutorial includes the following steps:
13
Setting up an application profile Recording traffic between a client application and a server Generating a test script based on the recorded traffic Trying out the generated test script Validating the generated test script
Setting up an application profile

Whenever you want the SilkPerformer Recorder to capture the traffic that is exchanged between a client application and a server, you have to set up a profile for the client application. This profile specifies the type of the client application and what type of traffic to record.
Procedure To set up a profile for the client application: 1 2 From the menu bar, select Settings/System. The System Settings Workbench dialog box opens. In the shortcut list on the left side, click the Recorder icon. You see the following.
The list contains all the application profiles that are currently set up on your computer. 3 Click Add.
14
The Application Profile dialog box opens.
4 5
In the Application profile text nox, enter a name for the application profile, for example, Person1. Click the Browse button and locate the executable, called Person1.exe. This file is located in the directory you selected during setup (see Sample: Person1). From the Application type list box, select the Custom Application option. In the API selection area, select the ODBC option. Click OK. SilkPerformer adds the new application profile to the profile list in the System Settings Recorder dialog box.
6 7 8
Click OK to close the dialog box.
10 In the Project window, expand Profiles, right-click Profile1 and select Edit Profile. The Profile [Profile1] Simulation dialog box opens. 11 Disable Choose transactions randomly option. This prevents Logoff from occurring in test script. 12 Click OK.
SilkPerformer Tutorials 15
Modeling a test script

To load test a database, the traffic between the client application and a server needs to be recorded and then described in a test script. The script finally enables any number of virtual users to perform actions similar to those that you performed during the recording session. In order to create as realistic a load test as possible, you will record five separate transactions in a single recording session: Logging on to the database Searching for customer information Updating a customer record Inserting a new customer record Logging off from the database
When you run the load test, you will create three user groups to which you will assign each of these tasks in a ratio that simulates real-world behavior.
Person1 application notes
Special considerations when working with the person1 application: In order to search for a user, one has to type the name into the field and then hit the <tab> key In order to insert a new record, one has to type the new details into the fields and then hit the <insert> button (after the information is entered)
Procedure To model a load-testing script: 1 In the Workflow bar, click Model Script. The Workflow Model Script dialog box opens.
16
2 3 4 5
In the Script area, select the Record option. From the Select application profile list box, select Person1. Click OK. SilkPerformer opens the Recorder and starts the Person1 application. In the Recorder, click the New Transaction button to insert a new transaction into the test script you are generating. The following dialog box opens.
Create a new transaction called TLogon; then click OK. A distinct set of time measurements will be made for each transaction you create. When recording traffic, you should create a new transaction for each distinct user session, from connection to shutdown. In the Login dialog of the Person1 application, enter the ODBC data source, the user name, and the password for logging on to the database. Then click OK. The Customer window opens.
As you connect to your database, the Recorder records the database traffic automatically.
To view your actions as well as the function calls that the Person1 application performs, click the Change GUI Size button. The SilkPerformer Recorder window then looks like the following.
In the Recorder, create a new transaction called TSearch.
10 In the Customer dialog box, enter a last name for which you wish to search, for example, Williams. 11 In the Person1 application, perform the following additional steps: Before you perform each step, create a new transaction with a name that describes that user session, such as TUpdate and TInsert. a b Change the address for a customer. Insert a new customer record.
12 In the Recorder, create a new transaction called TLogoff. 13 In the Customer window, select File/Exit from the menu bar. 14 In the Recorder, click the Stop Recording button. The Save As dialog box opens. 15 In the File name edit field, enter Person1. 16 Click Save. 17 You can now decide whether to close the Recorder.
18
If you keep it open, you can examine the script that has been generated.
18 Close the Recorder. SilkPerformer automatically adds the script to your current load-testing project.
Trying out the generated test script

Next you should do a trial run of the test script that was created. The object of the trial run is to ensure that the script is free from error, and that it will reproduce accurately the interaction between the client application and the database server.
Trying out the script
Procedure To try out the generated test script: 1 In the Workflow bar, click the Try Script button.
19
The Workflow Try Script dialog box opens.
2 3 4
From the Script list box, select the Person1.bdf script. Make sure the VUser group is selected in the Usergroup list. Click Run. SilkPerformer runs a single virtual user, called VUser, which performs all the actions that you have performed during the previous recording session. While the single-user test is running, you can watch progress in the Monitor window.
20
2 LOAD TESTING A DATABASE THROUGH ODBC Tutorial 3: Customizing the generated test script What you have learned
In Tutorial 2, you learned how to: Set up an application profile Record traffic between a client application and a database Generate a test script based on the recorded traffic Try out the generated test script
Tutorial 3: Customizing the generated test script

Customizing the test script you have generated allows you to take the actions performed by a single user and create from them a realistic simulation of multiple users. Two key tasks can help you create a real-world simulation: Replacing constant values with random variables Specifying which tasks each virtual user will perform Note You must use Benchmark Description Language (BDL), SilkPerformers high-level scripting language, to customize generated test scripts. Although knowledge of BDL is not required for this tutorial, it might be helpful to browse the introductory BDL Reference topics in the Online Help for more information about BDL before you begin.
Replacing constant values with random variables

Where randomized data is necessary, random variables are employed to provide realistic user data. In this way, SilkPerformer furnishes the virtual users with varied personal data like name, address, phone number, and so on.
Replacing constant values
Procedure To replace constant values with random variables: 1 In the Workflow bar, click Customize Test.
21
2 LOAD TESTING A DATABASE THROUGH ODBC Tutorial 3: Customizing the generated test script
The Workflow Customize Test dialog box opens.
2 3
Click the Create New Parameter Wizard button. The Parameter Wizard - Create New Parameter dialog box opens. Select Parameter from Random Variable and click Next. The Parameter Wizard - Random Variable dialog box opens.
4 5
From the Random type list box, select the String from file type. Click Next.
22
The following dialog box opens.
In the File area, select Address from the Name list box. This random variable will draw from a SilkPerformer file containing random addresses and select an address up to 35 characters in length.
Click Finish. SilkPerformer inserts the following lines into your test script.
dclrand rRndFile1 : RndFile("Address.rnd", 35);
Locate the TUpdate transaction. You can do this by expanding the Transactions folder in the Active Script window and double-clicking TUpdate.
Replace the existing address with the rRndFile1 variable. This section of the TUpdate transaction should now look like the following. The code shown in bold type is what you have changed.
OdbcPrepare(c2, TUpdate_SQL005); OdbcBind(c2, ":1", SQL_C_CHAR, 10); OdbcBind(c2, ":2", SQL_C_CHAR, 10); OdbcBind(c2, ":3", SQL_C_CHAR, 60); OdbcBind(c2, ":4", SQL_C_CHAR, 40); OdbcBind(c2, ":5", SQL_C_CHAR, 80); OdbcBind(c2, ":6", SQL_C_CHAR, 80); OdbcBind(c2, ":7", SQL_C_CHAR, 10); OdbcBind(c2, ":8", SQL_C_CHAR, 80); OdbcBind(c2, ":9", SQL_C_DOUBLE, 0, SQL_INTEGER); OdbcSetString(c2, ":1", "Mag. "); OdbcSetString(c2, ":2", "Company ");
23
OdbcSetString(c2, ":3", "Williams OdbcSetString(c2, ":4", "John OdbcSetString(c2, ":5", rRndFile1); OdbcSetString(c2, ":6", "Line2"); OdbcSetString(c2, ":7", "3584 BW "); OdbcSetString(c2, ":8", "Mississippi OdbcSetFloat(c2, ":9", 1813.00); OdbcExecute(c2); OdbcCommit(ghDbc1); "); ");
");
10 Locate the TInsert transaction. You can do this by expanding the Transactions folder in the Active Script window and double-clicking TInsert. 11 In this transaction, declare a local floating-point variable called fCustomerId. The code section should then look like the following. The code shown in bold type is what you have inserted.
transaction TInsert var fCustomierId: float; begin OdbcClose(c1, SQL_UNBIND);
12 Within this transaction, locate the section in which the customer ID is queried the second time. The customer ID is queried twice: once before it is increased (before the Update statement) and once after it has been increased (after the UPDATE statement). Immediately after the OdbcFetch function calls, insert the following code.
fCustomerId := float(OdbcGetString(c2, "1"));
This section of the TInsert transaction should now look like the following.
OdbcPrepare(c2, TLogon_SQL001); OdbcClose(c2); OdbcExecute(c2); OdbcDefine(c2, "1", SQL_C_CHAR, 12); OdbcFetch(c2, SQL_FETCH_ALL, 1, SQL_FETCH_NEXT); // 1 rows fetched fCustomerId := float(OdbcGetString(c2, "1"));
Locate the section in which the new customer is inserted. 13 In the first OdbcSetFloat function call, replace the last parameter with the variable fCustomerId. This will ensure that each time a new customer is inserted, a unique customer ID number is used. This section of the TInsert transaction should now look like the following.
OdbcPrepare(c2, TInsert_SQL008); OdbcBind(c2, ":1", SQL_C_DOUBLE, 0, SQL_INTEGER); OdbcBind(c2, ":2", SQL_C_CHAR, 10); OdbcBind(c2, ":3", SQL_C_CHAR, 10);
24
OdbcBind(c2, ":4", SQL_C_CHAR, 40); OdbcBind(c2, ":5", SQL_C_CHAR, 60); OdbcBind(c2, ":6", SQL_C_CHAR, 80); OdbcBind(c2, ":7", SQL_C_CHAR, 80); OdbcBind(c2, ":8", SQL_C_CHAR, 10); OdbcBind(c2, ":9", SQL_C_CHAR, 80); OdbcSetFloat(c2, ":1", fCustomerId); OdbcSetString(c2, ":2", "Company "); OdbcSetString(c2, ":3", "Mag. "); OdbcSetString(c2, ":4", "Richards"); OdbcSetString(c2, ":5", "Mike"); OdbcSetString(c2, ":6", "First Avenue"); OdbcSetString(c2, ":7", ""); OdbcSetString(c2, ":8", "10010"); OdbcSetString(c2, ":9", "Manhattan"); OdbcExecute(c2); OdbcCommit(ghDbc1);
14 When you are done making changes to the script file, select File/Save from the menu bar to save your changes.
Specifying which tasks each user will perform

Usually a load test simulates a number of different types of users. In the test script, you have to specify which action each type of virtual user will perform.
Assigning tasks to users
Procedure To specify which tasks each user will perform: 1 Navigate to the dcluser section of the Person1.bdf script file. You can do this by selecting User Groups/VUser in the Active Script window. You see the following.
dcluser user VUser transactions TInit TLogon TSearch TUpdate TInsert TLogoff
: : : : : :
begin; 1; 1; 1; 1; 1;
In this section, a single user group is defined, called VUser. By default, this user group will perform the transactions you created, TLogon, TSearch, TUpdate, TInsert, and TLogoff, once each. 2 Edit the dcluser section of the script so it looks like the following.
dcluser user Searcher transactions TLogon TSearch TLogoff
: begin; : 5; : end;
user Updater
25
2 LOAD TESTING A DATABASE THROUGH ODBC Tutorial 4: Replaying the customized script
transactions TLogon TSearch TUpdate TLogoff user Inserter transactions TLogon TSearch TInsert TLogoff
: : : :
begin; 3; 2; end;
: : : :
begin; 1; 3; end;
In the edited version of the script, the user group Searcher performs the TLogon transaction at the beginning, the TSearch transaction five times, and the TLogoff transaction at the end. The user group Updater performs the TLogon transaction at the beginning, the TSearch transaction three times, the TUpdate transaction twice, and the TLogoff transaction at the end. The user group Inserter performs the TLogon transaction at the beginning, the TSearch transaction once, the TInsert transaction three times, and the TLogoff transaction at the end. 3 4 5
Select File/Save from the menu bar to save your changes. In the Workflow toolbar, click Customize Test. The Workflow Customize Test dialog box opens. Click Yes to confirm that you are done customizing the test script.
In Tutorial 3, you learned how to: Replace constant values with random variables Specify which tasks each virtual user will perform
Tutorial 4: Replaying the customized script

After you have created a test script by recording traffic and then customizing the script, you can load test your server by replaying the script. To run a load test, you must perform the following steps: Find the test baseline Confirm the test baseline Set up server monitoring for your load test Execute the load test
26
Finding the test baseline

After you have customized the load-testing script, you need to determine baseline performance. This is the ideal performance of your application when it is not under real pressure. To obtain this test baseline, the fully customized script is run with just one user per user group. This will provide you with a solid basis for comparison with the situation when the application is fully taxed by a load test.
Finding the baseline
Procedure To find the load test baseline: 1 In the Workflow toolbar, click Find Baseline. The Workflow Find Baseline dialog box opens.
This dialog lists all the user groups you have set up in your test script. 2 Click Run. SilkPerformer runs one virtual user from each user group that you have declared in the test script. While the test is running, you can watch progress in the Monitor window.
Confirming the test baseline

After running the baseline test, you have to confirm the test result reflects the desired performance of the tested server. For this you inspect the results of the test. If they are satisfactory, the baseline is established and will form the basis for comparison with results from full load tests later.
27
2 LOAD TESTING A DATABASE THROUGH ODBC Tutorial 4: Replaying the customized script Confirming the baseline
Procedure To confirm the load test baseline: 1 In the Workflow toolbar, click Confirm Baseline. The Workflow Confirm Baseline dialog box opens.
2 3 4 5 6
Click the Baseline Report button. The Baseline Report opens. Check the report carefully. In particular, make sure that no errors have occurred during your baseline test. Click Accept Baseline in the Baseline Report. Click Yes and OK by the Message boxes that comes up. If your baseline report indicates no errors, click Yes in the Workflow Confirm Baseline dialog box to confirm that you have found the baseline.
Adjusting the workload

After you have confirmed your baseline, you now select your workload model and prepare the workload to run a full load test.
Procedure To adjust the workload: 1 In the Workflow toolbar, click Adjust Workload.
28
The Workflow - Select Workload Model dialog box opens.
This dialog box shows all possible workload models, which can be selected. 2 3 Select Queuing workload model. Click OK. SilkPerformer now opens the Workload Configuration dialog box.
Running the load test

After you have adjust the workload, you run the full load test. The test script is run with multiple virtual users in order to test the database server. A large load test would need the appropriate testing environment to be set up in the local area network, including a full complement of agent computers to host the virtual users. For this tutorial, however, you use only your local computer.
Running the test
Procedure To run the load test: 1 The Workload Configuration dialog box is open.
29
2 3 4
In the VUsers column, change the number of Inserter users to 25, the number of Searcher users to 50, and the number of Updater users to 25. For each of these user groups, change the simulation time to 300 seconds (5 minutes). Disable all user groups that are declared in the LoadPers test script.
You are now ready to run the load test. When you run a test SilkPerformers sophisticated monitoring tool Performance Explorer will automatically generate a live graphical display of a default set of test data for the server you are testing. You can disable this default option by deselecting the setting Automatically start monitoring. You can also change the default monitoring settings by pressing the Active profile button (See Customizing server monitoring). Once monitoring is set up the way you want it, you can continue and run the test. 5 Click Run to start the test now, or Click OK to save the settings and start the test later. When you start the test, SilkPerformer runs a load test for the database server with 100 virtual users. If the (default) option Automatically start monitoring is enabled, Performance Explorer will open and generate a live graphical display of the specified set of test data. If you wish you can adapt the views by
30
adding or deleting specific measurements. For this you can expand the tree menu on the left and drag and drop selected measurements into existing or new view graphs.
Customizing server monitoring for your load test

An important feature SilkPerformer provides, is server monitoring during an actual load test. Server monitoring will help you locate and analyze bottlenecks on the server. You can separately examine the performance of the operating system, the network and the server application, which in this case is the Web server. Server monitoring is performed with Performance Explorer, a powerful tool SilkPerformer incorporates. When you run a test, the default procedure is that Performance Explorer automatically opens a set of views containing a live graphical display of a selection of test data that is particularly significant for the server you are testing. You can disable this default option by deselecting the setting Automatically start monitoring in the Workload Configuration [.......] dialog. You can also customize the default monitoring settings and select a particular set of data sources.
Setting up server monitoring
Procedure To customize server monitoring for your load test: 1 2 In the Workflow toolbar, click the Run Test button. The Workload Configuration dialog opens. In the Settings section, click the Active Profile button.
31
The Profile Results dialog opens.
3 4
In the shortcut list on the left side, select the Replay category and click the Results icon. Select the Monitoring tab. The option Automatically start monitoring is activated by default. It means, that when you run a load test, the Performance Explorer will open automatically using a default template that invokes display of relevant client information.
If you want to customize monitoring, enable the Use custom monitoring template, and click the Create Customer Monitor Template button. Performance Explorer will create and open a template with the name of your project, which is equal to the default template.
Click Edit Customer Monitor Template, to customize the new template and change the display of information. You can close or maintain the default monitoring windows and you can add one or more windows to provide additional information. To set up Performance Explorer to display additional information, proceed as follows: a From the menu bar, select Monitor/Add Data Source.
32
The Data Source Wizard opens.
Click Next. The Data Source Wizard - System selection dialog opens.
In the tree view, expand the folder that corresponds to the operating system on which the database server is running. Within that folder, select System. Click Next. In the Connection Parameters dialog, enter connection parameters, like the host name or IP address of the database server, the connection port, the user name, and the password.
d e
33
f g h i j k l
The data you have to enter here depends on the operating system that is running on the computer you are monitoring. Click Next when you have entered the connection parameters. In the next dialog, select the performance counters you want to monitor. Of particular interest are the processor and memory utilization of the server being tested. Click Finish. Performance Explorer will open a new window, displaying real-time data for the performance counters you have selected. In the Monitor tree view, right-click the name of the computer you are monitoring and select Add Data Source. Repeat step a - i, but this time: I In the first dialog, select the name of the database server software instead of System.
m The Data Source Wizard opens again. n
II In the third dialog, select which performance counters you want to monitor. Later, when you are running the load test, the monitor view will look similar to the following.
In Tutorial 4, you learned how to:
34
2 LOAD TESTING A DATABASE THROUGH ODBC Tutorial 5: Viewing the results of your load test
Find the test baseline Confirm the test baseline Set up server monitoring for your load test Adjusting the workload Execute the load test
Tutorial 5: Viewing the results of your load test

SilkPerformer incorporates Performance Explorer, a powerful graphing and analysis tool to help you work with your results information. Performance Explorer provides a comprehensive array of results information, which can be displayed using advanced features for creating statistical reports and displaying performance results in real time generated graphics. Results information may vary, depending on the type of application and/or server being tested. In general it falls into the following categories: Response time information: This is the total time to process a given timer; it provides application performance information from the point of view of the client computer. Throughput information: This is the rate at which a given timer is processed on average by the database server; it allows you to analyze performance from the point of view of the server.
Overview report of performed measurements

You can consult an HTML overview report that contains results of all performed measurements.
Exploring overview report
Procedure to explore overview report: 1 In the Workflow toolbar, click the Explore Results button.
35
The Workflow - Explore Results dialog opens.
Click the Performance Explorer button. Performance Explorer opens, and the HTML overview report is generated.
36
You may consult this report which includes short explanations of the displayed graphs. If you want you can view more detailed information.
Detailed response time measurements

When you analyze the performance of a database server from the point of view of the client, you examine the response times for all the transactions, SQL statements, and individual timers. This enables you to find out how users will experience their interaction with the database server. A common goal in load testing is to ensure that the response times for all the database operations remain below a specified, critical limit.
Analyzing response times
Procedure To explore response time measurements: 1 2 In the Performance Explorer Workflow toolbar, click the Select Graph button. The Template dialog opens.
3 4
In the Templates area, select the Timer option. Click Finish.
37
The Performance Explorer opens a new chart that contains a graph of the active users.
You see the default graph with the average number of active users, and one or more default measurements (if any). 5 6 7 8 9 Expand the Explore tree view. In the Explore tree view, expand SQL Commands/TLOGON_ SQL001. Drag the Exec measurement and drop it on the new view. In the Explore tree view, expand SQL Commands/TINSERT_ SQL006. Again, drag the Exec measurement and drop it on the new view.
38
You see a chart similar to the following.
The load test that you ran in the previous tutorial lasted only a few minutes, so there are only a few measurements, which makes it difficult to draw any conclusions. In real-life you will run load tests that last several hours, a few days, or even a week. These tests will provide results information that will allow you to analyze the performance of your server accurately.
Exploring throughput measurements

When you analyze the performance of a database server from the point of view of the server, you examine the throughput rate. Throughput is the work done by the server within a specific time interval, for example, the number of requests that the server processes within a second, a minute, or an hour. A common goal in load testing is to ensure that the throughput rate is above a specified, critical limit.
Throughput rate details
Procedure To explore throughput measurements: 1 In the Performance Explorer Workflow bar, click the Select Graph button. The Template dialog opens. 2 In the Templates area, expand the Throughput folder.
3 4
In the Throughput folder, select Database. Click Finish. The Performance Explorer opens a new chart that looks like the following.
Again, since the load test that you ran lasted only five minutes, it is difficult to derive conclusions from the results.
In Tutorial 5, you learned how to: Explore response time measurements Explore throughput measurements
40
3
3e rh C t p a
Load Testing an Oracle OCI7 Database

This chapter contains a series of tutorials that will get you started using SilkPerformer to load test Oracle OCI7 databases. This chapter contains the following sections:
Section Page
Overview Tutorial 1: Running a predefined test Tutorial 2: Creating a script with the Recorder Tutorial 3: Customizing a generated test script Tutorial 4: Replaying a customized script Tutorial 5: Viewing the results of your load test
41 42 47 56 67 75
Overview
Each of the following tutorials provides step-by-step instruction for important SilkPerformer tasks. These tutorials should be followed in order, as each tutorial builds on what is covered in the preceding tutorials.
You will learn how to:
Execute a predefined load test on your local machine. Create a test script by recording database traffic using the Recorder. Customize a recorded test script. Run a customized script, using multiple virtual users.
41
3 LOAD TESTING AN ORACLE OCI7 DATABASE Tutorial 1: Running a predefined test
Sample: PersonPB
Use reporting tools to view select throughput and response time information.
These tutorials use a sample database application called PersonPB. This application is included on the SilkPerformer CD-ROM and is installed in the SampleApps\Oracle subfolder of the SilkPerformer home directory. To perform this tutorial Oracle Client software must be installed on your computer.
Oracle client

In this tutorial you will learn how to create a load-testing project and execute sample scripts provided with SilkPerformer. You will run a sample script with a single virtual user on your local machine. You will use the OraLoadPers.bdf test script, which is included in the Working\Samples\Database\Oracle folder of your SilkPerformer installation. This script creates the tables that the PersonPB application requires and inserts data into your database that is required for the remaining tutorials.

For each server you load test with SilkPerformer, you must create a project file. A project file administers all the settings that are associated with a series of load tests, including test type, workload model, and options that depend on the server type under test. In addition, project files enable you to easily switch between different load-testing projects without having to define new settings each time.
Creating a project
Procedure To create your load-testing project: 1 Open SilkPerformer. Close any open projects (SilkPerformer opens with the last project you worked on). 2 On the Workflow bar, click Start here.
42
3 4 5 6
In the Project name text box, enter PersonPB as the name of your loadtesting project. In the Project description text box, enter a short description of your project (used for project management purposes). In the Application type list, select the Oracle option. Click OK. SilkPerformer creates a new load-testing project called PersonPB with the default settings profile and your local computer as the only agent.

To run a load test, you must have a test script. Each project contains one or more load-testing scripts. Such scripts define one or a group of virtual users and the actions they perform. Usually, such scripts are modeled on real-world behavior. In this tutorial you will use a Sample script provided by SilkPerformer. Before you can run the load-testing script, you must add it to your project.
Procedure To add a predefined script to your project: 1 On the SilkPerformer workflow bar, click Model Script.
43
In the Script area, click the Sample script option button to open one of the scripts that accompany SilkPerformer and add it to your current project. Click OK. The Open dialog box opens. Navigate to the Working\Samples\Database\Oracle folder in your SilkPerformer installation and select the OraLoadPers.bdf script. Click Open. A SilkPerformer Message dialog box opens. This dialog box asks you whether you wish to add the test script to your load-testing project.
3 4 5
Click Yes to add the selected test script to your project. SilkPerformer adds the OraLoadPers.bdf test script to the Scripts folder of your current project and displays the script in a new editor window.
Personalizing the sample script

The OraLoadPers script contains three constant declarations that specify the database to which the virtual users connect. Before you can execute the script, you must change these constant values so that the users connect to your database.
Personalizing the test
Procedure To personalize the sample load-testing script: 1 In the Active Script window, select Symbols/Constants/USERNAME.
44
You see the following code:

const USERNAME PASSWORD CONNECTSTRING := "user"; // specify YOUR user name here := "password"; // specify YOUR password here := "orclnet2"; // specify the Oracle connect string
2 3 4 5
Replace the user string with the user name you wish to use to connect to the database. Replace the password string with the password you specified for the user. Replace the orclnet2 string with the connection string that refers to your database. Select File/Save from the menu bar to save your changes.

Three user groups are set up in the OraLoadPers test script: Creator: A virtual user of this group creates the tables that the PersonPB application requires. Loader: A virtual user of this group loads sample data into the database so that the PersonPB application can be load tested under real-world conditions. Dropper: A virtual user of this group removes the sample data and deletes the tables that were created earlier for PersonPB.
To create the tables and insert the sample data for the remaining tutorials, you must first run a virtual user of the Creator group and then a user of the Loader group.
Procedure To execute the OraLoadPers test script: 1 2 In the Active Script window, expand the User Groups folder. In the User Groups folder, right-click Creator and select Run User Creator. SilkPerformer runs a virtual user, performing all the actions defined in the test script (i.e., creating the tables in the database that the PersonPB application requires). While the virtual user runs, you can watch its progress in the Monitor window (e.g., number of transactions executed, response time of the last transaction, and average response time). 3 Monitor the load test and wait until the virtual user has finished executing its tasks.
45
In the top part of the Monitor window, select an agent computer or a user group that you wish to monitor. In the bottom part of the Monitor window, SilkPerformer displays overview information about the virtual users running on the selected agent computer, or belonging to the selected user group.
In the bottom part of the Monitor window, you can right-click a virtual user to view detailed information and select Show Output. SilkPerformer then displays detailed run-time information about the selected user in the Virtual User window at the bottom (e.g., transactions and functions the user executes, and the data the user sends to and receives from the server). The type of information displayed depends on the options selected at the top of the Monitor window. Display Errors. Select this button to display appropriate error messages indicating the probable causes of user-related errors. Display Transactions. Select this button to display a message when a user has finished executing a transaction; messages indicate whether or not transactions were successful. Display Functions. Select this button to display a message for each function call a given user performs, including function name and its parameters. Display Info. Select this button to display messages containing additional information about the current action a given user performs. Display Data. Select this button to show data exchanged with the server. Display all Errors of all Users. Select this button to display error messages for all errors of all users. Each error message indicates user, agent and probable cause.
4 5
From the menu bar, select File/Close to close the Monitor window. In the User Groups folder, right-click Loader and select Run User Loader. SilkPerformer runs a virtual user that inserts sample data into the previously created tables.
In Tutorial 1, you learned how to: Create a load-testing project Add a predefined script to a project Execute a script with one virtual user
46
3 LOAD TESTING AN ORACLE OCI7 DATABASE Tutorial 2: Creating a script with the Recorder
View progress information for a load test

The SilkPerformer Recorder allows you to capture database traffic transferred between a client application and a server. After you record database traffic, you can save it as a test script. You can then easily customize the script and replay it to simulate a large number of virtual users. Recording, customizing, and replaying scripts is covered in depth in Tutorials 2, 3, and 4. In Tutorial 5, you will analyze the results of a load test. This tutorial includes the following steps: Setting up an application profile Recording traffic between a client application and a server Generating a test script based on recorded traffic Trying out a generated test script Validating a generated test script

When you want the SilkPerformer Recorder to capture traffic exchanged between a client application and a server, you must set up a profile for the client application. Profiles specify client application type and what traffic is to be recorded.
Procedure To set up a profile for the client application: 1 From the menu bar, select Settings/System. The System Settings Workbench dialog box opens.
47
In the shortcut list on the left, click the Recorder icon.
48
4 5
In the Application profile text box, enter a name for the application profile, for example PersonPB. Click Browse and locate the executable called PersonPB.exe. This file is located in the SampleApps\Oracle subfolder of the SilkPerformer home directory. From the Application type list box, select the Custom Application option. In the API selection area, select the Oracle option. Click OCI Settings.... The Oracle OCI Settings dialog box opens. From the list box select Ociw32.dll. Click OK. SilkPerformer adds the new application profile to the profile list in the System Settings Recorder dialog box.
6 7 8 9
10 Click OK.
11 Click OK to close the dialog box.
49

To load test a database, traffic between the client application and a server must be recorded and described in a test script. The script enables any number of virtual users to perform actions similar to those that were performed during the recording session. To create as realistic a load test as possible, you will record five separate transactions in a single recording session: Logging on to the database Searching for customer information Updating a customer record Inserting a new customer record Logging off from the database
When you run the load test, you will create three user groups to which you will assign each of the above tasks in a ratio that simulates real-world behavior.
Procedure To model a load-testing script: 1 On the Workflow bar, click the Model Script button. The Workflow Model Script dialog box opens.
2 3 4
In the Script area, select the Record option. From the Select application profile list box, select PersonPB. Click OK. SilkPerformer opens the Recorder and starts the PersonPB application.
50
In the Recorder, click the New Transaction button to insert a new transaction into the test script you are generating. Confirm the next SilkPerformer Recorder message by clicking Yes. The following dialog box opens.
Create a new transaction called TLogon; then click OK. A distinct set of time measurements will be made for each transaction you create. When recording traffic, you should create a new transaction for each distinct user session, from connection to shutdown. In the Login dialog box of the PersonPB application, select OCI from the DBMS list box.
8 9
Enter the database connection string, user name, and password for logging on to the database. Click Login.
51
The Customer window opens.
The Recorder records the database traffic automatically as you connect to the database. 10 To view your actions and the function calls that the PersonPB application performs, click the Change GUI Size button. The SilkPerformer Recorder window displays as follows.
11 In the Recorder, create a new transaction called TSearch. 12 In the Customer OCI dialog box, enter a last name for which you wish to search, for example Williams, and press Select.
52
13 In the PersonPB application, perform the following additional steps. Before you perform each step, create a new transaction with a name that describes the user session, for example TUpdate or TInsert. a b Change the customer address Insert a new customer record
Note For detailed information on using the PersonPB sample application, refer to the SilkPerformer PersonPB Reference. 14 On the Recorder, create a new transaction called TLogoff. 15 In the Customer OCI window, select File/Exit from the menu bar. 16 On the Recorder, click the Stop Recording button. The Save As dialog box opens. 17 In the File name text box, enter PersonPB. 18 Click Save. 19 You can now decide whether or not to close the Recorder. If you keep the Recorder open, you can examine the script that was generated.
20 Close the Recorder. SilkPerformer then automatically adds the script to your current loadtesting project.
53

Next you should do a trial run of the test script that was created. The object of the trial run is to ensure that the script is error free, and that it accurately reproduces the interaction between the client application and the database server.
2 3
From the Script list box, select the PersonPB.bdf script. Click Run. SilkPerformer runs a single virtual user, called VUser, which performs all the actions that were performed during the recording session. While the single-user test runs, you can watch its progress.
54
The Try Script run failed because of an error. The " unique constraint violation " error message in the Virtual User output tab indicates that the script attempted to insert a record with a primary key that was not unique within the data table. Your script attempted to use the same value that was used during recording. This is a typical problem when replaying scripts that include session dependent, dynamic information. Tutorial 3 shows you how to customize your script to handle such session dependent, dynamic information. Specifically the script attempted to add a new person record that didnt have a unique person ID. Person IDs are numbers from 1 to 9999. The highest used person ID value is stored by the PersonPB sample application in a separate data table. Before adding a new record, PersonPB retrieves the value of the highest used person ID, increments the number up by one, and updates the data table. Then it retrieves the new value and uses it as an input parameter for the insert statement.
In Tutorial 2, you learned how to: Set up an application profile Record traffic between a client application and a database Generate a test script based on recorded traffic Try out a generated test script
55
3 LOAD TESTING AN ORACLE OCI7 DATABASE Tutorial 3: Customizing a generated test script
Tutorial 3: Customizing a generated test script

Customizing a generated test script allows you to use the actions performed by a single user to realistically simulate the actions of multiple users. Three key tasks assist in creating real-world simulations: Handling session dependent, dynamic information Replacing constant values with random variables Specifying the tasks each user is to perform Note Customizing a test script can be done through either SilkPerformer Workbench or Silk TrueLog Explorer (TrueLog Explorer). When using SilkPerformer Workbench to customize generated test scripts you must use Benchmark Description Language (BDL), SilkPerformer's high-level scripting language. Although knowledge of BDL is not required for this tutorial, it is recommended that you read the BDL introductory topics in SilkPerformers online help system. No knowledge of BDL is required to use TrueLog Explorer. TrueLog Explorer performs all script manipulation for you. In this tutorial TrueLog Explorer is used to handle session relevant information. To learn more about the functionality and use of TrueLog Explorer, please refer to the TrueLog Explorer Help.
Handling session dependent, dynamic information

Script customization must be performed whenever session dependent, dynamic information is used by a database application. In most cases customization involves parsing the result value of a database operation into a variable and substituting the input parameter value of another database operation with the parsed value. Tutorial 2: Creating a script with the Recorder explained the problem of not using a unique primary key within a database table and generating an unique constraint violation error. To handle this situation the result of a database operation must be parsed into a variable. The variables value must then be used in place of the recorded value as an input parameter for a subsequent database call.
56
3 LOAD TESTING AN ORACLE OCI7 DATABASE Tutorial 3: Customizing a generated test script Parsing a result into a variable
Procedure To parse the result of a database operation into a variable: 1 After performing a Try Script run, right click the VUser Try Script status line in the Monitor window and choose Explore TrueLog.
TrueLog Explorer launches, loaded with the replay TrueLog of your Try Script run. 2 Click Analyze Test on the TrueLog Explorer Workflow bar. The Workflow - Analyze Test dialog box opens.
57
Click Find Errors. Click the Errors option button on the Step Through TrueLog dialog box. Continue clicking Find Next until you receive a No more Errors message.
The database operation that caused your Try Script run to fail is now selected. On the Info tab you can see an error message that describes the reason for the failure. 4 Now select the closest preceding Fetch statement. Select the value in the output parameter table, right-click, and choose Parse Element Value.
58
The Insert Element Value Parsing Function dialog box displays.
Specify the name of the variable you want the value to be parsed into in the Parameter name text box, for example sCustomerId, and click OK. Confirm the following message box by clicking OK. Click the BDL tab in the lower section of TrueLog Explorer. TrueLog Explorer then adds the following lines to your script.
sCustomerId := RsGetString("1", 1); Print("sCustomerId: " + sCustomerId);
59
Additionally TrueLog Explorer declares a global variable in the dclparam section of your script.
dclparam sCustomerId Substitution of an input parameter : string;
Procedure To substitute an input parameter with a variable: 1 After parsing the session relevant data into a variable you can use the value of the variable rather than the formerly passed parameter value as input for a database operation. In this case you must substitute the parameter value passed to the database operation that caused your Try Script run to fail. To do this, select the database operation node immediately preceding the node that failed, right click the left-most element in the input parameter view and choose Customize Value.
60
The Parameter Wizard - Customize Value dialog box opens.
Select Use existing parameter and click Next to proceed. 3 The Parameter Wizard - Use Existing Parameter dialog box opens.
Select the name of the variable for which you previously created the parsing function, for example sCustomerId, and click Finish. Confirm the following message box by clicking OK, and click the BDL tab in the lower section of TrueLog Explorer. TrueLog Explorer then adds the following lines to your script.
// OraSetString(c0, ":1", "2011"); OraSetString(c0, ":1", sCustomerId);
61
Handling of session dependent, dynamic information is now complete. Close TrueLog Explorer, activate SilkPerformer Workbench, and do a trial run of the customized script as was shown in Tutorial 2. The Try Script run should now proceed without error.
62

When randomized data is required, random variables are employed to provide realistic user data. In this way, SilkPerformer furnishes virtual users with varied personal data, for example name, address, and phone number.
Procedure To replace constant values with random variables: Note Ensure that the PersonPB.bdf script is active in SilkPerformer Workbench. To do this, click the PersonPB.bdf tab. 1 In the Workflow bar, click the Customize Test button. The Workflow Customize Test dialog box opens.
Click the Create New Parameter Wizard button.
63
The Parameter Wizard - Create New Parameter dialog box opens.
Select Parameter from Random Variable and click Next. The Parameter Wizard - Random Variable dialog box opens.
From the Random type list box, select the String from file type.
64
Click Next.
Enter a name for your variable in the Name edit field, for example rsAddress. In the File area, select Address from the Name list box. This random variable selects an address of up to 35 characters in length from a SilkPerformer file that contains random addresses.
Click Finish. SilkPerformer inserts the following lines into your test script:
dclrand rsAddress : RndFile("Address.rnd", 35);
Locate the TUpdate transaction. Do this by expanding the Transactions folder in the Active Script window and double-clicking TUpdate.
In the TUpdate transaction, locate the section where the UPDATE statement is executed. This section looks like the following:
/*** TUpdate_SQL007: UPDATE "MY_PERSON" SET "P_ALINE1" = :1 WHERE "P_NO" = :2 ; ***/ OraParse(c0, TUpdate_SQL007);
65
OraBind(c0, ":1", SQLT_AVC, 15); OraBind(c0, ":2", SQLT_STR); OraSetString(c0, ":1", "First Avenue"); OraSetString(c0, ":2", "204"); Ora8StmtExecute(ghSvcCtx0, ghStmt0, 1);
10 Replace the fourth parameter of the first OraBind function call with 40. 11 Replace the address that you entered earlier, First Avenue in this case, with the rsAddress variable. The code section should now look like the following. The code shown in bold type is what was changed:
OraParse(c0, TUpdate_SQL007); OraBind(c0, ":1", SQLT_AVC, 40); OraBind(c0, ":2", SQLT_STR); OraSetString(c0, ":1", rsAddress); OraSetString(c0, ":2", "204"); OraExec(c0);
Specifying which tasks each user is to perform

Usually a load test simulates a number of different user types. In the test script, you must specify which action each virtual user type is to perform.
Procedure To specify which tasks each user is to perform: 1 Navigate to the dcluser section of the PersonPB.bdf script file. Do this by selecting User Groups/VUser in the Active Script window. You will see the following:
: : : : : :
begin; 1; 1; 1; 1; 1;
In this section, a single user group called VUser is defined. By default, this user group performs each of the transactions you created (TLogon, TSearch, TUpdate, TInsert, and TLogoff) once. 2 Edit the dcluser section of the script so that it looks like the following:
dcluser user Searcher transactions TLogon
: begin;
66
3 LOAD TESTING AN ORACLE OCI7 DATABASE Tutorial 4: Replaying a customized script

TSearch TLogoff user Updater transactions TLogon TSearch TUpdate TLogoff user Inserter transactions TLogon TSearch TInsert TLogoff : 5; : end;
: : : :
begin; 3; 2; end;
: : : :
begin; 1; 3; end;
In the edited version of the script, the Searcher user group performs the TLogon transaction at the beginning, then the TSearch transaction five times, and finally the TLogoff transaction at the end. The Updater user group performs the TLogon transaction at the beginning, then the TSearch transaction three times, the TUpdate transaction twice, and the TLogoff transaction at the end. The Inserter user group performs the TLogon transaction at the beginning, the TSearch transaction once, the TInsert transaction three times, and the TLogoff transaction at the end. 3 4 5
Select File/Save from the menu bar to save your changes. On the Workflow toolbar, click the Customize Test button. The Workflow Customize Test dialog box opens. Click Yes to confirm that youre done customizing the test script.
In Tutorial 3 you learned how to: Replace constant values with random variables Specify which tasks each virtual user is to perform
Tutorial 4: Replaying a customized script

Once you have created a test script by recording traffic, and then customized the script, you can load test your server by replaying the script. To run a load test you must perform the following steps: Find the test baseline Confirm the test baseline Set up server monitoring for your load test Execute the load test
67

Once you have customized the load-testing script, you must determine baseline performance. This is the ideal performance of your application when it is not under significant pressure. To identify the test baseline, the fully customized script is run with just one user per user group. This will provide a solid basis for comparison when the application is later placed under stress during the load test.
Procedure To find the load test baseline: 1 On the Workflow toolbar, click the Find Baseline button. The Workflow Find Baseline dialog box opens.
This dialog lists all the user groups that have been set up in your test script. 2 Click Run. SilkPerformer runs one virtual user from each user group declared in the test script. While the test runs you can watch its progress in the Monitor window.

After running the baseline test, you must confirm that the test result reflects the desired performance of the tested server. To do this, inspect the results of the test. If they are satisfactory, the baseline has been identified and can later form the basis for comparison with results from full load tests.
68
3 LOAD TESTING AN ORACLE OCI7 DATABASE Tutorial 4: Replaying a customized script Confirming the baseline
Procedure To confirm the load test baseline: 1 On the Workflow toolbar, click the Confirm Baseline button. The Workflow Confirm Baseline dialog box opens.
2 3 4 5 6
Click the Baseline Report button. The Baseline Report opens. Check the report carefully. In particular, make sure that no errors occurred during the baseline test. Click the Accept Baseline button on the Baseline Report. Click Yes and OK on the following dialog boxes. If your baseline report doesnt indicate any errors, click Yes on the Workflow Confirm Baseline dialog box to confirm that you have identified the baseline.

Once you have confirmed your baseline you can select a workload model and prepare the workload to run a full load test.
Procedure To adjust the workload: 1 On the Workflow toolbar, click the Adjust Workload button.
69
This dialog box shows all possible workload models that can be selected. 2 3 Select the Queuing workload model. Click OK. SilkPerformer opens the Workload Configuration dialog box.

Once you have adjusted the workload, youre ready to run a full load test. The test script is run with multiple virtual users to test the database server. For this tutorial, only your local computer is required. A true load test however requires an appropriate testing environment, which you have to set up on the local area network, that offers a full complement of agent computers to host virtual users.
Running the test
Procedure To run the load test: 1 Open the Workload Configuration dialog box.
70
2 3
In the VUsers column, change the number of Inserter users to 25, the number of Searcher users to 50, and the number of Updater users to 25. For each of these user groups, change the simulation time to 300 seconds (5 minutes).
You are now ready to run the load test. When you run a test SilkPerformers sophisticated monitoring tool, Performance Explorer, automatically generates a live graphical display with a default set of test data for the server under test. You can disable this default option by deselecting the setting Automatically start monitoring. You can also change the default monitoring settings by pressing the Active profile button. For additional information, see Customizing server monitoring. Once monitoring has been set up as required, you can run the test. 4 Disable all user groups that are declared in the OraLoadPers test script. 5 Click Run to start the test, or click OK to save the settings and run the test later. When you start the test, SilkPerformer runs the load test against the database server with 100 virtual users. If the default Automatically start monitoring option is enabled, Performance Explorer will open and generate a live graphical display of the specified test data. You can adapt these views by adding and
71
deleting specific measurements. To do this, expand the tree menu on the left and drag and drop selected measurements into existing or new view graphs.

An important feature provided by SilkPerformer is server monitoring during actual load tests. Server monitoring helps you locate and analyze bottlenecks on servers. You can separately examine the performance of the operating system, the network and the server application (which in this case is the Oracle server). Server monitoring is performed using Performance Explorer, a powerful tool incorporated into SilkPerformer. When you run a test, the default procedure has Performance Explorer automatically open a set of views containing a live graphical display of a selection of test data that is relevant to the server under test. You can disable this default option by deselecting the Automatically start monitoring setting on the Workload Configuration dialog. You can also customize the default monitoring settings and select a particular set of data sources.
Customizing server monitoring
Procedure To customize server monitoring for your load test: 1 2 On the Workflow toolbar, click the Run Test button. The Workload Configuration dialog box opens. In the Settings section, click the Active Profile button. The Profile - [Profile1] - Results dialog box opens.
72
3 4
In the shortcut list on the left, select the Replay category and click the Results icon. Select the Monitoring tab The Automatically start monitoring option is activated by default. This means that when you run a load test, Performance Explorer opens automatically using a default template that invokes a display of relevant client information.
If you want to customize monitoring, enable the Use custom monitoring template, and click the Create Custom Monitor Template button. Performance Explorer creates and opens a template with the name of your project, which is the same as the default template.
Click Edit Custom Monitor Template (Performance Explorer opens), to customize the new template and change the information display. You can close or maintain the default monitoring windows and you can add one or more windows to provide additional information. To set up Performance Explorer to display additional information, do the following: a From the menu bar, select Monitor/Add Data Source. The Data Source Wizard opens.
73
Click Next. The Data Source Wizard - System selection dialog box opens.
c d e
In the tree view, expand the folder that corresponds to the operating system on which the database server runs. Select System. Click Next. In the Connection Parameters dialog box, enter connection parameters such as the host name or IP address of the server, the connection port, the user name, and the password. The data you enter here depends on the operating system that runs on the computer you are monitoring.
f g
Click Next once you have entered the connection parameters. In the next dialog box, select the performance counters you wish to monitor. Of particular interest are processor and memory utilization of the server under test.
Click Finish. Performance Explorer opens a new window, displaying real-time data for the performance counters you have selected. In the Monitor tree view, right-click the name of the computer you are monitoring and select Add Data Source. The Data Source Wizard opens. Repeat steps A through E. However this time:
i j k
74
3 LOAD TESTING AN ORACLE OCI7 DATABASE Tutorial 5: Viewing the results of your load test
On the first dialog box, select the name of the Oracle server software rather than System.
II On the third dialog box, select which performance counters you wish to monitor. Later, when you run the load test, the monitor view will look similar to the following:
In Tutorial 4, you learned how to: Find a test baseline Confirm a test baseline Customize monitoring for a load test Adjust a workload Execute a load test

SilkPerformer incorporates Performance Explorer, a powerful graphing and analysis tool, to assist you in working with results information. Performance Explorer enables you to analyze results information with advanced features for creating statistical reports and displaying performance results in real-time generated graphics. Results information varies depending on the type of application and/or server under test. In general, the following is available:
Response time information: This is the total time it takes to process a given timer; it provides application performance information from the client perspective. Throughput information: This is the average rate at which a given timer is processed by the server; it allows you to analyze performance from the server perspective.

Exploring the overview report
Procedure To explore an overview report: 1 On the Workflow toolbar, click the Explore Results button. The Workflow - Explore Results dialog opens.
Click the Performance Explorer button.
76
Performance Explorer opens, and the HTML overview report is generated.
This report offers short explanations of displayed graphs. More detailed information is also available.

When you analyze the performance of an application from the client point of view, you examine the response times of each transaction and timer. This enables you to find out how users will experience interaction with server objects. A common goal in load testing is to find out if response times for all transactions remain below a specified, critical limit.
Response time details
Procedure To explore detailed response time measurements: 1 On the Performance Explorer Workflow bar, click the Select Graph button.
77
The Template dialog opens.
2 3
In the Templates area, select the Timer option. Click Finish. Performance Explorer displays a graph of the active users.
You see the default graph with the average number of active users, and one or more default measurements (if any). 4 5 Expand the Explore tree view. In the Explore tree view, select SQL Commands/TLOGON_SQL001.
78
6 7 8
Drag the Exec measurement into the new view. In the Explore tree view, select SQL Commands/TINSERT_SQL008. Again, drag the Exec measurement into the new view.
The load test you ran in the previous tutorial lasted only five minutes, so there are few measurements, which makes it difficult to draw any conclusions. Real load tests can last several hours, a few days, or even a week. Such complete tests provide result information that allows you to accurately analyze server performance.

When you analyze the performance of a database server from the point of view of the server, you examine the throughput rate. Throughput is work done by a server during a specific time interval (e.g., number of requests that a server processes each second, minute, or hour). A typical goal in load testing is to ensure that throughput rate remains above a specified, critical limit.
Procedure To explore throughput measurements: 1 On the Performance Explorer Workflow bar, click the Select Graph button. The Template dialog opens. 2 3 In the Templates area, select the Database group. Click Finish.
Performance Explorer opens a new chart that resembles the following:
Again, since the load test you ran lasted only five minutes, its difficult to draw conclusions from the results.
80
4
4e rh C t p a
Load Testing an Oracle OCI8 Database

This chapter contains a series of tutorials that will get you started using SilkPerformer to load test Oracle OCI8 databases. This chapter contains the following sections:
Section Page
Overview Tutorial 1: Running a predefined test Tutorial 2: Creating a script with the Recorder Tutorial 3: Customizing a generated test script Tutorial 4: Replaying a customized script Tutorial 5: Viewing the results of a load test
81 82 87 95 107 115
Overview
Each of the following tutorials provides step-by-step instruction for important SilkPerformer tasks. These tutorials should be followed in order, as each tutorial builds on what is covered in the preceding tutorials.
You will learn how to:
Execute a predefined load test on your local machine. Create a test script by recording database traffic using the Recorder. Customize a recorded test script. Run a customized script, using multiple virtual users.
81
Sample: PersonPB7
Use reporting tools to view select throughput and response time information.
These tutorials use a sample database application called PersonPB7. This application is included on the SilkPerformer CD-ROM and is installed in the SampleApps\Oracle subfolder of the SilkPerformer home directory. To perform this tutorial Oracle Client software must be installed on your computer.
Oracle client

In this tutorial you will learn how to create a load-testing project and execute sample scripts provided with SilkPerformer. You will run a sample script with a single virtual user on your local machine. You will use the test script OraLoadPers.bdf, which is included in the Working\Samples\Database\Oracle folder of your SilkPerformer installation. This script creates the tables that the PersonPB7 application requires and inserts data into your database that is required for the remaining tutorials.

For each server you load test with SilkPerformer, you must create a project file. A project file administers all the settings that are associated with a series of load tests, including test type, workload model, and options that depend on the server type under test. In addition, project files enable you to easily switch between different load-testing projects without having to define new settings each time.
Creating a project
Procedure To create your load-testing project: 1 2 3 Open SilkPerformer. Close any open projects (SilkPerformer opens with the last project you worked on). On the Workflow bar, click Start here.
82
4 5 6 7
In the Project name text box, enter PersonPB7 as the name of your load-testing project. In the Project description edit field, enter a short description of your project (used for project management purposes). In the Application type list, select the Oracle option. Click OK. SilkPerformer creates a new load-testing project called PersonPB7 with the default settings profile and your local computer as the only agent.

To run a load test, you must have a test script. Each project contains one or more load-testing scripts. Such scripts define one or a group of virtual users and the actions they perform. Usually, such scripts are modeled on real-world behavior. In this tutorial you will use a Sample script, provided by SilkPerformer. Before you can run the load-testing script, you must add it to your project.
Procedure To add a predefined script to your project: 1 On the SilkPerformer workflow bar, click the Model Script button.
83
In the Script area, click the Sample script option button to open one of the scripts that accompany SilkPerformer and add it to your current project. Click OK. The Open dialog box opens. Navigate to the Working\Samples\Database\Oracle folder in your SilkPerformer installation and select the OraLoadPers.bdf script. Click Open. A SilkPerformer Message dialog box opens. This dialog box asks you whether you wish to add the test script to your load-testing project.
3 4 5
Click Yes to add the selected test script to your project. SilkPerformer adds the OraLoadPers.bdf test script to the Scripts folder of your current project and displays the script in a new editor window.

The OraLoadPers script contains three constant declarations that specify the database to which the virtual users connect. Before you can execute the script, you must change these constant values so that the users connect to your database.
Procedure To personalize the sample load-testing script: 1 In the Active Script window, select Symbols/Constants/USERNAME.
84
You see the following code:

const USERNAME PASSWORD CONNECTSTRING := "user"; // specify YOUR user name here := "password"; // specify YOUR password here := "orclnet2"; // specify the Oracle connect string
2 3 4 5
Replace the user string with the user name you wish to use to connect to the database. Replace the password string with the password you specified for the user. Replace the orclnet2 string with the connection string that refers to your database. Select File/Save from the menu bar to save your changes.

Three user groups are set up in the OraLoadPers test script: Creator: A virtual user of this group creates the tables that the PersonPB7 application requires. Loader: A virtual user of this group loads the sample data into the database so that the PersonPB7 application can be load tested under realworld conditions. Dropper: A virtual user of this group removes the sample data and deletes the tables that were created earlier for PersonPB7.
To create the tables and insert the sample data for the remaining tutorials, you must first run a virtual user of the Creator group and then a user of the Loader group.
Procedure To execute the OraLoadPers test script: 1 2 In the Active Script window, expand the User Groups folder. In the User Groups folder, right-click Creator and select Run User Creator. SilkPerformer runs a virtual user, performing all the actions defined in the test script, that is, creating the tables in the database that the PersonPB7 application requires. While the virtual user runs, you can watch its progress in the Monitor window, for example the number of transactions executed, the response time of the last transaction, and the average response time. 3 Monitor the load test and wait until the virtual user has finished executing its tasks.
85
In the top part of the Monitor window, select an agent computer or a user group that you wish to monitor. In the bottom part of the Monitor window, SilkPerformer displays overview information about the virtual users running on the selected agent computer, or belonging to the selected user group.
In the bottom part of the Monitor window, right-click a virtual user for which you want to view detailed information and select Show Output. SilkPerformer then displays detailed run-time information about the selected user in the Virtual User window at the bottom (e.g., transactions and functions the user executes, and the data the user sends to and receives from the server). The type of information displayed depends on the options selected at the top of the Monitor window. Display Errors. Select this button to display appropriate error messages indicating the probable causes of user-related errors. Display Transactions. Select this button to display a message when a user has finished executing a transaction; messages indicate whether or not transactions were successful. Display Functions. Select this button to display a message for each function call a given user performs, including function name and its parameters. Display Info. Select this button to display messages containing additional information about the current action a given user performs. Display Data. Select this button to show data exchanged with the server. Display all Errors of all Users. Select this button to display error messages for all errors of all users. Each error message indicates user, agent and probable cause.
4 5
From the menu bar, select File/Close to close the Monitor window. In the User Groups folder, right-click Loader and select Run User Loader. SilkPerformer runs a virtual user that inserts sample data into the previously created tables.
In Tutorial 1, you learned how to: Create a load-testing project Add a predefined script to a project
86
Execute a script with one virtual user View progress information for a load test

The SilkPerformer Recorder allows you to capture database traffic transferred between a client application and a server. After you record database traffic, you can save it as a test script. You can then easily customize the script and replay it to simulate a large number of virtual users. Recording, customizing, and replaying scripts is covered in depth in Tutorials 2, 3, and 4. In Tutorial 5, you will analyze the results of a load test. This tutorial includes the following steps: Setting up an application profile Recording traffic between a client application and a server Generating a test script based on recorded traffic Trying out a generated test script Validating a generated test script

When you want the SilkPerformer Recorder to capture traffic exchanged between a client application and a server, you must set up a profile for the client application. Profiles specify client application type and what traffic is to be recorded.
Procedure To set up a profile for the client application: 1 From the menu bar, select Settings/System. The System Settings Workbench dialog box opens.
87
The list contains all the application profiles that are currently set up on your computer. 3 Click Add. The Application Profile dialog box opens.
In the Application profile text box, enter a name for the application profile, for example PersonPB7.
88
Click Browse and locate the executable called PersonPB7.exe. This file is located in the SampleApps\Oracle subfolder of the SilkPerformer home directory. From the Application type list box, select the Custom Application option. In the API selection area, select the Oracle option. Click OCI Settings.... The Oracle OCI Settings dialog box opens. From the list box select Oci.dll. Click OK. SilkPerformer adds the new application profile to the profile list in the System Settings Recorder dialog box.
6 7 8 9
10 Click OK.

To load test a database, traffic between the client application and a server must be recorded and described in a test script. The script enables any number of virtual users to perform actions similar to those that were performed during the recording session. To create as realistic a load test as possible, you will record five separate transactions in a single recording session: Logging on to the database Searching for customer information Updating a customer record Inserting a new customer record Logging off from the database
When you run the load test, you will create three user groups to which you will assign each of the above tasks in a ratio that simulates real-world behavior.
Procedure To model a load-testing script: 1 On the Workflow bar, click the Model Script button.
89
2 3 4 5
In the Script area, select the Record option. From the Select application profile list box, select PersonPB7. Click OK. SilkPerformer opens the Recorder and starts the PersonPB7 application. In the Recorder, click the New Transaction button to insert a new transaction into the test script you are generating. Confirm the next SilkPerformer Recorder message by clicking Yes. The following dialog box opens.
Create a new transaction called TLogon; then click OK. A distinct set of time measurements will be made for each transaction you create. When recording traffic, you should create a new transaction for each distinct user session, from connection to shutdown.
90
In the Login dialog box of the PersonPB7 application, select O84 from the DBMS list box.
8 9
Enter the database connection string, user name, and password for logging on to the database. Click Login. The Customer window opens.
The Recorder records the database traffic automatically as you connect to the database. 10 To view your actions and the function calls that the PersonPB7 application performs, click the Change GUI Size button.
91
The SilkPerformer Recorder window displays as follows.
11 In the Recorder, create a new transaction called TSearch. 12 In the Customer OCI dialog box, enter a last name for which you wish to search, for example Williams, and press Select. 13 In the PersonPB7 application, perform the following additional steps. Before you perform each step, create a new transaction with a name that describes the user session, for example TUpdate or TInsert. a b Change the customer address Insert a new customer record.
Note For detailed information on using the PersonPB7 sample application, refer to the SilkPerformer PersonPB Reference. 14 On the Recorder, create a new transaction called TLogoff. 15 In the Customer OCI window, select File/Exit from the menu bar. 16 On the Recorder, click the Stop Recording button. The Save As dialog box opens. 17 In the File name text box, enter PersonPB7. 18 Click Save. 19 You can now decide whether or not to close the Recorder.
92 SilkPerformer Tutorials
If you keep the Recorder open, you can examine the script that was generated.
20 Close the Recorder. SilkPerformer then automatically adds the script to your current loadtesting project.

Next you should do a trial run of the test script that was created. The object of the trial run is to ensure that the script is error free, and that it accurately reproduces the interaction between the client application and the database server.
93
4 LOAD TESTING AN ORACLE OCI8 DATABASE Tutorial 2: Creating a script with the Recorder Trying out the script
2 3
From the Script list box, select the PersonPB7.bdf script. Click Run. SilkPerformer runs a single virtual user, called VUser, which performs all the actions that were performed during the recording session. While the single-user test runs, you can watch its progress.
The Try Script run failed because of an error. The " unique constraint violation " error message in the Virtual User output tab indicates that the
script attempted to insert a record with a primary key that was not unique within the data table. Your script attempted to use the same value that was used during recording. This is a typical problem when replaying scripts that include session dependent, dynamic information. Tutorial 3 shows you how to customize your script to handle such session dependent, dynamic information. Specifically the script attempted to add a new person record that didnt have a unique person ID. Person IDs are numbers from 1 to 9999. The highest used person ID is stored by the PersonPB7 sample application in a separate data table. Before adding a new record, PersonPB7 retrieves the value of the highest used person ID, increments the number up by one, and updates the data table. Then it retrieves the new value and uses it as an input parameter for the insert statement.
In Tutorial 2, you learned how to: Set up an application profile Record traffic between a client application and a database Generate a test script based on recorded traffic Try out a generated test script

Customizing a generated test script allows you to use the actions performed by a single user to realistically simulate the actions of multiple users. Three key tasks assist in creating real-world simulations: Handling session dependent, dynamic information Replacing constant values with random variables Specifying the tasks each user is to perform Note Customizing a test script can be done through either SilkPerformer Workbench or TrueLog Explorer. When using SilkPerformer Workbench to customize generated scripts you must use Benchmark Description Language (BDL), SilkPerformer's highlevel scripting language. Although knowledge of BDL is not required for this tutorial, it is recommended that you read the BDL introductory topics in SilkPerformers online help system. No knowledge of BDL is required to use TrueLog Explorer. TrueLog Explorer performs all script manipulation for you. In this tutorial TrueLog Explorer is used to handle session relevant information. To learn more about the
95
functionality and use of TrueLog Explorer, please refer to the TrueLog Explorer Help.
Handling session dependent, dynamic information

Script customization must be performed whenever session dependent, dynamic information is used by a database application. In most cases customization involves parsing the result value of a database operation into a variable and substituting the input parameter value of another database operation with the parsed value. Tutorial 2: Creating a script with the Recorder explained the problem of not using a unique primary key within a database table and generating an unique constraint violation error. To handle this situation the result of a database operation must be parsed into a variable. The variables value must then be used in place of the recorded value as an input parameter for a subsequent database call.
Parsing a result into a variable
Procedure To parse the result of a database operation into a variable: 1 After performing a Try Script run, right click the VUser Try Script status line in the Monitor window and choose Explore TrueLog.
TrueLog Explorer launches, loaded with the replay TrueLog of your Try Script run. 2 Click Analyze Test on the TrueLog Explorer Workflow bar. The Workflow - Analyze Test dialog box opens.
96
Click Find Errors. Click the Errors option button on the Step Through TrueLog dialog box. Continue clicking Find Next until you receive a No more Errors message.
97
The database operation that caused your Try Script run to fail is now selected. On the Info tab you can see an error message that describes the reason for the failure. 4 Now select the closest preceding Fetch statement. Select the value in the output parameter table, right-click, and choose Parse Element Value.
98
The Insert Element Value Parsing Function dialog box opens.
Specify the name of the variable you want the value to be parsed into in the Parameter name field for example sCustomerId, and click OK. Confirm the following message box by clicking OK. Click the BDL tab in the lower section of TrueLog Explorer. TrueLog Explorer then adds the following lines to your script.
sCustomerId := RsGetString("1", 1); Print("sCustomerId: " + sCustomerId);
99
Additionally TrueLog Explorer declares a global variable in the dclparam section of your script.
dclparam sCustomerId Substitution of an input parameter : string;
Procedure To substitute an input parameter with a variable: 1 After parsing the session relevant data into a variable you can use the value of the variable rather than the formerly passed parameter value as input for a database operation. In this case you must substitute the parameter value passed to the database operation that caused the Try Script run to fail. To do this, select the database operation node immediately preceding the node that failed, right click the left-most element in the input parameter view and choose Customize Value.
100
The Parameter Wizard - Customize Value dialog box opens.
Select Use existing parameter and click Next to proceed. 3 The Parameter Wizard - Use Existing Parameter dialog box opens.
Select the name of the variable for which you previously created the parsing function, for example sCustomerId, and click Finish. Confirm the following message box by clicking OK, and click the BDL tab in the lower section of TrueLog Explorer. TrueLog Explorer then adds the following lines to your script:
// Ora8SetString(ghStmt0, ":1", "2001"); Ora8SetString(ghStmt0, ":1", sCustomerId);
101
Handling of session dependent, dynamic information is now complete. Close TrueLog Explorer, activate SilkPerformer Workbench, and do a trial run of the customized script as was shown in Tutorial 2. The Try Script run should now proceed without error.
102

When randomized data is required, random variables are employed to provide realistic user data. In this way, SilkPerformer furnishes virtual users with varied personal data, for example name, address, and phone number.
Procedure To replace constant values with random variables: Note Ensure that the PersonPB7.bdf script is active in SilkPerformer Workbench. To do this, click the PersonPB7.bdf tab. 1 In the Workflow bar, click the Customize Test button. The Workflow Customize Test dialog box opens.
Click the Create New Parameter Wizard button.
103
The Parameter Wizard - Create New Parameter dialog box opens.
From the Random type list box, select the String from file type.
104
Click Next.
Enter a name for your variable in the Name edit field, for example rsAddress. In the File area, select Address from the Name list box. This random variable selects an address of up to 35 characters in length from a SilkPerformer file that contains random addresses.
dclrand rsAddress : RndFile("Address.rnd", 35);
Locate the TUpdate transaction. Do this by expanding the Transactions folder in the Active Script window and double-clicking TUpdate.
In the TUpdate transaction, locate the section where the UPDATE statement is executed. This section looks like the following.
/*** TUpdate_SQL007: UPDATE "MY_PERSON" SET "P_ALINE1" = :1 WHERE "P_NO" = :2 ; ***/ Ora8StmtPrepare(ghStmt0, TUpdate_SQL007, OCI_NTV_SYNTAX);
105
Ora8Bind(ghStmt0, ":1", SQLT_AVC, 15); Ora8Bind(ghStmt0, ":2", SQLT_CHR, 3); Ora8SetString(ghStmt0, ":1", "First Avenue"); Ora8SetString(ghStmt0, ":2", "204"); Ora8StmtExecute(ghSvcCtx0, ghStmt0, 1);
10 Replace the fourth parameter of the first Ora8Bind function call with 40. 11 Replace the address that you entered earlier (First Avenue in this case) with the rsAddress variable. The code section should now look like the following. The code shown in bold type is what was changed.
Ora8StmtPrepare(ghStmt0, TUpdate_SQL007, OCI_NTV_SYNTAX); Ora8Bind(ghStmt0, ":1", SQLT_AVC, 40); Ora8Bind(ghStmt0, ":2", SQLT_CHR, 3); Ora8SetString(ghStmt0, ":1", rsAddress); Ora8SetString(ghStmt0, ":2", "204"); Ora8StmtExecute(ghSvcCtx0, ghStmt0, 1);
Specifying which tasks each user is to perform

Usually a load test simulates a number of different user types. In the test script, you must specify which action each virtual user type is to perform.
Procedure To specify which tasks each user is to perform: 1 Navigate to the dcluser section of the PersonPB7.bdf script file. Do this by selecting User Groups/VUser in the Active Script window. You will see the following:
: : : : : :
begin; 1; 1; 1; 1; 1;
In this section, a single user group called VUser is defined. By default, this user group performs each of the transactions you created (TLogon, TSearch, TUpdate, TInsert, and TLogoff) once. 2 Edit the dcluser section of the script so that it looks like the following.
dcluser user Searcher transactions TLogon
: begin;
106

TSearch TLogoff user Updater transactions TLogon TSearch TUpdate TLogoff user Inserter transactions TLogon TSearch TInsert TLogoff : 5; : end;
: : : :
begin; 3; 2; end;
: : : :
begin; 1; 3; end;
In the edited version of the script, the Searcher user group performs the TLogon transaction at the beginning, then the TSearch transaction five times, and finally the TLogoff transaction at the end. The Updater user group performs the TLogon transaction at the beginning, the TSearch transaction three times, the TUpdate transaction twice, and the TLogoff transaction at the end. The Inserter user group performs the TLogon transaction at the beginning, the TSearch transaction once, the TInsert transaction three times, and the TLogoff transaction at the end. 3 4 5
Select File/Save from the menu bar to save your changes. On the Workflow toolbar, click the Customize Test button. The Workflow Customize Test dialog box opens. Click Yes to confirm that youre done customizing the test script.
In Tutorial 3, you learned how to: Replace constant values with random variables Specify which tasks each virtual user is to perform

Once you have created a test script by recording traffic, and then customized the script, you can load test your server by replaying the script. To run a load test, you must perform the following steps: Find the test baseline Confirm the test baseline Set up server monitoring for your load test Execute the load test
107

Once you have customized the load-testing script, you must determine baseline performance. This is the ideal performance of your application when it is not under significant pressure. To identify the test baseline, the fully customized script is run with just one user per user group. This will provide a solid basis for comparison when the application is later placed under stress during the load test.
Procedure To find the load test baseline: 1 On the Workflow toolbar, click the Find Baseline button. The Workflow Find Baseline dialog box opens.
This dialog box lists all the user groups that have been set up in your test script. 2 Click Run. SilkPerformer runs one virtual user from each user group declared in the test script. While the test runs, you can watch its progress in the Monitor window.

After running the baseline test, you must confirm that the test result reflects the desired performance of the tested server. To do this, inspect the results of the test. If they are satisfactory, the baseline has been established and can later form the basis for comparison with results from full load tests.
108
4 LOAD TESTING AN ORACLE OCI8 DATABASE Tutorial 4: Replaying a customized script Confirming the baseline
Procedure To confirm the load test baseline: 1 On the Workflow toolbar, click the Confirm Baseline button. The Workflow Confirm Baseline dialog box opens.
2 3 4 5 6
Click the Baseline Report button. The Baseline Report opens. Check the report carefully. In particular, make sure that no errors occurred during the baseline test. Click the Accept Baseline button on the Baseline Report. Click Yes and OK on the following dialog boxes. If your baseline report doesnt indicate any errors, click Yes on the Workflow Confirm Baseline dialog box to confirm that you have identified the baseline.

Once you have confirmed your baseline you can select a workload model and prepare the workload to run a full load test.
109
This dialog box shows all possible workload models that can be selected. 2 3 Select the Queuing workload model. Click OK. SilkPerformer opens the Workload Configuration dialog box.

Once you have adjusted the workload, youre ready to run a full load test. The test script is run with multiple virtual users to test the database server. For this tutorial, only your local computer is required. A true load test however requires an appropriate testing environment, set up on the local area network, that offers a full complement of agent computers to host virtual users.
Running the test
110
2 3
In the VUsers column, change the number of Inserter users to 25, the number of Searcher users to 50, and the number of Updater users to 25. For each of these user groups, change the simulation time to 300 seconds (5 minutes).
You are now ready to run the load test. When you run a test SilkPerformers sophisticated monitoring tool, Performance Explorer, automatically generates a live graphical display with a default set of test data for the server under test. You can disable this default option by deselecting the Automatically start monitoring setting. You can also change the default monitoring settings by pressing the Active profile button (See Customizing server monitoring). Once monitoring has been set up as required, you can run the test. 4 Disable all user groups that are declared in the OraLoadPers test script. 5 Click Run to start the test, or click OK to save the settings and run the test later. When you start the test, SilkPerformer runs the load test against the database server with 100 virtual users. If the default Automatically start monitoring option is enabled, Performance Explorer will open and generate a live graphical display of the specified test data. You can adapt these views by adding and
111
deleting specific measurements. To do this expand the tree menu on the left and drag and drop selected measurements into existing or new view graphs.

An important feature provided by SilkPerformer is server monitoring during actual load tests. Server monitoring helps you locate and analyze bottlenecks on servers. You can separately examine the performance of the operating system, the network and the server application (which in this case is the Oracle server). Server monitoring is performed using Performance Explorer, a powerful tool incorporated into SilkPerformer. When you run a test, the default procedure has Performance Explorer automatically open a set of views containing a live graphical display of a selection of test data that is relevant to the server under test. You can disable this default option by deselecting the Automatically start monitoring setting on the Workload Configuration dialog. You can also customize the default monitoring settings and select a particular set of data sources.
Procedure To customize server monitoring for your load test: 1 2 On the Workflow toolbar, click the Run Test button. The Workload Configuration dialog box opens. In the Settings section, click the Active Profile button. The Profile - [Profile1] - Results dialog box opens.
112
3 4
In the shortcut list on the left, select the Replay category and click the Results icon. Select the Monitoring tab The Automatically start monitoring option is activated by default. This means that when you run a load test, Performance Explorer opens automatically using a default template that invokes a display of relevant client information.
If you want to customize monitoring, enable the Use custom monitoring template, and click the Create Custom Monitor Template button. Performance Explorer creates and opens a template with the name of your project, which is the same as the default template.
Click Edit Custom Monitor Template (Performance Explorer opens) to customize the new template and change the information display. You can close or maintain the default monitoring windows and you can add one or more windows to provide additional information. To set up Performance Explorer to display additional information, do the following: a From the menu bar, select Monitor/Add Data Source. The Data Source Wizard opens.
113
c d e
In the tree view, expand the folder that corresponds to the operating system on which the database server runs. Select System. Click Next. In the Connection Parameters dialog box, enter connection parameters, like the host name or IP address of the database server, the connection port, the user name, and the password. The data you enter here depends on the operating system that runs on the computer you are monitoring. Click Next once you have entered the connection parameters. In the next dialog box, select the performance counters you wish to monitor. Of particular interest are processor and memory utilization of the server under test.
f g h
i j k l
Click Finish. Performance Explorer opens a new window, displaying real-time data for the performance counters you have selected. In the Monitor tree view, right-click the name of the computer you are monitoring and select Add Data Source. The Data Source Wizard opens.
m Repeat steps A through E. However this time:
114
4 LOAD TESTING AN ORACLE OCI8 DATABASE Tutorial 5: Viewing the results of a load test
On the first dialog box, select the name of the Oracle server software rather than System.
II On the third dialog box, select which performance counters you wish to monitor. Later, when you run the load test, the monitor view will look similar to the following.
In Tutorial 4, you learned how to: Find a test baseline Confirm a test baseline Customize monitoring for a load test Adjust a workload Execute a load test
Tutorial 5: Viewing the results of a load test

SilkPerformer incorporates Performance Explorer, a powerful graphing and analysis tool, to assist you in working with results information. Performance Explorer enables you to analyze results information with advanced features for creating statistical reports and displaying performance results in real-time generated graphics. Results information varies depending on the type of application and/or server under test. In general, the following is available:
Response time information: This is the total time it takes to process a given timer; it provides application performance information from the client perspective. Throughput information: This is the average rate at which a given timer is processed by the server; it allows you to analyze performance from the server perspective.

Procedure To explore an overview report: 1 On the Workflow toolbar, click the Explore Results button. The Workflow - Explore Results dialog box opens.
116

117
The Template dialog box opens.
2 3
In the Templates area, select the Timer option. Click Finish. Performance Explorer displays a graph of the active users.
You see the default graph with the average number of active users, and one or more default measurements (if any). 4 5 Expand the Explore tree view. In the Explore tree view, select SQL Commands/TLOGON_SQL001.
118
6 7 8
Drag the Exec measurement into the new view. In the Explore tree view, select SQL Commands/TINSERT_SQL008. Again, drag the Exec measurement into the new view.
The load test you ran in the previous tutorial lasted only five minutes, so there are few measurements, which makes it difficult to draw any conclusions. Real load tests can last several hours, a few days, or even a week. Such complete tests provide results information that allows you to accurately analyze server performance.

When you analyze the performance of a database server from the point of view of the server, you examine throughput rate. Throughput is work done by a server during a specific time interval (e.g., number of requests that a server processes within a second, minute, or hour). A typical goal in load testing is to ensure that throughput rate remains above a specified, critical limit.
Procedure To explore throughput measurements: 1 On the Performance Explorer Workflow bar, click the Select Graph button. The Template dialog box opens. 2 3 In the Templates area, select the Database group. Click Finish.
Performance Explorer opens a new chart that resembles the following.
Again, since the load test you ran lasted only five minutes, its difficult to draw conclusions from the results.
120
5
5e rh C t p a
Load Testing a CORBA Application

This chapter contains a series of tutorials that will help you to start load-testing CORBA applications with SilkPerformer. This chapter contains the following sections:
Section Page
Overview Tutorial 1: Running a sample load test Tutorial 2: Creating a script with the Recorder Tutorial 3: Customizing the generated test script Tutorial 4: Replaying the customized script Tutorial 5: Viewing the results of your load test
121 122 126 133 137 145
Overview
Each of the following tutorials provides step-by-step instructions for important SilkPerformer tasks. You should perform the tutorials in order, since each tutorial builds on what you have learned in the previous ones. You will learn how to do the following: Execute a predefined load test on your local machine. Create a test script by recording IIOP traffic using the Recorder. Customize the recorded test script.
121
5 LOAD TESTING A CORBA APPLICATION Tutorial 1: Running a sample load test

Sample: VisiBroker Bank application
Run the customized script, using multiple virtual users. Use reporting tools to view throughput and response time information.
These tutorials use the sample CORBA Bank application that accompanies Inprise VisiBroker. This application is included on the VisiBroker CD-ROM and should have been installed in the examples\basic\bank_agent subfolder of the VisiBroker home directory as part of the installation and setup.
Tutorial 1: Running a sample load test

In this tutorial you will learn to create a load-testing project and execute sample scripts that are provided with SilkPerformer. You will run one of the sample scripts with a single virtual user on your local machine. You will use the test script VBrokerBank01.bdf, which is included in the Working\Samples\CORBA\VisiBroker folder in the SilkPerformer folder. This sample was created using VisiBroker 4.5.

For each server you load test with SilkPerformer, you have to create a project file. A project file administers all the settings that are associated with a series of load tests, like the test type, the workload model, and a number of options that depend on the type of server being tested.
Creating a project
Procedure To create your load-testing project: 1 Open SilkPerformer. If you did not close the project you last worked on, SilkPerformer will open with that project. 2 Close any open projects.
122
In the Workflow bar, click Start here. The Workflow - Outline project dialog box opens.
4 5
In the Project name text box, enter Bank as the name for your loadtesting project. In the Project description text box, enter a short description for your project. This description is for your own project management purposes only. In the Application type list, select the CORBA (IIOP) option. Click OK. SilkPerformer creates a new load-testing project called Bank with the default settings profile and your local computer as the only agent.
6 7

Procedure To add a predefined script to your project: 1 In the SilkPerformer workflow bar, click the Model Script button.
123
In the Script area, select the Sample script option in order to open one of the scripts that accompany SilkPerformer and add it to your current project. Click OK. The Open dialog box opens. Navigate to the Working\Samples\CORBA\VisiBroker folder in your SilkPerformer installation and select the VBrokerBank01.bdf script. Click Open. A SilkPerformer Message dialog box opens. This dialog box asks you whether you want to add the test script to your load-testing project.
3 4 5
Click Yes to add the selected test script to your project. SilkPerformer adds the VBrokerBank01.bdf test script to the Scripts folder of your current project and displays the script in a new editor window.

In the VBrokerBank01 test script, the VB_Bank01 user group is set up. Virtual users in this group will create a new account, query the current balance of the account, and write the balance to the output file.
124
5 LOAD TESTING A CORBA APPLICATION Tutorial 1: Running a sample load test Executing the test script
Procedure To execute the VBrokerBank01 test script: 1 2 3 Make sure the VisiBroker Bank sample server is running before you start this procedure, otherwise the script will fail. In the Active Script window, expand the User Groups folder. In the User Groups folder, right-click VB_Bank01 and select Run User VB_Bank01. SilkPerformer runs a virtual user, performing all the actions defined in the test script. While the virtual user is being run, you can watch progress in the Monitor window, for example, the number of transactions executed, the response time of the last transaction, and the average response time. 4 Monitor the load test and wait until the virtual user has finished executing its tasks. a In the top part of the Monitor window, select an agent computer or a user group that you want to monitor. In the bottom part of the Monitor window, SilkPerformer displays overview information about all the virtual users running on the selected agent computer or belonging to the selected user group. b In the bottom part of the Monitor window, right-click a virtual user for which you want to view detailed information and select Show Output. SilkPerformer displays detailed run-time information about the selected user in the Virtual User window at the bottom, for example, the transactions and functions the user executes, and the data the user sends to and receives from the server. The type of information displayed depends on the options that you select at the top of the Monitor window. Display Errors. Select this button to display an appropriate error message indicating the probable reason whenever a virtual-userrelated error occurs. Display Transactions. Select this button to display a message when a user has finished executing a transaction; the message indicates whether the transaction was successful or not. Display Functions. Select this button to display a message for each function call a given user performs, including the function name and all its parameters. Display Info. Select this button to display messages containing additional information about the current action a given user performs.
5 LOAD TESTING A CORBA APPLICATION Tutorial 2: Creating a script with the Recorder
Display Data. Select this button to show data exchanged with the server. Display all Errors of all Users. Select this button to display error messages for all errors of all users. Each error message will indicate user, agent and probable cause of the error. This information will be displayed in addition to the information chosen for the selected user.

The SilkPerformer Recorder allows you to capture and record the IIOP traffic between the client CORBA object and the server objects. After you record traffic, you can save it as a test script. You can then easily customize the script and replay the script to simulate a large number of virtual users. Recording, customizing, and replaying a script will be covered separately in Tutorials 2, 3, and 4. In Tutorial 5, you will analyze the results of the load test you ran. This tutorial includes the following steps: Setting up an application profile Recording traffic between a client application and a server Generating a test script based on the recorded traffic Trying out the generated test script Validating the generated test script

Whenever you want the SilkPerformer Recorder to capture and record IIOP traffic that is exchanged between CORBA objects, you have to set up a profile for the client object. This profile specifies the type of the client and what type of traffic to record. If you are using VB for Java 3.X, you have to enter an additional application profile for the Java VM. (Application path will point to the local installation of the virtual machine).
5 LOAD TESTING A CORBA APPLICATION Tutorial 2: Creating a script with the Recorder Setting up an application profile
Procedure To set up a profile for the client: 1 2 From the menu bar, select Settings/System. The System Settings Workbench dialog box opens. In the shortcut list on the left side, click the Recorder icon. You see the following.
The list contains all the application profiles that are currently set up on your computer. 3 Click the Add button.
127
4 5 6 7 8 9
In the Application profile text box, enter a name for the application profile, for example, Bank. Click Browse and locate the executable, called VBJ.exe. This file is located in the BIN subfolder of the VisiBroker home directory. In the Working directory text box, enter the path of the sample you work with. In the Program arguments text box, enter Client. From the Application type list box, select the Custom Application option. In the API selection area, select the WinSock option.
10 Click Web Settings.... The Web Settings dialog box opens. 11 From the list box, select ws2_32.dll. Click OK. 12 Click OK. SilkPerformer adds the new application profile to the profile list in the System Settings Recorder dialog box. Since VBJ launches a Java Virtual Machine, you also have to enter an application profile for java.exe. 13 Click the Add button.
128
14 In the Application profile text box, enter JVM for the application profile, for example, JVM. 15 Click Browse and in the folder of the Java virtual Machine locate and select Java.exe. 16 From the Application type list box, select the Custom Application option. 17 In the API selection area, select the WinSock option. 18 Click Web Settings.... The Web Settings dialog box opens. 19 From the list box, select ws2_32.dll. Click OK. 20 Click OK. SilkPerformer adds the new application profile to the profile list in the System Settings Recorder dialog box. 21 Click OK to close the dialog box.

To load test the Bank application, the IIOP traffic between the client object and the server objects needs to be recorded and then described in a test script. The script finally enables any number of virtual users to perform actions similar to those that you performed during the recording session.
129
5 LOAD TESTING A CORBA APPLICATION Tutorial 2: Creating a script with the Recorder Modeling a test script
Procedure To model a load-testing script: 1 In the Project window, right-click Project Bank and select Add Data File. The Select Data File(s) dialog box opens. 2 3 From the Files of type list box, select CORBA IDL Files (*.idl). Browse to the Bank.idl file and click Add. SilkPerformer adds the Bank.idl file to your current project. The Recorder will require this file to interpret the traffic that is exchanged between the bank client and the server objects and to generate a highlevel test script that can easily be customized. 4 In the Workflow bar, click Model Script. The Workflow Model Script dialog box opens.
5 6 7 8
In the Script area, select the Record option. From the Select application profile list box, select Bank. Make sure the server is running! Enter the Command line parameter Client (Program argument in application profile). Click OK. SilkPerformer opens the Recorder and starts the Bank client application. The Recorder automatically records the IIOP traffic that the client application sends to and receives from the server objects.
To view the function calls that the Bank application performs, click the Change GUI Size button.
130
The SilkPerformer Recorder window displays as follows.
10 When the execution of the Bank client application is done, click the Stop Recording button in the Recorder. The Save As dialog box opens. 11 In the File name text box, enter Bank. 12 Click Save. SilkPerformer automatically adds the script to your current load-testing project. 13 You can now decide whether to close the Recorder. If you keep it open, you can examine the script that has been generated.
131
14 Close the Recorder.

Next you should do a trial run of the test script that was created. The object of the trial run is to ensure that the script is free from error, and that it will reproduce accurately the interaction between the client and the server objects.
Procedure To try out the generated test script: 1 In the Workflow bar, click Try Script. The Workflow Try Script dialog box opens.
2 3 4 5
From the Script list box, select the Bank.bdf script. Make sure the VUser group is selected in the Usergroup list. Disable the Animated option. Click Run. SilkPerformer runs a single virtual user, called VUser, which performs all the actions that you have performed during the previous recording session.
132
5 LOAD TESTING A CORBA APPLICATION Tutorial 3: Customizing the generated test script
While the single-user test is running, you can watch progress.
In Tutorial 2, you learned how to: Set up an application profile Record traffic between a client application and a server Generate a test script based on the recorded traffic Try out the generated test scripts

133
5 LOAD TESTING A CORBA APPLICATION Tutorial 3: Customizing the generated test script Replacing constant values
2 3
4 5
134
In the File area, select Efname from the Name list box. This random variable will draw from a SilkPerformer file containing first names and randomly select a name up to 15 characters in length.
dclrand rsEfname : RndFile("Efname.rnd", 15);
Repeat steps 2-6, but instead of Efname select Elname from the Name list box in the Random Variable Wizard. This random variable will draw from a SilkPerformer file containing last names and randomly select a name up to 15 characters in length. The dclrand section of the test script should now look like the following.
dclrand rsEfname : RndFile("Efname.rnd", 15); rsElname : RndFile("Elname.rnd", 12);
Locate the TMain transaction. You can do this by expanding the Transactions folder in the Active Script window and double-clicking TMain.
10 Within the TMain transaction, declare a local string variable called sName.
135
You do this by inserting the following variable declaration after the var keyword.
sName: string;
11 At the beginning of the transaction, insert the following code.

sName := rsEfname + " " + rsElname;
This will generate a random name, consisting of a first and a last name, separated by a blank. The beginning of the TMain transaction should now look like the following. The code shown in bold type is what you have inserted.
transaction TMain var sName: string; begin sName := rsEfname + " " + rsElname; IiopObjectCreate(ghIiop0, "", "1.0", "192.168.20.128", 1026, "\h01504D43000000001C00000049444C3A" "\h42616E6B2F4163636F756E744D616E61" "\h6765723A312E30000D00000042616E6B" "\h204D616E6167657200", 57);
12 Locate the section of the TMain transaction where a request for the open operation is sent. This code section looks similar to the following.
IiopSetString(ghIiop0, "Default Name"); // name IiopRequest(ghIiop0, "open");
13 Replace the name with the string variable sName. The BDL code should now look like the following.
IiopSetString(ghIiop0, sName); // name IiopRequest(ghIiop0, "open");

Procedure To specify which tasks each user will perform: 1 Navigate to the dcluser section of the Bank.bdf script file. You can do this by selecting User Groups/VUser in the Active Script window.
136
5 LOAD TESTING A CORBA APPLICATION Tutorial 4: Replaying the customized script
You see the following.

dcluser user VUser transactions TInit TMain
: begin; : 1;
In this section, a single user group is defined, called VUser. By default, this user group will perform the transactions that the Recorder created, TInit and TMain, once each. 2 Edit the dcluser section of the script so it looks like the following.
dcluser user Customer transactions TInit TMain
: begin; : 50;
In the edited version of the script, each user of the Customer group performs the TInit transaction at the beginning and then the TMain transaction 50 times. 3 4 5
Select File/Save from the menu bar to save your changes. In the Workflow toolbar, click the Customize Test button. The Workflow Customize Test dialog box opens. Click Yes to confirm that you are done customizing the test script.

137

After you have customized the load-testing script, you should ascertain the baseline performance that is, the basic, ideal performance of the server objects under test. The fully customized test script is run with just one user per user group, and the results from this unstressed performance from the server objects form the basis for comparison with the results of the full load test later.
Procedure To find the load test baseline: 1 In the Workflow toolbar, click the Find Baseline button. The Workflow Find Baseline dialog box opens.
This dialog box lists all the user groups you have set up in your test script. 2 Click Run. SilkPerformer runs one virtual user from each user group that you have declared in the test script. While the test is running, you can watch progress in the Monitor window.

After this test run, you have to confirm that the test baseline does actually reflect the desired performance by the application under test. This is done by inspecting the results from that test. If the results are satisfactory, the baseline established will form the basis for comparison with the results from the full load test later.
138
5 LOAD TESTING A CORBA APPLICATION Tutorial 4: Replaying the customized script Confirming the baseline
Procedure To confirm the load test baseline: 1 In the Workflow toolbar, click the Confirm Baseline button. The Workflow Confirm Baseline dialog box opens.
2 3 4 5 6
Click the Baseline Report button. The Baseline Report opens. Check the report carefully. In particular, make sure that no errors have occurred during your baseline test. Click the Accept Baseline button in the Baseline Report. Click Yes and OK by the Message boxes that comes up. If your baseline report indicates no errors, click Yes in the Workflow Confirm Baseline dialog box to confirm that you have found the baseline.
Setting up server monitoring for your load test

Monitoring the server under test helps you to find out whether there are bottlenecks on the server objects, and, if so, where exactly they are.
Procedure To set up server monitoring for your load test: 1 In the Workflow toolbar, once again click the Confirm Baseline button.
139
The Workflow Confirm Baseline dialog box opens.
Click the Monitoring template button. The Profile - [Profile1] - Results dialog box opens to the Monitoring tab. The option Automatically start monitoring is activated by default. It means, that when you run a load test, the Performance Explorer will open automatically using a default template that invokes a display of relevant client information.
Click Edit Customer Monitor Template, to customize the new template and change the display of information. You can close or maintain the default monitoring windows and you can add one or more windows to provide additional information.
140
To set up Performance Explorer to display additional information, proceed as follows. a Click the Monitor Server button in the Performance Explorer workflow bar The Data Source Wizard opens.
In the tree view, expand the folder that corresponds to the operating system on which the Bank server is running. Within the folder, select System.
141
d e
Click Next. In the next dialog box, enter connection parameters, like the host name or IP address of the server, the connection port, the user name, and the password. The data you have to enter here depends on the operating system that is running on the computer you are monitoring.
f g
Click Next when you are done entering connection parameters. In the next dialog box, select the performance counters you want to monitor. Of particular interest are the processor and memory utilization of the server being tested.
Click Finish. The Performance Explorer opens a new window and displays realtime data for the performance counters you have selected.
Later, when you are running the load test, the monitor view will look similar to the following.

142
5 LOAD TESTING A CORBA APPLICATION Tutorial 4: Replaying the customized script Adjusting the workload
Procedure To adjust the workload: 1 In the Workflow toolbar, click Adjust Workload. The Workflow - Select Workload Model dialog box opens.
This dialog box shows all possible workload models, which can be selected. 2 3 Select Queuing workload model. Click OK.
SilkPerformer now opens the Workload Configuration dialog box.

After you have adjust the workload, you run the full load test. The test script is run with multiple virtual users in order to test the Bank server. A large load test would need the appropriate testing environment to be set up in the local area network, including a full complement of agent computers to host the virtual users. For this tutorial, however, you use only your local computer.
Running the test
143
2 3 4 5
In the VUsers column, change the number of Customer users to 50. For the Customer user group, change the simulation time to 300 seconds (5 minutes). Disable all user groups that are declared in the VBrokerBank01 test script. Click Run. SilkPerformer runs a load test with 50 virtual users, load testing the server application. Performance Explorer opens automatically and you can watch progress and the server being tested in the Monitor window.
In Tutorial 4, you learned how to: Find the test baseline Confirm the test baseline Set up server monitoring for your load test Adjusting the workload Execute the load test
144
5 LOAD TESTING A CORBA APPLICATION Tutorial 5: Viewing the results of your load test

SilkPerformer incorporates Performance Explorer, a powerful graphing and analysis tool to help you work with your results information. Performance Explorer provides a comprehensive array of results information, which can be displayed using advanced features for creating statistical reports and displaying performance results in real time generated graphics. Results information may vary, depending on the type of application and/or server being tested. In general it falls into the following categories: Response time information: This is the total time to process a given timer; it provides application performance information from the point of view of the client. Throughput information: This is the rate at which a given timer is processed on average by the server; it allows you to analyze performance from the point of view of the server.

Procedure To explore overview report: 1 In the Workflow toolbar, click the Explore Results button. The Workflow - Explore Results dialog box opens.


When you analyze performance of an application from the client point of view, you examine the response times for all the transactions and individual timers. This will enable you to find out how users will experience their interaction with server objects. A common goal in load testing is to find out if response times for all transactions remain below a specified, critical limit.
Procedure To explore detailed response time measurements: 1 In the Performance Explorer Workflow bar, click the Select Graph button.
146
2 3
In the Templates list, select the Timer option. Click Finish. Performance Explorer opens a new chart with the number of active virtual users displayed.
You see the default graph with the average number of active users, and one or more default measurements (if any).
147
4 5 6
Expand the Explore tree view. In the Explore tree view, select IIOP/balance, drag the Round trip time measurement, and drop it on the graph. In the Explore tree view, select IIOP/open, drag the Round trip time measurement, and drop it on the graph. Your graph should now look like the following.
The load test that you ran in the previous tutorial lasted only a few minutes, so there are only a few measurements, which makes it difficult to draw any conclusions. In real-life you will run load tests that last several hours, a few days, or even a week. These tests will provide results information that will allow you analyze the performance of your server accurately.

When you analyze the performance of an application from the point of view of the server, you examine the throughput rate. Throughput is the work done by the server within a specific time interval, for example, the number of requests that the server objects process within a second, a minute, or an hour. A common goal in load testing is to ensure that the throughput rate is above a specified, critical limit.
148
5 LOAD TESTING A CORBA APPLICATION Tutorial 5: Viewing the results of your load test Throughput rate details
Procedure To explore throughput measurements: 1 2 3 4 5 From the menu bar, select File/New/Graph. The Performance Explorer opens a new, blank graph. In the Explore tree view, expand both the Summary General and the IIOP measurement groups. In the Summary General measurement group, drag the Active users measurement and drop it on the graph. In the IIOP measurement group, select balance/Server busy time, drag the Count measurement, and drop it on the graph. In the IIOP measurement group, select open/Server busy time, drag the Count measurement, and drop it on the graph. You see a graph that displays the number of operations performed by the server objects. The graph should look similar to the following.
149
5 LOAD TESTING A CORBA APPLICATION Tutorial 5: Viewing the results of your load test What you have learned
150
6
6e rh C t p a
Load Testing a TUXEDO Application

This chapter contains a series of tutorials that will help you to start load-testing TUXEDO applications with SilkPerformer. This chapter contains the following sections:
Section Page
151 152 156 164 170 178
Overview
Each of the following tutorials provides step-by-step instructions for important SilkPerformer tasks. You should perform the tutorials in order, since each tutorial builds on what you have learned in the previous ones. You will learn how to do the following: Execute a predefined load test on your local machine. Create a test script by recording function calls to the TUXEDO System using the Recorder. Customize the recorded test script.
151
6 LOAD TESTING A TUXEDO APPLICATION Tutorial 1: Running a sample load test

Sample: Bank application
These tutorials use a sample TUXEDO System application called bankapp. This application is included on your BEA TUXEDO System CD-ROM and should have been installed in the apps\bankapp subfolder of the TUXEDO System home directory as part of the installation and setup.

In this tutorial you will learn to create a load-testing project and execute sample scripts that are provided with SilkPerformer. You will run one of the sample scripts with a single virtual user on your local machine. You will use the test script bankappn.bdf, which is included in the Working\Samples\Middleware\TUXEDO folder in your SilkPerformer installation.

For each server you load test with SilkPerformer, you have to create a project file. A project file administers all the settings that are associated with a series of load tests, like the test type, the workload model, and a number of options that depend on the type of server being tested.
Creating a project
Procedure To create your load-testing project: 1 Open SilkPerformer. If you did not close the project you last worked on, SilkPerformer will open with that project. 2 3 Close any open projects. In the Workflow bar, click Start here.
152
The Workflow - Outline Project dialog box opens.
4 5
In the Project name text box, enter Bank as the name for your loadtesting project. In the Project description text box, enter a short description for your project. This description is for your own project management purposes only. In the Application type list, select Tuxedo. Click OK. SilkPerformer creates a new load-testing project called Bank with the default settings profile and your local computer as the only agent.
6 7

Procedure To add a predefined script to your project: 1 In the SilkPerformer workflow bar, click Model Script.
153
In the Script area, select the Sample script option in order to open one of the scripts that accompany SilkPerformer and add it to your current project. Click OK. The Open dialog box opens. Navigate to the Working\Samples\Middleware\TUXEDO folder in your SilkPerformer installation and select the bankappn.bdf script. Click Open. A SilkPerformer Message dialog box opens. This dialog box asks you whether you want to add the test script to your load-testing project.
3 4 5
Click Yes to add the selected test script to your project. SilkPerformer adds the bankappn.bdf test script to the Scripts folder of your current project and displays the script in a new editor window.

The bankappn script contains three constant declarations that specify the directory where the TUXEDO System client software is installed on the agent computer and the address of the Bank application server. Before you execute the script, you have to change the constant values with your personal settings.
Procedure To personalize the sample load-testing script: 1 In the Active Script window, select Symbols/Constants/TUXDIR.
154
You see the following code section.

const TUXDIR := "d:\\tuxedo"; // TUXEDO environment setting WSNADDR := "//lab5:3000"; // host/port where WSL listens FLDTBLDIR := "d:\\tuxedo\\apps\\allserv"; // location of field tables
2 3 4
Replace the directory d:\\tuxedo with the directory where the TUXEDO System client software is installed on your local computer. Replace the address //lab5:3000 with the address of the Bank application server. Replace the first part of the FLDTBLDIR constant (d:\\tuxedo) with the directory where the TUXEDO System client software is installed on your local computer. Select File/Save from the menu bar to save your changes.

In the bankappn test script, the TuxBankUsr user group is set up. Virtual users in this group will log on to the TUXEDO System, make inquiries about their bank account, deposit money into and withdraw money from the account, and log off from the TUXEDO System.
Procedure To execute the bankappn test script: 1 2 In the Active Script window, expand the User Groups folder. In the User Groups folder, right-click TuxBankUsr and select Run User TuxBankUsr. SilkPerformer runs a virtual user, performing all the actions defined in the test script. While the virtual user is being run, you can watch progress in the Monitor window, for example, the number of transactions executed, the response time of the last transaction, and the average response time. 3 Monitor the load test and wait until the virtual user has finished executing its tasks. a In the top part of the Monitor window, select an agent computer or a user group that you want to monitor. In the bottom part of the Monitor window, SilkPerformer displays overview information about all the virtual users running on the selected agent computer or belonging to the selected user group. b In the bottom part of the Monitor window, right-click a virtual user for which you want to view detailed information and select Show Output.
155
6 LOAD TESTING A TUXEDO APPLICATION Tutorial 2: Creating a script with the Recorder
SilkPerformer displays detailed run-time information about the selected user in the Virtual User window at the bottom, for example, the transactions and functions the user executes, and the data the user sends to and receives from the server. The type of information displayed depends on the options that you select at the top of the Monitor window. Display Errors. Select this button to display an appropriate error message indicating the probable reason whenever a user-related error occurs. Display Transactions. Select this button to display a message when a user has finished executing a transaction; the message indicates whether the transaction was successful or not. Display Functions. Select this button to display a message for each function call a given user performs, including the function name and all its parameters. Display Info. Select this button to display messages containing additional information about the current action a given user performs. Display Data. Select this button to show data exchanged with the server. Display all Errors of all Users. Select this button to display error messages for all errors of all users. Each error message will indicate user, agent and probable cause of the error. This information will be displayed in addition to the information chosen for the selected user.

The SilkPerformer Recorder allows you to capture function calls that a TUXEDO client application performs. After you record function calls, you can save them as a test script. You can then easily customize the script and replay the script to simulate a large number of virtual users. Recording, customizing, and
156
replaying a script will be covered separately in Tutorials 2, 3, and 4. In Tutorial 5, you will analyze the results of the load test you ran. This tutorial includes the following steps: Setting up an application profile Recording the function calls that the client application performs Generating a test script based on the recorded traffic Trying out the generated test script Validating the generated test script

Whenever you want the SilkPerformer Recorder to capture and record the function calls that a client application performs, you have to set up a profile for the client application. This profile specifies the type of the client application and what type of function calls to record.
Procedure To set up a profile for the client application: 1 2 From the menu bar, select Settings/System. The System Settings Workbench dialog box opens. In the shortcut list on the left side, click the Recorder icon. You see the following.
157
The list contains all the application profiles that are currently set up on your computer. 3 Click Add. The Application Profile dialog box opens.
4 5
In the Application profile text box, enter a name for the application profile, for example Bank. Click Browse and locate the executable, called bankappn.exe. This file is located in the apps\bankapp subfolder of the TUXEDO System home directory. From the Application type list box, select the Custom Application option. In the API selection area, select the Tuxedo option. Click OK. SilkPerformer adds the new application profile to the profile list in the System Settings Recorder dialog box.
6 7 8
Click OK to close the dialog box.

To load test the Bank server, the function calls that the client application performs need to be recorded and then described in a test script. The script
158
finally enables any number of virtual users to perform actions similar to those that you performed during the recording session. In order to create as realistic a load test as possible, you will record four separate transactions in a single recording session: Logging on to the Bank server Opening a new account Querying the balance of an existing account Logging off from the Bank server
When you run the load test, you will create two user groups to which you will assign each of these tasks in a ratio that simulates real-world behavior.
2 3 4
In the Script area, select the Record option. From the Select application profile list box, select Bank. Click OK.
159
SilkPerformer opens the Recorder and starts the Bank client application.
As you connect to the Bank server, the Recorder automatically records the function calls that the client application performs. 5 To view your actions as well as the function calls that the Bank application performs, click the Change GUI Size button. The SilkPerformer Recorder window displays as follows.
In the Recorder, click the New Transaction button to insert a new transaction into the test script you are generating. The following dialog box opens.
Create a new transaction called TOpen; then click OK. A distinct set of time measurements will be made for each transaction you create. When recording traffic, you should create a new transaction for each distinct user session, from connection to shutdown.
160
In the Bank application, open a new account. Enter the necessary information as shown in the following dialog box; then click OK.
In the Recorder, create a new transaction called TQuery.
10 In the Bank application, make an inquiry about an existing account. 11 Close the Bank application. 12 In the Recorder, click the Stop Recording button. The Save As dialog box opens. 13 In the File name text box, enter Bank. 14 Click Save. 15 You can now decide whether to close the Recorder.
161
16 Close the Recorder. SilkPerformer automatically adds the script to your current load-testing project.

Next you should do a trial run of the test script that was created. The object of the trial run is to ensure that the script is free from error, and that it will reproduce accurately the interaction between the client application and the Bank server.
162
2 3 4 5
From the Script list box, select the Bank.bdf script. Make sure the VUser group is selected in the Usergroup list. Disable the Animated option. Click Run.
163
6 LOAD TESTING A TUXEDO APPLICATION Tutorial 3: Customizing the generated test script
SilkPerformer runs a single virtual user, called VUser, which performs all the actions that you have performed during the previous recording session. While the single-user test is running, you can watch the progress.
In Tutorial 2, you learned how to: Set up an application profile Record traffic between a client application and a server Generate a test script based on the recorded traffic Try out the generated test scripts

Customizing the test script you have generated allows you to take the actions performed by a single user and create from them a realistic simulation of multiple users. Two key tasks can help you create a real-world simulation: Replacing constant values with random variables Specifying which tasks each virtual user will perform Note You must use Benchmark Description Language (BDL), SilkPerformers high-level scripting language, to customize generated test scripts. Although knowledge of BDL is not required
164
for this tutorial, it might be helpful to browse the introductory BDL Reference topics in the SilkPerformer Online Help for more information about BDL before you begin.

Procedure To replace constant values with random variables: 1 In the Workflow bar, click Customize Test. The Workflow Customize Test dialog box opens.
Click the Create New Parameter Wizard button. The Parameter Wizard - Create New Parameter dialog box opens.
165
4 5
From the Random type list box, select the String from file type. Click Next. The following dialog box opens.
In the File area, select Efname from the Name list box.
166
This random variable will draw from a SilkPerformer file containing first names and randomly select a name up to 15 characters in length. 7 Click Finish. SilkPerformer inserts the following lines into your test script.
dclrand rsEfname : RndFile("Efname.rnd", 15);
Repeat steps 1-6, but instead of Efname select Elname from the Name list box in the Random Variable Wizard. This random variable will draw from a SilkPerformer file containing last names and randomly select a name up to 15 characters in length. The dclrand section of the test script should now look like the following.
dclrand rsEfname : RndFile("Efname.rnd", 15); rsElname : RndFile("Elname.rnd", 15);
Locate the TOpen transaction. You can do this by expanding the Transactions folder in the Active Script window and double-clicking TOpen.
10 Within the TOpen transaction, locate the section where the parameters for the OPEN_ACCT service call are copied into a typed buffer. The section looks similar to the following.
Tux_tpbegin(30, 0); TuxGetBuffer(hBuffer0, "FML", NULL, 1024); TuxSetInt(hBuffer0, ID_8296, 1); TuxSetInt(hBuffer0, ID_16496, ord('C')); TuxSetInt(hBuffer0, ID_16499, ord('R')); TuxSetString(hBuffer0, ID_41068, "212-555-0293"); TuxSetString(hBuffer0, ID_41069, "First Avenue New York, NY 10010"); TuxSetString(hBuffer0, ID_41071, "345-23-1092"); TuxSetString(hBuffer0, ID_41073, "Walters"); TuxSetString(hBuffer0, ID_41074, "Jimmy"); TuxSetString(hBuffer0, ID_41162, "1000.00"); Tux_tpcall("OPEN_ACCT", hBuffer0, 0, hBuffer0, olen, TPNOFLAGS);
11 Replace the first name that you have entered during the recording session with the rsEfname random variable. 12 Replace the last name that you have entered during the recording session with the rsElname random variable. 13 Immediately before the Tux_tpcall function call, insert the following function call.
MeasureStart("Open Account");
This will start a time measurement for the TUXEDO service call. 14 Immediately after the Tux_tpcall function call, insert the following function call.
MeasureStop("Open Account");
167
This will stop the time measurement for the TUXEDO service call. The section should now look like the following. The code shown in bold type is what you have changed.
Tux_tpbegin(30, 0); TuxGetBuffer(hBuffer0, "FML", NULL, 1024); TuxSetInt(hBuffer0, ID_8296, 1); TuxSetInt(hBuffer0, ID_16496, ord('C')); TuxSetInt(hBuffer0, ID_16499, ord('R')); TuxSetString(hBuffer0, ID_41068, "212-555-0293"); TuxSetString(hBuffer0, ID_41069, "First Avenue New York, NY 10010"); TuxSetString(hBuffer0, ID_41071, "345-23-1092"); TuxSetString(hBuffer0, ID_41073, rsElname); TuxSetString(hBuffer0, ID_41074, rsEfname); TuxSetString(hBuffer0, ID_41162, "1000.00"); MeasureStart("Open Account"); Tux_tpcall("OPEN_ACCT", hBuffer0, 0, hBuffer0, olen, TPNOFLAGS); MeasureStop("Open Account");
15 Locate the TQuery transaction. You can do this by expanding the Transactions folder in the Active Script window and double-clicking TQuery. 16 In this transaction, immediately before the Tux_tpcall function call, insert the following function call.
MeasureStart("Query Balance");
This will start a time measurement for the TUXEDO service call. 17 Immediately after the Tux_tpcall function call, insert the following function call.
MeasureStop("Open Account");
This will stop the time measurement for the TUXEDO service call. The section should now look like the following.
Tux_tpbegin(30, 0); TuxGetBuffer(hBuffer0, "FML", NULL, 4096); TuxSetInt(hBuffer0, ID_8302, 10023); MeasureStart("Query Balance"); Tux_tpcall("INQUIRY", hBuffer0, 0, hBuffer0, olen, TPNOFLAGS); MeasureStop("Query Balance"); //TuxGetInt(hBuffer0, ID_8302); // 10023 //TuxGetString(hBuffer0, ID_40966, ostring, sizeof(ostring)); //TuxGetString(hBuffer0, ID_41161, ostring, sizeof(ostring)); Tux_tpcommit(0);

168
6 LOAD TESTING A TUXEDO APPLICATION Tutorial 3: Customizing the generated test script Assigning tasks to users
Procedure To specify which tasks each user will perform: 1 Navigate to the dcluser section of the Bank.bdf script file. You can do this by selecting User Groups/VUser in the Active Script window. You see the following.
dcluser user VUser transactions TInit TOpen TQuery TShutdown
: : : :
begin; 1; 1; end;
In this section, a single user group is defined, called VUser. By default, this user group will perform the transactions you created, TInit, TOpen, TQuery, and TShutdown, once each. 2 Edit the dcluser section of the script so it looks like the following.
dcluser user Creator transactions TInit TOpen TShutdown
169
6 LOAD TESTING A TUXEDO APPLICATION Tutorial 4: Replaying the customized script

user Querist transactions TInit TQuery TShutdown
In the edited version of the script, each user of the Creator group performs the TInit transaction at the beginning, the TOpen transaction three times, and the TShutdown transaction at the end. Each user of the Querist group performs the TInit transaction at the beginning, the TQuery transaction five times, and the TShutdown transaction at the end. 3 4 5

After you have created a test script by recording function calls that the client application performs and then customizing the script, you can load test your server by replaying the script. To run a load test, you must perform the following steps: Find the test baseline Confirm the test baseline Set up server monitoring for your load test Execute the load test

After you have customized the load-testing script, you should ascertain the baseline performance that is, the basic, ideal performance of the server under test. The fully customized test script is run with just one user per user group, and the results from this unstressed performance from the application form the basis for comparison with the results of the full load test later.
Procedure To find the load test baseline: 1 In the Workflow toolbar, click the Find Baseline button.
170
The Workflow Find Baseline dialog box opens.
This dialog box lists all the user groups you have set up in your test script. 2 Click Run. SilkPerformer runs one virtual user from each user group that you have declared in the test script. While the test is running, you can watch progress in the Monitor window.

Confirming the baseline
Procedure To confirm the load test baseline: 1 In the Workflow toolbar, click the Confirm Baseline button.
171
2 3 4 5 6
Click the Baseline Report button. The Baseline Report opens. Check the report carefully. In particular, make sure that no errors have occurred during your baseline test. Click Accept Baseline button in the Baseline Report. Click Yes and OK by the Message boxes that comes up. If your baseline report indicates no errors, click Yes in the Workflow Confirm Baseline dialog box to confirm that you have found the baseline.

Monitoring the server under test helps you to find out whether there are bottlenecks on the server, and, if so, where exactly they are.
Procedure To set up server monitoring for your load test: 1 In the Workflow toolbar, once again click the Confirm Baseline button.
172
Click the Monitoring template button. The Profile - [Profile1] - Results dialog box opens on the Monitoring tab. The option Automatically start monitoring is activated by default. It means, that when you run a load test, the Performance Explorer will open automatically using a default template that invokes a display of relevant client information.
Click Edit Customer Monitor Template, to customize the new template and change the display of information. You can close or maintain the default monitoring windows and you can add one or more windows to provide additional information. To set up Performance Explorer to display additional information, proceed as follows: a Click the Monitor Server button in the Performance Explorer workflow bar
173
The Data Source Wizard opens.
In the tree view, expand the folder that corresponds to the operating system on which the Bank server is running. Within the folder, select System. Click Next. In the next dialog box, enter connection parameters, like the host name or IP address of the server, the connection port, the user name, and the password.
d e
174
f g h i j
The data you have to enter here depends on the operating system that is running on the computer you are monitoring. Click Next when you are done entering connection parameters. In the next dialog box, select the performance counters you want to monitor. Of particular interest are the processor and memory utilization of the server being tested. Click Finish. The Performance Explorer opens a new window and displays realtime data for the performance counters you have selected.

Procedure To adjust the workload: 1 In the Workflow toolbar, click the Adjust Workload button.
175
This dialog box shows all possible workload models, which can be selected. 2 3 Select Queuing workload model. Click OK. SilkPerformer now opens the Workload Configuration dialog box.

After you have adjust the workload, you run the full load test. The test script is run with multiple virtual users in order to test the Bank server. A large load test would need the appropriate testing environment to be set up in the local area network, including a full complement of agent computers to host the virtual users. For this tutorial, however, you use only your local computer.
Running the test
176
2 3 4 5
In the VUsers column, change the number of Creator and Querist users to 25. For each of these user groups, change the simulation time to 300 seconds (5 minutes). Disable all user groups that are declared in the Bankappn test script. Click Run. SilkPerformer runs a load test with 50 virtual users, load testing the Bank server. Performance Explorer opens automatically and you can watch progress of the load test and the server being tested in the Monitor window.
In Tutorial 4, you learned how to: Find the test baseline Confirm the test baseline Set up server monitoring for your load test Adjusting the workload Execute the load test
177
6 LOAD TESTING A TUXEDO APPLICATION Tutorial 5: Viewing the results of your load test

SilkPerformer incorporates Performance Explorer, a powerful graphing and analysis tool to help you work with your results information. Performance Explorer provides a comprehensive array of results information, which can be displayed using advanced features for creating statistical reports and displaying performance results in real time generated graphics. Results information may vary, depending on the type of application and/or server being tested. In general it falls into the following categories: Response time information: This is the total time to process a given timer; it provides application performance information from the point of view of the client computer. Throughput information: This is the rate at which a given timer is processed on average by the server; it allows you to analyze performance from the point of view of the server.

Procedure To explore overview report: 1 In the Workflow toolbar, click Explore Results. The Workflow - Explore Results dialog box opens.
2

179
2 3
In the Templates area, select the Timer option. Click Finish. The Performance Explorer displays a chart that looks similar to the following.
180

When you analyze the performance of a server from the point of view of the server, you examine the throughput rate. Throughput is the work done by the server within a specific time interval, for example, the number of requests that the server processes within a second, a minute, or an hour. A common goal in load testing is to ensure that the throughput rate is above a specified, critical limit.
Procedure To explore throughput measurements: 1 2 3 4 5 From the menu bar, select File/New/Graph. The Performance Explorer opens a new, blank graph. In the Explore tree view, expand both the Summary General and the Timers measurement groups. In the Summary General measurement group, drag the Active users measurement and drop it on the graph. In the Timers measurement group, select Open Account/Response time, drag the Count measurement, and drop it on the graph. In the Timers measurement group, select Query Balance/Response time, drag the Count measurement, and drop it on the graph. You see a graph that displays the number of service calls processed by the Bank server.
181
The graph should look similar to the following.
182
7
7e rh C t p a
Load Testing a Jolt Application

This chapter contains a series of tutorials that will help you to start load-testing Jolt applications with SilkPerformer. This chapter contains the following sections:
Section Page
183 184 189 198 203 210
Overview
Each of the following tutorials provides step-by-step instructions for important SilkPerformer tasks. You should perform the tutorials in order, since each tutorial builds on what you have learned in the previous ones. You will learn how to do the following: Execute a predefined load test on your local machine. Create a test script by recording Jolt function calls using the Recorder. Customize the recorded test script.
183
7 LOAD TESTING A JOLT APPLICATION Tutorial 1: Running a sample load test

Sample: Bank applet
In these tutorials, you will use the sample BEA Jolt Bank applet; this applet is included on the BEA Jolt CD-ROM. Make sure your network configuration fulfills the following requirements: The BEA TUXEDO System server software is installed and running on a computer in your local area network. The BEA Jolt server software is installed and running on the computer as the TUXEDO System; this computer must also run a Web server to enable the applet to be accessed. The BEA Jolt client software is installed on your SilkPerformer controller computer. Any version of the Sun Java Development Kit (JDK) is installed on your SilkPerformer controller computer.

The following tutorial shows you how to create load-testing projects and execute sample scripts that accompany SilkPerformer. You will run one of the sample scripts on your local machine, for a single virtual user. For now, just to keep everything simple, you will work with a sample script provided by SilkPerformer. This is the test script JoltBankApp.bdf, which is included in the Working\Samples\Middleware\Jolt folder in your SilkPerformer installation.

For each application you load test with SilkPerformer, you have to create a project file. A project file administers all the settings that are associated with a series of load tests, like the test type, the workload model, and a number of options that depend on the type of application being tested. In addition, project files enable you to easily switch between different load-testing projects without having to define any new settings when you switch to a different project.
Creating a project
Procedure To create your load-testing project: 1 Open SilkPerformer. If you did not close the project you last worked on, SilkPerformer will open with that project. 2 Close any open projects.
184
In the Workflow bar, click Start here. The Workflow Outline Project dialog box opens.
4 5
In the Project name text box, enter Bank of BEA as the name for your load-testing project. In the Project description text box, enter a short description of your project. This description is for your own project management purposes only. In the Application type list box, select the Jolt option. Click OK. SilkPerformer creates a new load-testing project called Bank of Bea with the default settings profile and your local computer as the only agent.
6 7

Procedure To add a predefined script to your project: 1 In the SilkPerformer workflow bar, click the Model Script button.
185
In the Script area, select the Sample script option in order to open one of the scripts that accompany SilkPerformer and add it to your current project. Click OK. The Open dialog box opens. Navigate to the Working\Sample\Middleware\Jolt folder in your SilkPerformer installation and select the JoltBankApp script. Click Open. A SilkPerformer Message dialog box opens. This dialog box asks you if you want to add the test script to your load-testing project.
3 4 5
In this dialog box, click Yes to add the selected test script to your project. SilkPerformer adds the JoltBankApp test script to the Scripts folder of your current project and displays the script in a new editor window.

The JoltBankApp script contains a number of constant declarations that specify the Java home directory, the Java classpath, and the server to which the virtual users connect. Before you execute the script, you have to change the constant values so that they correspond to your configuration.
Procedure To personalize the sample load-testing script: 1 In the Active Script window, select Symbols/Constants/HOST.
186
You see the following.

HOST := "//lab5:8000"; // TUXEDO host name
2 3 4
Replace the address lab5 with the name of the server where the TUXEDO System server software is running. If necessary, change the port number (8,000) to the number of the port that the server listens to. In the Active Script window, select Symbols/Constants/ JOLTCLASSPATH. You see the following.
JOLTCLASSPATH:="c:/jolt/lib/jolt11.zip"; // path of the Jolt package
5 6 7
Replace the directory name c:/jolt/lib with the name of the directory where the Jolt classes are located on your computer. In the Active Script window, select Symbols/Transactions/TInit. In the TInit transaction, locate the following two lines.
JavaSetOption(JAVA_VERSION, JAVA_V12); // JVM 1.2.x JavaSetOption(JAVA_HOME, "c:/jdk1.2"); // contains folders: bin/, lib/
If any version of the Java Development Kit 1.1 is installed on your computer, replace the second parameter of the first function call with the JAVA_V11 constant. The function call would then look like the following.
JavaSetOption(JAVA_VERSION, JAVA_V11); // JVM 1.2.x
In the second function call, replace the directory c:/jdk1.2 with the name of the directory where the Java Development Kit is installed on your computer.
10 Select File/Save from the menu bar to save your changes.

In the JoltBankAPP test script, the JoltUser user group is set up. Virtual users in this group will create a new account, query the current balance of the account, deposit some money in the account, and withdraw some money from the account.
Procedure To execute the JoltBankApp test script: 1 2 In the Active Script window, expand the User Groups folder. In the User Groups folder, right-click JoltUser and select Run User JoltUser.
187
SilkPerformer runs a virtual user, performing all the actions defined in the test script. While the virtual user is being run, you can watch progress in the Monitor window, for example, the number of transactions executed, the response time of the last transaction, and the average response time. 3 Monitor the load test and wait until the virtual user has finished executing its tasks. a In the top part of the Monitor window, select an agent computer or a user group that you want to monitor. In the bottom part of the Monitor window, SilkPerformer displays overview information about all the virtual users running on the selected agent computer or belonging to the selected user group. b In the bottom part of the Monitor window, right-click a virtual user for which you want to view detailed information and select Show Output. SilkPerformer displays detailed run-time information about the selected user in the Virtual User window at the bottom, for example, the transactions and functions the user executes, and the data the user sends to and receives from the server. The type of information displayed depends on the options that you select at the top of the Monitor window. Display Errors. Select this button to display an appropriate error message indicating the probable reason whenever a user-related error occurs. Display Transactions. Select this button to display a message when a user has finished executing a transaction; the message indicates whether the transaction was successful or not. Display Functions. Select this button to display a message for each function call a given user performs, including the function name and all its parameters. Display Info. Select this button to display messages containing additional information about the current action a given user performs. Display Data. Select this button to show data exchanged with the server. Display all Errors of all Users. Select this button to display error messages for all errors of all users. Each error message will indicate user, agent and probable cause of the error.
188
7 LOAD TESTING A JOLT APPLICATION Tutorial 2: Creating a script with the Recorder
This information will be displayed in addition to the information chosen for the selected user.

The SilkPerformer Recorder allows you to capture and record the Jolt traffic between the client and the server. After you record traffic, you can save it as a test script. You can then easily customize the script and replay the script to simulate a large number of virtual users. Recording, customizing, and replaying a script will be covered separately in Tutorials 2, 3, and 4. In Tutorial 5, you will analyze the results of the load test you ran. This tutorial includes the following steps: Specifying Java-specific options Setting up an application profile Recording traffic between a client and a server Generating a test script based on the recorded traffic Trying out the generated test script Validating the generated test script
Specifying Java-specific load-testing options

Before you can capture and record Jolt traffic, you need to tell the Recorder where the Java Development Kit and the Jolt classes are located on your computer.
Specifying Java options
Procedure To point to the Java Development Kit: 1 2 3 In the Project window, expand the Profiles folder. Right-click the Profile1 profile and select Edit Profile. The Profile [Profile1] Simulation dialog box opens. In the shortcut list on the left side, select the Replay category and click the Java icon.
189
You see the General tab of the Profile [Profile1] Java dialog box.
4 5 6
From the Version list box, select the version number of the Java Development Kit that is installed on your computer. In the Java home text box, specify the directory where the Java Development Kit is installed on your computer. In the Classpath field, specify the archives that contain the basic Java SilkPerformer framework classes (javaUserFramework.zip) and the Jolt classes (jolt.zip). Click the File and Dir buttons to add files and directories to the field, respectively. The javaUserFramework.zip file is located in the ClassFiles subfolder of the SilkPerformer home directory. Note Make sure that JoltMessageBundle.properties is also added to the classpath. If this properties file is not available in the jolt.zip file, try the jolt.jar file.
Click OK.

Whenever you want the SilkPerformer Recorder to capture and record Jolt traffic that is exchanged between the client and the server, you have to set up a profile for the client. This profile specifies the type of the client and what type of traffic to record. In this tutorial, you will use a Web browser to access the BEA Bank applet. SilkPerformer automatically sets up profiles for Microsoft Internet Explorer and
Netscape Communicator (if they are installed on your computer). To record Jolt traffic, however, you have to modify the application profiles that are set up by default.
Modifying the application profile
Procedure To modify the profile for the Web browser: 1 2 From the menu bar, select Settings/System. The System Settings Workbench dialog box opens. In the shortcut list on the left side, click the Recorder icon. You see the following.
Select the application profile that corresponds to the Web browser you want to use for recording Jolt traffic. For example, if you want to use Microsoft Internet Explorer, select Internet Explorer. Click Edit.
191
5 6 7
In the Java API area, select the API you want. Click OK. In the System Settings - Recorder dialog box, click the Proxies tab. You see the following.
192
Select the protocol type SOCKS and click Edit. The Proxy Settings dialog box opens.
In the Suppress recording (only forward data) area, in the Within port range edit field, specify the port range on which the Jolt lisener is running. This must be specified that only the Jolt functions are recorded, and not also the TCP/IP functions.
10 Click OK. 11 In the System Settings Recorder dialog box, click OK to close the dialog.

To load test the Jolt Bank applet, the Jolt traffic between the client and the server needs to be recorded and then described in a test script. The script finally enables any number of virtual users to perform actions similar to those that you performed during the recording session.
Procedure To model a load-testing script: 1 In the Workflow bar, click Model Script.
193
2 3 4 5
In the Script area, select the Record option. From the Select application profile list box, select the profile that corresponds to the Web browser you want to use for recording traffic. In the command line text box, specify the URL of the BEA Bank applet. Click OK. SilkPerformer opens the Recorder and starts the Web browser. The Recorder automatically records the Jolt traffic that the client sends to and receives from the server.
To view your actions as well as the requests sent to the server and the responses received, click the Change GUI Size button.
Click the New Transaction button to insert a new transaction into the test script you are generating.
194
Create a new transaction called TInquiry; then click OK. A distinct set of time measurements will be made for each transaction you create. When recording traffic, you should create a new transaction for each piece of work that has no dependencies on others. In your Web browser, enter your PIN (for example, 100, 120, or 121). You do this by clicking the digits on the number pad and clicking OK when you are done.
10 To the right of the number pad, click Inquiry and then Checking Acct. 11 In the Recorder, create a new transaction called TDeposit. 12 In your Web browser, again enter your PIN (for example, 100, 120, or 121). 13 To the right of the number pad, click Deposit and then Checking Acct. 14 Using the number pad, enter the amount of money you want to deposit in the account, for example, $100. Then click OK. 15 In the Recorder, click the Stop Recording button. The Save As dialog box opens. 16 In the File name text box, enter Bank of BEA. 17 Click Save. SilkPerformer automatically adds the script to your current load-testing project. 18 You can now decide whether to close the Recorder.
195
19 Close the Recorder.

Next you should do a trial run of the test script that was created. The object of the trial run is to ensure that the script is free from error, and that it will reproduce accurately the interaction between the client and the server.
Procedure To try out the generated test script: 1 In the Workflow bar, click Try Script.
196
The Workflow - Try Script dialog box opens.
2 3 4 5
From the Script list box, select the Bank of BEA.bdf script. Make sure the VUser group is selected in the Usergroup list. Disable the Animated option. Click Run.
197
7 LOAD TESTING A JOLT APPLICATION Tutorial 3: Customizing the generated test script
SilkPerformer runs a single virtual user, called VUser, which performs all the actions that you have performed during the previous recording session. While the single-user test is running, you can watch progress in the Monitor window.
In Tutorial 2, you learned how to: Set up an application profile Record traffic between a client application and a server Generate a test script based on the recorded traffic Try out the generated test script

198
The Workflow Customize Test dialog box opens.
2 3
Click the Create New Parameter Wizard button. The Parameter Wizard - Create New Parameter dialog box opens. Select Parameter from Random Variable and click Next. The Parameter Wizard - Random Variable dialog box opens. The Random Variable Wizard opens.
4 5
From the Random type list box, select the RndUniN type. Click Next.
199
You see the following dialog box.
In the Name text box, enter rnAmount. This is the name for the random variable that will be inserted into your test script.
7 8 9
In the Upper boundary edit field, enter 500. In the Lower boundary edit field, enter 100. Click Finish. SilkPerformer inserts the following lines into your test script.
dclrand rnAmount : RndUniN(100..500);
10 Repeat the steps 1-8, but in the first dialog box, instead of selecting the RndUniN option, select RndInd. in the second dialog box, enter rnAccount in the Name edit field, select the Number option in the Parameter type area, and enter the following pairs in the Parameter list.
Value Weight
10001 10002
50 50
200
The dclrand section of the test script should now look like the following.
dclrand rnAccount : RndInd(10001 = 0.500000; 10002 = 0.500000); rnAmount : RndUniN(100..500);
11 Locate the TInquiry transaction. You can do this by expanding the Transactions folder in the Active Script window and double-clicking TInquiry. 12 In the TInquiry transaction, locate the following function call.
JoltSetInt(svcInquiryObject0, "ACCOUNT_ID", 10001);
13 Replace the constant (10,001) with the random variable rnAccount. The function should now look like the following. The code shown in bold type is what you have changed.
JoltSetInt(svcInquiryObject0, "ACCOUNT_ID", rnAccount);
14 Locate the TDeposit transaction. You can do this by expanding the Transactions folder in the Active Script window and double-clicking TDeposit. You see the following.
transaction TDeposit var begin JoltSetInt(svcDepositObject0, "ACCOUNT_ID", 10001); JoltSetString(svcDepositObject0, "SAMOUNT", 100);
15 In the first function call, again replace the constant (10,001) with the random variable rnAccount. 16 In the second function call, replace the constant (100) with the expression string(rnAmount). The beginning of the TDeposit transaction should now look like the following. The code shown in bold type is what you have changed.
transaction TDeposit var begin JoltSetInt(svcDepositObject0, "ACCOUNT_ID", rnAccount); JoltSetString(svcDepositObject0, "SAMOUNT", string(rnAmount));

201
7 LOAD TESTING A JOLT APPLICATION Tutorial 3: Customizing the generated test script Assigning tasks to users
Procedure To specify which tasks each user will perform: 1 Navigate to the dcluser section of the Bank.bdf script file. You can do this by selecting User Groups/VUser in the Active Script window. You see the following.
dcluser user VUser transactions TInit TMain TInquiry TDeposit
: : : :
begin; 1; 1; 1;
In this section, a single user group is defined, called VUser. By default, this user group will perform the transactions that you created, Tinit, TMain, TInquiry, and TDeposit once each. 2 Edit the dcluser section of the script so it looks like the following.
dcluser user Inquirer transactions TInit TMain TInquiry user Depositor transactions TInit TMain TDeposit
: begin; : 1; : 3;
: begin; : 1; : 2;
In the edited version of the script, each user of the Inquirer group performs the TInit transaction at the beginning and then the TMain transaction once and the TInquiry transaction three times. Each user of the Depositor group performs the TInit transaction at the beginning and then the TMain transaction once and the TDeposit transaction twice. 3 4 5
202
7 LOAD TESTING A JOLT APPLICATION Tutorial 4: Replaying the customized script


After you have customized the load-testing script, you should ascertain the baseline performance that is, the basic, ideal performance of the server objects under test. The fully customized test script is run with just one user per user group, and the results from this unstressed performance from the server objects form the basis for comparison with the results of the full load test later.
This dialog box lists all the user groups you have set up in your test script. 2 Click Run.
203
SilkPerformer runs one virtual user from each user group that you have declared in the test script. While the test is running, you can watch progress in the Monitor window.

2 3 4 5 6
Click the Baseline Report button. The Baseline Report opens. Check the report carefully. In particular, make sure that no errors have occurred during your baseline test. Click Accept Baseline button in the Baseline Report. Click Yes and OK by the Message boxes that come up. If your baseline report indicates no errors, click Yes in the Workflow Confirm Baseline dialog box to confirm that you have found the baseline.
204

Monitoring the server under test helps you to find out whether there are bottlenecks on the server objects, and, if so, where exactly they are.
Procedure To set up server monitoring for your load test: 1 In the Workflow toolbar, once again click the Confirm Baseline button. The Workflow Confirm Baseline dialog box opens.
Click the Monitoring template button. The Profile - [Profile1] - Results dialog box opens on the Monitoring tab. The option Automatically start monitoring is activated by default. It means, that when you run a load test, the Performance Explorer will open automatically using a default template that invokes a display of relevant client information.
If you want to customize monitoring, enable the Use custom monitoring template, and click the Create Customer Monitor Template button. The Performance Explorer will create and open a template with the name of your project, which is equal to the default template.
Click Edit Customer Monitor Template, to customize the new template and change the display of information. You can close or maintain the default monitoring windows and you can add one or more windows to provide additional information. To set up Performance Explorer to display additional information, proceed as follows:
Click the Monitor Server button in the Performance Explorer workflow bar. The Data Source Wizard opens.
In the tree view, expand the folder that corresponds to the operating system on which the Bank server is running. Within the folder, select System. Click Next.
206
In the next dialog box, enter connection parameters, like the host name or IP address of the server, the connection port, the user name, and the password. The data you have to enter here depends on the operating system that is running on the computer you are monitoring.
f g
Click Next when you are done entering connection parameters. In the next dialog box, select the performance counters you want to monitor. Of particular interest are the processor and memory utilization of the server being tested.
Click Finish. The Performance Explorer opens a new window and displays realtime data for the performance counters you have selected.

207
This dialog box shows all possible workload models, which can be selected. 2 3 Select Queuing workload model. Click OK.
SilkPerformer now opens the Workload Configuration dialog box.

After you have adjust the workload, you run the full load test. The test script is run with multiple virtual users in order to test the BEA Bank applet. A large load test would need the appropriate testing environment to be set up in the local area network, including a full complement of agent computers to host the virtual users. For this tutorial, however, you use only your local computer.
Running the test
Procedure To run the load test: 1 The Workload Configuration dialogbox is open.
208
2 3 4 5
In the VUsers column, change the number of Depositor and Inquirer users to 50. For the Depositor and Inquirer user groups, change the simulation time to 300 seconds (5 minutes). Disable all user groups that are declared in the JoltBankApp test script. Click Run. SilkPerformer runs a load test with 100 virtual users, load testing the Bank applet. While the test is running, you can watch progress in the Monitor window and monitor the server being tested in the Performance Explorer.
In Tutorial 4, you learned how to: Find the test baseline Confirm the test baseline Set up server monitoring for your load test# Adjusting the workload Execute the load test
209
7 LOAD TESTING A JOLT APPLICATION Tutorial 5: Viewing the results of your load test

SilkPerformer incorporates Performance Explorer, a powerful graphing and analysis tool to help you work with your results information. Performance Explorer provides a comprehensive array of results information, which can be displayed using advanced features for creating statistical reports and displaying performance results in real time generated graphics. Results information may vary, depending on the type of application and/or server being tested. In general it falls into the following categories: Response time information: This is the total time to process a given timer; it provides application performance information from the point of view of the client. Throughput information: This is the rate at which a given timer is processed on average by the server; it allows you to analyze performance from the point of view of the server.

2

211
2 3
In the Templates area, select the Timer option. Click Finish. The Performance Explorer opens a new chart with the number of active virtual users and the response time for the Jolt service calls displayed.
212
The load test that you ran in the previous tutorial lasted only a few minutes, so there are only a few measurements, which makes it difficult to draw any conclusions. In real-life you will run load tests that last several hours, a few days, or even a week. These tests will provide results information that will allow you to analyze the performance of your server accurately.

When you analyze the performance of an application from the point of view of the server, you examine the throughput rate. Throughput is the work done by the server within a specific time interval, for example, the number of requests that the server objects process within a second, a minute, or an hour. A common goal in load testing is to ensure that the throughput rate is above a specified, critical limit.
Procedure To explore throughput measurements: 1 2 3 4 5 From the menu bar, select File/New/Graph. The Performance Explorer opens a new, blank graph. In the Explore tree view, expand both the Summary General and the Timer measurement groups. In the Summary General measurement group, drag the Active users measurement on to the graph. In the Timer measurement group, select CALL:DEPOSIT/Response time, drag the Count measurement, and drop it on the graph. In the Timer measurement group, select CALL:INQUIRY/Response time, drag the Count measurement, and drop it on the graph. You see a graph that displays the number of services performed by the server.
213
The graph should look similar to the following.
214
8
8e rh C t p a
Load Testing a COM Application

This chapter contains a series of tutorials that will help you to start load-testing COM applications with SilkPerformer. This chapter contains the following sections:
Section Page
Overview Setting up the sample COM Person application Tutorial 1: Running a sample load test Tutorial 2: Creating a script with the Recorder Tutorial 3: Customizing the generated test script Tutorial 4: Replaying the customized script Tutorial 5: Viewing the results of your load test
215 216 216 220 228 232 240
Overview
Each of the following tutorials provides step-by-step instructions for important SilkPerformer tasks. You should perform these tutorials in order, since each tutorial builds on what you have learned in the previous ones. You will learn how to do the following: Execute a predefined load test on your local machine. Create a test script by recording COM traffic using the Recorder. Customize the recorded test script.
215
8 LOAD TESTING A COM APPLICATION Tutorial 1: Running a sample load test

Sample: Person application
Run the customized script, using multiple virtual users. Use reporting tools to view selected throughput and response time information.
These tutorials use the sample COM Person application. This application is included in the SilkPerformer CD-ROM and is normally installed during installation and setup. You can find it in the SampleApps\COM\ subfolder of the SilkPerformer home directory.
Setting up the sample COM Person application

Before you can begin testing the COM sample, you need to register the COM server. The sample COM Person application has a built-in registration process, so the effort to register it is minimal. Procedure To set up the sample COM Person application: 1 2 From the SilkPerformer start menu, navigate to and select \Sample Applications\COM Samples\PersonCOMServer. The Person Server application dialog box opens. By having started this application, the COM server has been automatically registered. You can close the Person Server dialog box if you wish. You can now continue with the tutorials.
If you wish to get familiar with the sample COM Person application, you can navigate to and select <SilkPerformer menu>\Sample Applications\COM Samples\PersonCOMClient. This will start the Person Client application, where you need to select the menu Server / Connect before you can begin using the application (use the suggested default connection values).

In this tutorial, you will learn to create a load-testing project and execute a sample script that is provided with SilkPerformer. You will use the test script PersonCOM_01.bdf, which is included in the Working\Samples\COM subfolder of the SilkPerformer home directory.

You have to create a project file for every COM application you plan to load test with SilkPerformer. In this project file you administer all the settings associated with one or a series of load tests. These settings include the test type, for
216
example stress test or stability test, the workload model, for example increasing workload or steady-state workload, and a number of options, which depend on the type of COM server you are testing. The first step in preparing your load test is to set up the basic outlines of your project - give it a name, add a short description, and choose the kind of application you want to test.
Creating a project
Procedure To create a load-testing project for a COM application: 1 Open SilkPerformer. If you did not close the project you last worked on, SilkPerformer will open with that project. 2 3 Close any open projects. In the Workflow bar, click Start here. The Workflow Outline Project dialog box opens.
4 5
In the Project name text box, enter PersonCOM as the name for your load-testing project. In the Project description text box, enter a short description of your project. This description only serves your own project management purposes. In the Application type list, select the COM option. Click OK. SilkPerformer will create a new load-testing project called PersonCOM with the default settings profile and your local computer as the only agent.
6 7
217
Adding a load-testing script to your project

To run a load test, you need to have a test script. Therefore, each project must contain at least one load-testing script. Each script defines one or more different groups of virtual users and the actions they will perform during the test. In this tutorial you will use a Sample script that is provided with SilkPerformer. Before you can run a test script, you need to add it to your project.
Procedure To add a predefined script to your project: 1 On the SilkPerformer workflow bar, click Model Script. The Workflow - Model Script dialog box opens.
2 3 4 5
In the Script area, select Sample script. Click OK. The Open dialog box opens. Navigate to the Working\Samples\COM folder in your SilkPerformer installation and select the sample script PersonCOM_01.bdf. Click Open. A SilkPerformer Message dialog asks you if you want to add the test script to your load-testing project.
Click Yes to add the selected test script to your project. SilkPerformer will add the test script to the Scripts folder of your current project and will display it in a new editor window.
218

In the PersonCOM_01 test script, the HRInsChng user group is defined. Each of the virtual users in this group will create 5 new person entries with default values, and subsequently change height, weight, salary, and date of birth of those persons to a randomly selected value.
Procedure To execute the PersonCOM_01 test script: 1 2 On the SilkPerformer workflow bar, click Try Script. Click Run. SilkPerformer runs a virtual user performing all actions defined in the test script. While the virtual user is being run, you can watch it progress in the Monitor window. You will see for example, the number of transactions executed, the response time of the last transaction, and the average response time. 3 Monitor the load test. a In the top part of the Monitor window, select an agent computer or a user group that you want to monitor. In the bottom part of the Monitor window, SilkPerformer will display overview information of all virtual users running on the selected agent computer or belonging to the selected user group. b In the Virtual User window, SilkPerformer will display detailed runtime information of the selected user. Which type of information is displayed depends on the options you have selected at the top of the Monitor window, for example, the transactions and functions the user executes, and the data the user sends to and receives from the server. Display Errors. Select this button to display an error message indicating the probable cause, each time a user-related error occurs for the selected user. Display Transactions. Select this button to display a message when the user has finished executing a transaction; the message will indicate whether the transaction was successful or not. Display Functions. Select this button to display a message containing function name and all parameters for each function call the selected user performs. Display Info. Select this button to display messages containing additional information about the current action a selected user performs.
219
8 LOAD TESTING A COM APPLICATION Tutorial 2: Creating a script with the Recorder
Display Data. Select this button to show which data the selected user exchanges with the server. Display all Errors of all Users. Select this button to display error messages for all errors of all users. Each error message will indicate user, agent and probable cause of the error. This information will be displayed in addition to the information chosen for the selected user.
In Tutorial 1, you learned how to: Create a load-testing project Add a predefined script to the project Execute the script with one virtual user View progress information on the load test

SilkPerformer Recorder allows you to capture and record traffic between COM clients and COM server objects. You can save this recorded traffic as a test script. You can then easily customize this test script to simulate any number of virtual users and replay it. Recording, customizing, and replaying a test script will be covered separately in Tutorials 2, 3, and 4. In Tutorial 5, you will learn to analyze the results of the load test you ran. This tutorial includes the following steps: Setting up an application profile Recording traffic between a client and a server application Generating a test script based on recorded traffic Trying out the generated test script Validating the generated test script

Whenever you want SilkPerformer Recorder to capture and record traffic between COM clients and COM server objects, you have to set up an application profile for the client. This profile specifies the client type and the type of traffic you want to record.
Procedure To set up an application profile for the client: 1 From the menu bar, select Settings/System.
220
The System Settings Workbench dialog box opens. 2 In the shortcut list on the left side, click the Recorder icon. You see the following.
The list contains all application profiles that are currently set up on your computer. 3 Click Add. The Application Profile dialog box opens.
221
4 5
In the Application profile text box, enter a name for the application profile, for example, PersonCOMClient. Click Browse and locate the executable, called PersonCOMClient.exe. This file is located in the SampleApps\COM subfolder of the SilkPerformer home directory. From the Application type list box, select the Custom Application option. In the API selection area, select the COM option. Click the Interfaces button and click on Add in the Server Interfaces Window. Select the application PersonCOMServer in the SampleApps\COM directory of the SilkPerformer home directory. The Server Interfaces dialog box opens.
6 7 8 9
10 Click Open.
11 Make sure the Class filter option is selected. 12 Click OK twice to close two windows.
222
SilkPerformer will add the new application profile to the profile list in the System Settings Recorder dialog box.

To load test the Person application, COM traffic between the COM Client and the COM Server needs to be recorded and described in a test script. This script can then be modified to simulate any number of virtual users to perform actions similar to those performed by the real user during the recorded session.
Procedure To model a load-testing script: 1 To check the actual settings for recording COM traffic, from the menu bar select Settings/Active Profile. The Profile - [Profile1] - COM dialog box opens.
223
In the shortcut list on the left side, select the Record category and click the COM icon. You see the following.
3 4 5
In the Filter area, make sure both the Remote out-of-process server and the Local out-of-process server are selected. Click OK. In the Workflow bar, click Model Script. The Workflow Model Script dialog box opens.
6
In the Script area, select the Record option.
7 8
From the Select application profile list box, select PersonCOMClient. Click OK. SilkPerformer opens the Recorder and starts the PersonCOMClient application. The Recorder automatically records COM traffic that the client application sends to and receives from the server.
From the menu bar in the PersonCOMClient window, select Server/ Connect.
10 Type in the name of the computer on which your COM Server is running (localhost). Click OK. The Person Server window opens displaying the transaction log and error output. 11 Click New in the Person Client window and enter a new name, for example, Donald.
225
Click OK.
12 To view the function calls the Person application performs, click the Change GUI Size button. The SilkPerformer Recorder window then looks as follows.
13 Stop the Person Client by closing the window, then click the Stop Recording button in the Recorder. The Save As dialog box opens. 14 In the File name text box, enter PersonCOM. 15 Click Save.
226
SilkPerformer automatically adds the script to your current load-testing project. 16 You can now decide whether to close the Recorder (dont close it). 17 From the menu bar in the PersonCOMClient window, select Server/ Disconnect and close the application. 18 Close the Recorder.

Next, you should do a trial run of the test script you have created. The object of the trial run is to ensure that the script is free from errors, and accurately reproduces interactions between client and server objects.
Procedure To try out the generated test script: 1 In the Workflow bar, click Try Script. The Workflow Try Script dialog box opens.
2 3 4
From the Script list box, select the PersonCOM.bdf script. Make sure the VUser group is selected in the Usergroup list. Click Run. SilkPerformer runs a single virtual user, called VUser, which performs all actions that were registered during the previous recording session.
227
8 LOAD TESTING A COM APPLICATION Tutorial 3: Customizing the generated test script
While the single-user test is running, you can watch its progression.
In Tutorial 2, you learned how to: Set up an application profile Record traffic between a client application and a server Generate a test script based on the recorded traffic Try out the generated test script

If you use your test script as it now is, your load test will only repeatedly reproduce the exact behavior recorded on one particular occasion. This kind of repetition will not produce realistic COM traffic and therefore it will not provide very accurate results. To realistically emulate the varied traffic of a large number of different users, your virtual users need to be as different as real users are.
228
8 LOAD TESTING A COM APPLICATION Tutorial 3: Customizing the generated test script Replacing constant values
2 3
4 5
229
In the File area, select Elname from the Name list box. This random variable will draw from a SilkPerformer file containing last names and randomly select a name up to 12 characters in length.
dclrand rsElname : RndFile("Elname.rnd", 12);
Locate the TMain transaction. You can do this by expanding the Transactions folder in the Active Script window and double-clicking TMain.
Within the TMain transaction, declare a local string variable called sName. You do this by inserting the following variable declaration after the var keyword.
sLastname: string;
10 At the beginning of the transaction, insert the following code.

sLastname := rsElname;
This will generate a random name, consisting of a last name. The beginning of the TMain transaction should now look as follows.
230
transaction TMain var sLastname: string; begin sLastname := rsElname;
The code shown in bold type is what you should have inserted. 11 Locate the section of the TMain transaction where the COM function AddPerson is performed. This code section looks as follows.
ComFunction(hFunc0, hIFace2, "AddPerson"); ComSetString(hFunc0, "sName", "Donald");
12 Replace the name Donald with the string variable sLastname. The BDL code should now look like:
ComFunction(hFunc0, hIFace2, "AddPerson"); ComSetString(hFunc0, "sName", sLastname);
13 Locate the section of the TMain transaction where the COM function GetPerson is performed. This code section looks as follows.
ComFunction(hFunc0, hIFace2, "GetPerson"); ComSetString(hFunc0, "sName", "Donald");
14 Replace the name Donald with the string variable sLastname. The BDL code should now look like:
ComFunction(hFunc0, hIFace2, "GetPerson"); ComSetString(hFunc0, "sName", sLastname);
15 When you have finished making changes to the script file, select File/ Save from the menu bar to save your changes.

Usually a load test simulates a number of different types of users. In the test script, you have to specify which actions each type of virtual user will perform.
Procedure To specify which tasks each user will perform: 1 Navigate to the dcluser section at the beginning of the PersonCOM.bdf script file. You can do this by selecting User Groups/VUser in the Active Script window. You see the following.
dcluser user VUser transactions TInit TMain
: begin; : 1;
231
8 LOAD TESTING A COM APPLICATION Tutorial 4: Replaying the customized script
In this section, a single user group is defined, called VUser. By default, this user group will perform transactions TInit and TMain, which the Recorder registered once each. 2 Edit the dcluser section of the script so that it looks like the following.
dcluser user HRInsert transactions TInit TMain
: begin; : 5;
In the edited version of the script, each user of the HRInsert group performs the TInit transaction at the beginning and then the TMain transaction 5 times. 3 4 5
Select File/Save from the menu bar to save your changes. In the Workflow toolbar, click Customize Test. The Workflow Customize Test dialog box opens. Click Yes to confirm that you finished customizing the test script.

After you have created a test script by recording traffic and then customizing the recorded script, you can load test your server by replaying the script. To run this load test, you must perform the following steps: Find the test baseline Confirm the test baseline Set up server monitoring for your load test Execute the load test

After you have customized the load-testing script, you need to determine baseline performance. This is the ideal performance of your application when it is not under real pressure. To obtain this test baseline, the fully customized script is run with just one user per user group. This will provide you with a solid basis for comparison with the situation when the application is fully taxed by a load test
232
8 LOAD TESTING A COM APPLICATION Tutorial 4: Replaying the customized script Finding the baseline
This dialog box lists all the user groups you have set up in your test script. 2 3 Select the user types for which you would like to run a baseline test. Click Run. SilkPerformer runs one virtual user from each user group that you have selected. While the test is running, you can watch it progress in the Monitor window.

After running the baseline test, you have to confirm the test result reflects the desired performance of the tested server. For this you inspect the results of the test. If they are satisfactory, the baseline is established and will form the basis for comparison with results from full load tests later.
Procedure To confirm the load test baseline: 1 In the Workflow toolbar, click the Confirm Baseline button.
233
2 3 4 5 6
Click the Baseline Report button. The Baseline Report opens. Check the report carefully. In particular, make sure that no errors have occurred during your baseline test. Click Accept Baseline button in the Baseline Report. Click Yes and OK by the Message boxes that comes up. If your baseline report indicates no errors, click Yes in the Workflow Confirm Baseline dialog box to confirm that you have found the baseline.

234
This dialog box shows all possible workload models, which can be selected. 2 3 4 Select Steady State workload model. Click OK. SilkPerformer now opens the Workload Configuration dialog box.

After you have adjust the workload, you are ready to run the full load test. The test script is run with multiple virtual users in order to test the targeted server. A large load test will need an appropriate testing environment, set up in the local area network and including a full complement of agent computers to host the virtual users. For this tutorial, only your local computer will be used.
Running the test
235
2 3
In the VUsers column, change the number of HRInsert users to 5. For the HRInsert user group, change the simulation time to 60 seconds.
You are now ready to run the load test. When you run a test SilkPerformers sophisticated monitoring tool Performance Explorer will automatically generate a live graphical display of a default set of test data for the server you are testing. You can disable this default option by deselecting the setting Automatically start monitoring. You can also change the default monitoring settings by pressing the Active profile button (See Customizing server monitoring). Once monitoring is set up the way you want it, you can continue and run the test. 4 Click Run to start the test now, or Click OK to save the settings and start the test later. When you start the test, SilkPerformer tests the Person application with 5 virtual users. If the (default) option Automatically start monitoring is enabled, Performance Explorer will open and generate a live graphical display of the specified set of test data. If you wish you can adapt the views by adding or deleting specific measurements. For this you can expand the tree menu on the left and drag and drop selected measurements into existing or new view graphs.
236

An important feature SilkPerformer provides, is server monitoring during an actual load test. Server monitoring will help you locate and analyze bottlenecks on the server. You can separately examine the performance of the operating system, the network and the server application, which in this case is the Web server. Server monitoring is performed with Performance Explorer, a powerful tool SilkPerformer incorporates. When you run a test, the default procedure is that Performance Explorer automatically opens a set of views containing a live graphical display of a selection of test data that is particularly significant for the server you are testing. You can disable this default option by deselecting the setting Automatically start monitoring in the Workload Configuration [.......] dialog. You can also customize the default monitoring settings and select a particular set of data sources.
Procedure To customize server monitoring for your load test: 1 2 In the Workflow toolbar, click Run Test. The Workload Configuration dialog box opens. In the Settings section, click the Active Profile button. The Profile Results dialog box opens.
3 4
In the shortcut list on the left side, select the Replay category and click the Results icon. Select the Monitoring tab.
237
The option Automatically start monitoring is activated by default. It means, that when you run a load test, the Performance Explorer will open automatically using a default template that invokes a display of relevant client information. 5 If you want to customize monitoring, enable the Use custom monitoring template, and click the Create Customer Monitor Template button. Performance Explorer will create and open a template with the name of your project, which is equal to the default template. 6 Click Edit Customer Monitor Template, to customize the new template and change the display of information. You can close or maintain the default monitoring windows and you can add one or more windows to provide additional information. To set up Performance Explorer to display additional information, proceed as follows: a From the menu bar select Monitor/Add Data Source. The Data Source Wizard opens.
238
In the tree view, expand the folder that corresponds to the operating system on which the Person COM server is running. Within that folder, select System. Click Next. In the Connection Parameters dialog box, enter connection parameters, like the host name or IP address of the server, the connection port, the user name, and the password. The data you have to enter here depends on the operating system that is running on the computer you are monitoring.
d e
f g
Click Next when you have entered the connection parameters. In the next dialog box, select the performance counters you want to monitor. Of particular interest are processor and memory utilization of the server being tested.
Click Finish. Performance Explorer will open a new window, displaying real-time data for the performance counters you have selected.
239
8 LOAD TESTING A COM APPLICATION Tutorial 5: Viewing the results of your load test
In Tutorial 4, you learned how to: Find the test baseline Confirm the test baseline Customizing server monitoring for your load test Adjusting the workload Execute the load test

SilkPerformer incorporates Performance Explorer, a powerful graphing and analysis tool to help you work with your results information. Performance Explorer provides a comprehensive array of results information, which can be displayed using advanced features for creating statistical reports and displaying performance results in real time generated graphics. Results information may vary, depending on the type of application and/or server being tested. In general it falls into the following categories: Response time information: This is the total time it takes to process a given timer; it provides application performance information from the point of view of the client.
240
Throughput information: This is the average rate at which a given timer is processed by the server; it allows you to analyze performance from the point of view of the server.

241

242
2 3
In the Templates area, select the Timer option. Click Finish. The Performance Explorer opens a new chart that contains a graph of the active users.
You see the default graph with the average number of active users, and one or more default measurements (if any). 4 5 Expand the Explore tree view. In the Explore tree view, select Transactions/TMain.
243
Drag the TMain measurement on to the new view. You see a chart similar to the following.
In Tutorial 5 you learned how to: Explore response time measurements
244
9
9e rh C t p a
Load Testing an ADO Application

This chapter contains a series of tutorials that will help you load test ADO applications using SilkPerformer. This chapter contains the following sections:
Section Page
Overview Tutorial 1: Setting up an application profile Tutorial 2: Creating a sample database Tutorial 3: Creating a script with the Recorder Tutorial 4: Customizing a generated test script Tutorial 5: Replaying a customized script Tutorial 6: Viewing the results of a load test
245 246 250 252 258 260 268
Overview
Each of the following tutorials provides step-by-step instruction for important SilkPerformer tasks. You should perform these tutorials in order as each tutorial builds on what was covered in the preceding tutorials. You will learn how to: Execute a predefined load test on your local machine Create a test script by recording ADO (COM) traffic using the Recorder
245
9 LOAD TESTING AN ADO APPLICATION Tutorial 1: Setting up an application profile
Customize the recorded test script Run the customized script, using multiple virtual users Use reporting tools to view selected throughput and response time information
ADO (Active Data Objects) are special COM objects that allow client applications to access any type of database with a common set of interfaces. As ADO is a COM Library, you can also review the tutorials that describe the testing of COM applications to gain an overview of basic COM load testing.
Sample: Person application
These tutorials use the sample COM Person application. This application is included on the SilkPerformer CD-ROM and is installed during installation and setup. You can find it in the SampleApps\COM\ subfolder of the SilkPerformer home directory.
Tutorial 1: Setting up an application profile

In this tutorial, you will learn how to create a load-testing project based on a SilkPerformer SilkEssential and configure an application profile for the sample application to record ADO traffic. This SilkEssential is used because it provides a BDL script that creates/populates a sample database that the sample application can access.
Creating a load-testing project based on a SilkEssential

You must create a project file for each COM application you plan to load test with SilkPerformer. In a project file you administer all the settings associated with one or a series of load tests. These settings include the test type (for example, stress test or stability test), the workload model (for example, increasing workload or steady-state workload), and a number of options that vary based on the type of COM server you are testing. The first step in preparing your load test is to set up the basic outlines of your projectgive it a name, a short description, and select the type of application you wish to test.
Creating a project
Procedure To create a load-testing project for a COM application: 1 2 Open SilkPerformer. Close any open projects. If you did not close the project you last worked on, SilkPerformer will open with that project.
246
Click Start here on the Workflow bar. The Workflow - Outline Project dialog box opens.
4 5 6 7
In the Project name text box, enter PersonADO as the name of the load-testing project. In the Project description text box, enter a short description of your project. This description assists with project management tasks. In the Application type list, select the Samples\ADO Sample option. Click OK.
SilkPerformer creates a new load-testing project called PersonADO with preconfigured profile and workload settings. The ODBCLoadComPerson.bdf script is added to the project.

When you want SilkPerformers Recorder to capture and record traffic between ADO clients and databases, you must set up an application profile for the client. This profile specifies the client type and the type of traffic you wish to record.
Procedure To set up an application profile for the client: 1 From the menu bar, select Settings/System. The System Settings - Workbench dialog box opens.
247
The list contains all application profiles that are currently set up on your computer. 3 4 Click Add. The Application Profile dialog box opens. In the Application profile text box, enter a name for the application profile, for example, PersonCOMClient.
248
Click Browse and locate the executable called PersonCOMClient.exe. This file is located in the SampleApps\COM subfolder of the SilkPerformer home directory. From the Application type list box, select the Custom Application option. In the API selection area, select the COM option. Click the Interfaces button and click Add in the Server Interfaces Window. Select msadoxx.tlb, which is normally located in the following folder: C:\Program Files\Common Files\System\ADO. Select the msadoxx.tlb with the highest number. This file is selected because this type library defines all the interface information that the recorder needs to do ADO recording. The Server Interfaces dialog box opens.
6 7 8 9
10 Click Open.
11 Make sure the Class filter option is selected.
249
9 LOAD TESTING AN ADO APPLICATION Tutorial 2: Creating a sample database
12 Click OK twice to close two windows.
SilkPerformer adds the new application profile to the profile list in the System Settings - Recorder dialog box. 13 Click OK to close the dialog box.
Tutorial 2: Creating a sample database

In this tutorial, you will learn how to use the script that is provided by the SilkEssential to create the sample database and populate it with demonstration data. If you have a Microsoft Access OLEDB driver installed on your machine you can skip this tutorial and use the sample database that comes with PersonCOMClient.
Executing the Database Script

ODBCLoadComPerson.bdf is a SilkPerformer ODBC script that connects to a database, creates sample tables and populates them with demonstration data. To connect to a database via ODBC you must provide an empty database and configure an ODBC DSN to that database on your local machine.
Setting up the project attributes
The script connects to the DSN using a username and password that are defined in the project attributes. To set the correct values for the required project attributes: 1 Select Project/Project Attributes from the menu bar.
250
9 LOAD TESTING AN ADO APPLICATION Tutorial 2: Creating a sample database
The Project Attributes Configuration dialog box opens. 2 3 Enter the name of your configured DSN in the Value of the DSN attribute If you need special user credentials enter Username and Password for the username and password attributes.
Click OK.
Running the ODBC script
The script offers three user groups: Creator, Loader and Dropper. First we will execute the Creator user group to create the tables in the database, then we will use the Loader user group to populate the tables with demonstration data. If you dont need the tables in the database you can execute the Dropper user group to delete them. 1 To run a user group, select Try Script from the workflow bar. The Workflow - Try Script dialog box opens. 2 3 Select the Creator user group and click Run. If there are any errors during the TryScript run, verify that you have correctly setup the ODBC DSN and set the correct DSN name and user credentials in the project attributes To populate the tables with demonstration data, select Try Script from the workflow bar. The Workflow - Try Script dialog box opens. 5 Select the Loader user group and click Run.
251
9 LOAD TESTING AN ADO APPLICATION Tutorial 3: Creating a script with the Recorder

As we already setup the application profile in Tutorial 1 we can now begin directly recording a script.

To load test the Person application, ADO traffic between the ADO Client and the database must be recorded and described in a test script. The script can then be modified to simulate any number of virtual users performing actions similar to those performed by the real user during the recorded session.
Procedure To model a load-testing script: 1 To check the actual settings for recording COM/ADO traffic, from the menu bar select Settings/Active Profile. The Profile - [ADOProfile1] - COM dialog box opens. 2 In the shortcut list on the left, select the Record category and click the COM/ADO icon.
There are different recording options available. For a detailed description refer to the online documentation. For the purposes of this tutorial you can accept the default settings.
252
4 5
Click OK. Click Model Script on the Workflow bar. The Workflow - Model Script dialog box opens.
6 7
In the Script area, click the Record option button. If you wish to have detailed information about the SilkEssential that is the basis of the current project, you can double-click the ProjectInfo.html entry in the list control. A browser then opens, offering a detailed description of the SilkEssential. Click OK. SilkPerformer opens the Recorder. Select the PersonCOMClient application profile from the list box and press Play.
253
The Recorder launches the application and automatically records ADO traffic that the client application sends to and receives from the database.
From the menu bar in the PersonCOMClient window, select Server/ Connect.
10 Click the database option button and select the ADO connection string that connects to your sample database. If you will be using the sample Microsoft Access database that comes with SilkPerformer you must select the first entry (Provider=Microsoft.Jet.OLEDB.4.0;Data Source={install}\persons.mdb). If you will be connecting to an ODBC database you must select the second entry (Provider=MSDASQL.1;Data Source=COMPerson) and modify the DSN name to the name of the configured ODBC DSN that links to your sample database. If you are using an ODBC connection, not all client functionality can be used because of an improper implementation of the ODBC data provider. If you are connecting to a database running Microsoft SQL Server you must use the third entry
254
(Provider=SQLOLEDB.1;User ID=sa;Initial Catalog=tempdb;Data Source=(local)using your database server name, database name and user credentials.
Click OK. 11 In the Search text box enter a % symbol and click GO. A list of all persons in the database is displayed and the details of the first person are displayed in the Person Details section.
12 12 Click New in the Person Client window and enter a new name, for example Donald.
255
Click OK.
13 From the menu bar in the PersonCOMClient window, select Server/ Disconnect and close the application. 14 Click the Stop Recording button on the Recorder. The Save As dialog box opens. 15 In the File name text box enter PersonADO. 16 Click Save. SilkPerformer automatically adds the script to your current load-testing project. 17 Close the Recorder.

Now do a trial run of the test script you have created. The object of the trial run is to ensure that the script is error free, and accurately reproduces interactions between client and server objects. Before you can try out the script you must delete the created person from the database, because the application doesn't allow you to create two people with the same name. If you ran a test now a second person with the name Donald would be created.
256
9 LOAD TESTING AN ADO APPLICATION Tutorial 3: Creating a script with the Recorder Removing the created person
Procedure To remove the created person: 1 2 3 4 5 Start the sample application from the SampleApps\Com directory. Connect to the database as you did during recording. Search for the person (Donald) or search for all persons using %. Select Donald and click Delete. Disconnect from the database and close the application.
Procedure To try out the generated test script: 1 On the Workflow bar, click Try Script. The Workflow - Try Script dialog box opens.
2 3 4
From the Script list box, select the PersonADO.bdf script. Make sure the VUser group is selected in the Usergroup list. Click Run.
SilkPerformer runs a single virtual user, called VUser, which performs all actions that were registered during the previous recording session. You can watch the single-user test run as it progresses.
257
9 LOAD TESTING AN ADO APPLICATION Tutorial 4: Customizing a generated test script
What you learned In Tutorial 3
Recording traffic between a client application and a database Generating a test script based on recorded traffic Trying out a generated test script

To realistically emulate the varied traffic of a large number of real-world users, your virtual users need to have as varied characteristics as real users do. If you use your test script as it now is, your load test will reproduce the same recorded behavior with each transaction. Such repetition wont produce realistic COM traffic and therefore wont provide accurate results.
Customizing in the TrueLog

The replay TrueLog of your last test run can be used to view the database queries that were executed. The TrueLog can also be used to customize those queries by changing input parameters and adding verifications.
To customize in the TrueLog
Open the replay TrueLog of the last test run.
258
9 LOAD TESTING AN ADO APPLICATION Tutorial 4: Customizing a generated test script
Look over the nodes in the TrueLog to acquaint yourself with them. There are nodes for executing a command, fetching results and updating/ adding recordsets. Select the node that adds the new user. Right-click the input value and select Customize Value to open the Parameter Wizard.
259
9 LOAD TESTING AN ADO APPLICATION Tutorial 5: Replaying a customized script
4 5 6 7 8
Select Create new parameter on the first dialog box of the wizard. Select Parameter from Random Variable on the second dialog box of the wizard. Select Strings from file as the random type and click Next. In the list box of filenames select Efname to get random variables with first names. Click Finish. The script is now customized to take a random first name for the Add New command.

Once you have created a test script (by recording traffic) and then customized the recorded script, you can load test your server by replaying the script. To run the load test, you must perform the following steps: Find the test baseline Confirm the test baseline Set up server monitoring for your load test Execute the load test
260

Once you have customized the load-testing script, you need to determine baseline performance, which is the ideal performance of your application when it is not under stress. To obtain a test baseline, the fully customized script must be run with only one user per user group. This will provide you with a solid basis for comparison when the application is fully taxed by a load test.
Procedure To find the load test baseline: 1 Click the Find Baseline button on the Workflow toolbar. The Workflow Find Baseline dialog box opens.
This dialog box lists the user groups you have set up in your test script. 2 3 Select the user types for which you would like to run a baseline test. Click Run. SilkPerformer runs one virtual user from each user group that you have selected. While the test runs, you can watch its progress in the Monitor window.

After running the baseline test, you must confirm that the test results reflect the desired performance of the tested server. For this you must inspect the results of the test. If they are satisfactory, the baseline has been established. The baseline will later form the basis for comparison with results from your load tests.
261
9 LOAD TESTING AN ADO APPLICATION Tutorial 5: Replaying a customized script Confirming the baseline
Procedure To confirm the load test baseline: 1 Click the Confirm Baseline button on the Workflow toolbar. The Workflow Confirm Baseline dialog box opens.
2 3 4 5 6
Click the Baseline Report button. The Baseline Report opens. Check the report carefully. In particular, make sure that no errors occurred during the baseline test. Click the Accept Baseline button on the Baseline Report. Click Yes and OK on the subsequent dialog boxes. If your baseline report indicates no errors, click Yes on the Workflow Confirm Baseline dialog box to confirm that you have identified the baseline.

Once you have confirmed your baseline, you can select your workload model and prepare the workload to run a full load test.
262
This dialog box shows all possible workload models that can be selected. 2 3 4 Select Steady State workload model. Click OK. SilkPerformer now opens the Workload Configuration dialog box.

Once you have adjusted the workload, youre ready to run the full load test. The test script is run with multiple virtual users to test the targeted server. For this tutorial, only your local computer is required. A true load test however requires an appropriate testing environment (set up on the local area network) that offers a full complement of agent computers to host virtual users.
263
9 LOAD TESTING AN ADO APPLICATION Tutorial 5: Replaying a customized script Running the test
2 3
In the VUsers column, change the number of HRInsert users to 5. For the HRInsert user group, set the simulation time to 60 seconds.
You are now ready to run the load test. When you run a test SilkPerformers sophisticated monitoring tool, Performance Explorer, automatically generates a live graphical display with a default set of test data for the server you are testing. You can disable this default option by deselecting the setting Automatically start monitoring. You can also change the default monitoring settings by pressing the Active profile button (See Customizing server monitoring). Once monitoring has been set up as required, you can run the test. 4 Click Run to start the test now, or Click OK to save the settings and begin the test later. When you start the test, SilkPerformer tests the Person application with 5 virtual users. If the default option Automatically start monitoring is enabled, Performance Explorer will open and generate a live graphical display of the specified test data. You can adapt these views by adding and deleting specific measurements. To do this, expand the tree menu on the left and drag and drop selected measurements into existing or new view graphs.
264

An important feature provided by SilkPerformer is server monitoring during actual load tests. Server monitoring helps you locate and analyze bottlenecks on servers. You can separately examine the performance of the operating system, the network and the server application (which in this case is the Web server). Server monitoring is performed using Performance Explorer, a powerful tool incorporated into SilkPerformer. When you run a test, the default procedure has Performance Explorer automatically open a set of views containing a live graphical display of a selection of test data that is relevant to the server under test. You can disable this default option by deselecting the Automatically start monitoring setting in the Workload Configuration dialog. You can also customize the default monitoring settings and select a particular set of data sources.
Procedure To customize server monitoring for your load test: 1 2 On the Workflow toolbar, click Run Test. The Workload Configuration dialog box opens. In the Settings section, click the Active Profile button. The Profile Results dialog box opens.
3 4
In the shortcut list on the left, select the Replay category and click the Results icon. Select the Monitoring tab.
265
The Automatically start monitoring option is activated by default. This means that when you run a load test, Performance Explorer opens automatically using a default template that invokes a display of relevant client information. 5 If you want to customize monitoring, enable the Use custom monitoring template, and click the Create Custom Monitor Template button. Performance Explorer creates and opens a template with the name of your project, which is the same as the default template. 6 Click Edit Custom Monitor Template, to customize the new template and change the information display. You can close or maintain the default monitoring windows and you can add one or more windows to provide additional information. To set up Performance Explorer to display additional information, do the following: a From the menu bar select Monitor/Add Data Source. The Data Source Wizard opens.
266
In the tree view, expand the folder that corresponds to the operating system on which the Person COM server runs. Within that folder, select System. Click Next. In the Connection Parameters dialog, enter connection parameters such as the host name or IP address of the server, the connection port, the user name, and the password. The data you enter here depends on the operating system that runs on the computer you are monitoring.
d e
f g
Click Next once you have entered the connection parameters. In the next dialog box, select the performance counters you wish to monitor. Of particular interest are processor and memory utilization of the server under test.
Click Finish. Performance Explorer opens a new window, displaying real-time data for the performance counters you have selected.
267
9 LOAD TESTING AN ADO APPLICATION Tutorial 6: Viewing the results of a load test
Later, when you run the load test, the monitor view will look similar to the following.
In Tutorial 4, you learned how to: Find a test baseline Confirm a test baseline Customize server monitoring for a load test Adjust a workload Execute a load test
Tutorial 6: Viewing the results of a load test

SilkPerformer incorporates Performance Explorer, a powerful graphing and analysis tool, to assist you in working with results information. Performance Explorer enables you to analyze results information with advanced features for creating statistical reports and displaying performance results in real-time generated graphics. Results information varies depending on the type of application and/or server under test. In general, the following is available: Response time information: This is the total time it takes to process a given timer; it provides application performance information from the client perspective.
268
Throughput information: This is the average rate at which a given timer is processed by the server; it allows you to analyze performance from the server perspective.

Procedure To explore an overview report: 1 On the Workflow toolbar, click Explore Results. The Workflow - Explore Results dialog box opens.
269
Performance Explorer opens and the HTML overview report is generated.

270
2 3
In the Templates area, select the Timer option. Click Finish. Performance Explorer opens a new chart that contains a graph of the active users.
You see the default graph with the average number of active users, and one or more default measurements (if any). 4 5 Expand the Explore tree view. In the Explore tree view, select Transactions/TMain.
271
Drag the TMain measurement into the new view. A chart similar to the following appears.
The load test that you ran in the previous tutorial lasted only five minutes, so there are few measurements, which makes it difficult to draw any conclusions. Real load tests can last several hours, a few days, or even a week. Such complete tests provide result information that allows you to accurately analyze server performance.
In Tutorial 6 you learned how to: Explore response time measurements
272
10
0rh 1e C t p a
Load Testing a WAP Application

This chapter contains a series of tutorials that will help you to start load-testing WAP applications with SilkPerformer. In WAP load-testing, a distinction is made between testing the WAP gateway and testing the Web environment that is hosting the WAP application. These tutorials will show you both ways of load-testing. Load-testing the servers that host WAP applications is very similar to load-testing Web content and is largely covered by these Web tutorials. To perform this tutorial, we will use the Nokia Emulator. You need to install the Nokia Mobile Browser Simulator, the Nokia WAP Gateway Simulator, and, as a prerequisite, Suns Java Runtime Environment 1.2 or later.
Introduction
What you will learn
This chapter contains the following sections:

Section Page
Overview Tutorial 1: Running a sample load test Tutorial 2: Creating a test script with the Recorder Tutorial 3: Customizing the generated test script Tutorial 4: Replaying the customized test scripts Tutorial 5: Viewing the results of your load test
274 274 280 293 296 305
273
10 LOAD TESTING A WAP APPLICATION Overview
Overview
Each of the following tutorials provides step-by-step instructions for performing important SilkPerformer tasks. You should complete these tutorials in order, since each tutorial builds upon what you have learned in the previous ones. Execute predefined load tests on your local machine. Create test scripts by recording HTTP traffic using the Recorder. Customize the recorded test scripts. Run the customized scripts, using multiple virtual users. Use reporting tools to view selected multiple throughput and response time information.

In this first tutorial, you will learn to create a load-testing project and execute a sample script that is provided with SilkPerformer. To perform this tutorial you need to use a WAP sample application, which is included on your SilkPerformer CD-ROM. See Setting up the SilkCentral Performance Manager WAP sample application for installation instructions. This sample application generates server monitoring data on a WAP device. To keep it simple, you will work with sample test scripts that are provided with SilkPerformer. These scripts, named WAP_Samp_HTML.bdf and WAP_Samp_ WML.bdf, are both located in the Working\Samples\Wireless folder.
Creating your load-testing project

You have to create a project file for every WAP application you plan to load test with SilkPerformer. In this project file you administer all the settings associated with one or a series of load tests. These settings include the test type, the workload model, and a number of options, which depend on the type of server you are testing. The first step in preparing your load test is to set up the basic outlines of your project - give it a name, add a short description, and choose the kind of application you want to test.
Creating a project
Procedure To create a load-testing project: 1 Open SilkPerformer.
274
10 LOAD TESTING A WAP APPLICATION Tutorial 1: Running a sample load test
If you did not close the project you last worked on, SilkPerformer will open with that project. 2 3 Close any open projects. In the Workflow bar, click Start here. The Workflow Outline Project dialog box opens.
4 5
In the Project name text box, enter WAP Tutorial as the name for your load-testing project. In the Project description text box, enter a short description for your project. This description is only for your own project management. From the Application type list, select the WAP option. Click OK. SilkPerformer will create a new load-testing project called WAP Tutorial with the default settings and your local computer as the only agent.
6 7
Adding a load-testing script to your project

To run a load test, you need to have a test script. Therefore, each project must contain at least one load-testing script. Each script defines one or more different groups of virtual users and the actions they will perform during the test. In this tutorial you will use Sample scripts that are provided with SilkPerformer. Before you can run a test script, you need to add it to your project.
275
10 LOAD TESTING A WAP APPLICATION Tutorial 1: Running a sample load test Adding a test script
Procedure To add a pre-defined script to your project: 1 In the SilkPerformer Workflow bar, click Model Script. The Workflow - Model Script dialog box opens.
2 3 4
In the Script area, select Sample script. Click OK. In the Open dialog box, navigate to the Working\Samples\Wireless folder in the SilkPerformer installation directory and select the sample script WAP_Samp_HTML.bdf. This sample script will be used for sending HTTP traffic directly to the Web server. Click Open. A SilkPerformer Message box asks you if you want to add the test script to your load-testing project.
6 7
Click Yes to add the selected test script to your project. Repeat the above steps 1 to 6 to also add the WAP_Samp_WML.bdf script to your project. This sample script will be used for sending WAP traffic to the WAP gateway. SilkPerformer will add both scripts to the project and will for each open an editor window.
Pointing the test at the servers involved

Before you can perform a trial run of your test script, you need to specify where the WAP gateway is located and where the WAP sample application is installed.
276
10 LOAD TESTING A WAP APPLICATION Tutorial 1: Running a sample load test Specifying the server(s)
Procedure To point the test at your Web server and at your WAP gateway: 1 2 From the SilkPerformer menu bar, select Settings/Active Profile. The Profile [Profile1] Simulation dialog box opens. In the shortcut list on the left side, select the Replay category and click the WAP icon. You see the following.
3 4
Make sure the Custom option is selected from the Phone list box. Click the Gateway tab. You see the following.
277
5 6 7 8
In the Host name or IP address text box, enter the name or IP address of the host that accommodates the Gateway. From the Connection type list, select Connection-less. In the shortcut list on the left side, select the Replay category and click the Internet icon. Click the Hosts tab. You see the following.
In the Standardhost area, enter the name or IP address of the Web server that hosts the WAP sample application. This parameter will replace the standardhost variable in the sample scripts.
10 Click OK.
Trying out your sample script

You are now ready to perform the third step of the load-testing workflow, trying out your sample script.
Sending HTTP traffic to the Web server
Procedure To try out the WAP_Samp_HTML test script: 1 In the SilkPerformer Workflow bar, click Try Script.
278
2 3
Select the WAP_Samp_HTML.bdf script. Click Run. SilkPerformer launches the load test and displays progress information in the Monitor window. The Data Explorer opens and shows you the Web pages that are downloaded from the Web server.
4
Sending WAP traffic to the WAP gateway
Close the Data Explorer.
Procedure To try out the WAP_Samp_WML test script: 1 In the SilkPerformer Workflow bar, click Try Script. The Workflow Try Script dialog box opens.
279
10 LOAD TESTING A WAP APPLICATION Tutorial 2: Creating a test script with the Recorder
2 3
Select the WAP_Samp_WML.bdf script. Click Run. SilkPerformer launches the load test and displays progress information in the Monitor window. The Data Explorer opens and shows you the Web pages that have been downloaded via the WAP gateway.
4 5 6
Close the Data Explorer. From the menu bar, select File/Save Project. From the menu bar, select File/Close Project.
In Tutorial 1, you learned how to: Outline a load-testing project Add a sample script to the project Try out the sample script for testing a Web server Try out the sample script for testing a WAP gateway
Tutorial 2: Creating a test script with the Recorder

In this tutorial, you will record the HTTP traffic between a WAP browser emulation toolkit and the Web server. Then you will generate a test script based on the recorded traffic and try out the test script.
Recording traffic
To record traffic with the Recorder, configure your WAP browser emulator so that it communicates with the Web server via HTTP. Based on the recorded traffic, you can then generate two different kinds of test scripts, one for sending WAP traffic to the WAP gateway and one for sending HTTP traffic directly to the Web server. After you have generated a test script, you can adjust a number of settings for replaying the script. You can easily customize this test script to simulate any number of virtual users. Recording, customizing, and replaying a test script will be covered separately in Tutorials 2, 3, and 4. In Tutorial 5, you will learn to analyze the results of the load test you ran.
Sample: Displaying monitoring data on a WAP device.
In the remaining tutorials, you will use the WAP sample application that is included in your SilkPerformer installation. See Setting up the SilkCentral Performance Manager WAP sample application, for installation instructions. This sample application delivers server monitoring data to a WAP device. This tutorial includes the following steps: Recording traffic between a WAP browser and the Web server that hosts the WAP application
280
Generating a test script based on the recorded traffic, which will send WAP traffic to the WAP gateway Generating a test script that will send HTTP traffic to the Web server Adapting the necessary settings for properly replaying the script Trying out and validating the test script
Creating your load-testing project

To load test the monitoring application, you first have to create a project file. The project file will administer all the settings associated with a series of load tests, including the test type and a number of WAP-specific options.
Creating a project
Procedure To create a load-testing project: 1 2 Close any open projects. In the Workflow bar, click Start here. The Workflow Outline Project dialog box opens.
3 4 5 6
In the Project name text box, enter WAP Sample. In the Project description text box, enter a short description of your WAP load-testing project. From the Application type list, select the WAP option. Click OK.
281
Checking the profile settings

Before you can start recording, you must decide if you want to load-test the WAP gateway by burdening it with WAP traffic, or if you want to load-test the Web server by burdening it with HTTP traffic. SilkPerformer adjusts the relevant profile settings automatically.
Checking the settings
Procedure To check the system settings for recording traffic: 1 2 3 From the SilkPerformer menu bar, select Settings - Active Profile. In the shortcut list on the left side, select the Record category and click the Web icon. Click the Recording tab. The Profile [Profile1] - Web dialog box opens.
4 5
In the Browser emulation level area, make sure the Browser-level API (HTTP) option is selected. Select the Generate WAP script option. If this option is selected, SilkPerformer generates test scripts that will send WAP requests to a WAP gateway; this kind of test script will consist of function calls with the Wap prefix. If this option is disabled, SilkPerformer generates test scripts that will send HTTP requests directly to the content server; this kind of test script will consist of function calls with the Web prefix.
Click OK to save the settings and close the dialog box.
282
Now you will specify which WAP browser emulator you will use for recording. If any of the following WAP toolkits exist on your computer when you install SilkPerformer, the application profiles for the toolkits are set up automatically: Nokia Mobile Browser Simulator and Nokia WAP Gateway Simulator UP.SDK 4.0, UP.SDK 4.1 If the application profiles were set up by SilkPerformer, you can omit the following two procedures.
Setting up application profiles
Procedure To set up a profile for the WAP browser emulation toolkit: 1 2 From the SilkPerformer menu bar, select Settings/System. In the shortcut list on the left side, click the Recorder icon. The System Settings - Recorder dialog box opens.
Click Add.
283
4 5 6 7 8 9
In the Application profile text box, enter a name for the profile, for example, Nokia WAP Toolkit. In the Application path text box, specify the executable of the WAP browser emulation toolkit. Click Browse to locate the executable. From the Application type list box, select the Custom Application option. In the API selection area, select Web. Click Web Settings.... The Web Settings dialog box opens. From the list box choose the ws2_32.dll option. Click OK.
10 Click OK to add the application profile to the system settings. Some parts of the Nokia WAP Toolkit are implemented in Java. For recording traffic that is generated by Java applications, you must set up an application profile for the Java Virtual Machine. Procedure To set up a profile for the Java Virtual Machine: 1 In the Application Profiles tab of the System Settings - Recorder dialog box, click Add.
284
2 3
In the Application profile text box, enter a name for the profile, for example, Java Virtual Machine. In the Application path text box, specify the executable of the Java Virtual Machine. This file is called javaw.exe. Click Browse to locate the executable. From the Application type list box, select the Custom Application option. In the API selection area, select Web. Click Web Settings.... The Web Settings dialog box opens. From the list box choose the ws2_32.dll option. Click OK. Click OK to add the application profile to the system settings. In the System Settings - Recorder dialog box, click OK.
4 5 6 7 8 9
You now have to configure the Nokia emulators communication settings.

Configuring the Nokia WAP Gateway Simulator
To configure the Nokia WAP Gateway Simulator, refer to the products documentation. Make sure to configure software to use an HTTP Server Connection. If you are using a proxy server for accessing the sample application, you also need to configure the HTTP Proxy settings. In addition, specify the number of the port
at which the proxy server listens for connections; typically this is port 8080. Separate the URL and the port number by a colon (:). SilkPerformer will automatically launch the toolkit when you start recording traffic.

Common WAP browsers and emulators enable you to select the communication protocol that should be used, HTTP or WAP. To load-test a WAP server, the HTTP traffic between a WAP browser (or a WAP browser emulator) and the content, the server behavior needs to be recorded and described in a script. This script can then be modified to simulate any number of virtual users to perform actions similar to those performed by the real user during the recorded session.
2 3
In the Script area, select Record. From the Select application profile list box, select the Nokia WAP Toolkit. This toolkit will be used for generating HTTP traffic. In the URL text box, specify the URL of the WAP sample application. In this example, the sample application is located at http://bach/wap/welcome.wml.
286
Note If you are using UP.SDK, you cannot specify the URL in the Workflow - Model Script dialog box; enter the URL in the WAP browser. 5 Click OK. SilkPerformer opens both the Recorder and the Nokia WAP Toolkit. The WAP browser emulator displays the monitoring applications welcome message. 6 7 8 In the WAP browser emulator, enter the name and the password to log in. Both the name and the password are a. From the Option menu, select Submit. To view your actions as well as the requests sent to the server and the responses received, click the Change GUI Size button in the SilkPerformer Recorder. The Recorder window will look similar to the following.
Switch back to the WAP browser emulator. The emulator lists projects for which monitoring data is available.
10 Select the E-banking project and click Link. 11 Select one of the monitors and click Link. 12 Select one of the time frames. You will see a table similar to the following. 13 When you are done viewing monitoring data, close the WAP browser. 14 In the SilkPerformer Recorder, click the Stop Recording button. The Save As dialog box opens. 15 In the File name text box, enter WAPSample_01. 16 Click Save.
287
17 Close the Recorder. SilkPerformer automatically adds the script to your current load-testing project. You have now generated a script that consists of functions with the Wap prefix. When this script is executed, it will send WAP traffic to the WAP gateway.
Generating a Web script
In addition to this test script, you can create a script that will send HTTP traffic to the Web server. Procedure To create a test script for load-testing the Web server. 1 2 3 From the SilkPerformer menu bar, select Settings/Active Profile. The Profile - [Profile1] - Simulation dialog box opens. In the shortcut list on the left side, select the Record category and click the Web icon. Click the Recording tab. You see the following.
4 5
Disable the Generate WAP script option. Repeat all steps of the previous procedure, but save the generated script as WAPSample_02.
288
Pointing the test at the servers involved

Before you can perform a trial run of your test scripts, you must specify where the WAP gateway is located.
Specifying the WAP gateway
Procedure To point the test at your WAP gateway: 1 2 From the SilkPerformer menu bar, select Settings/Active Profile. The Profile [Profile1] Simulation dialog box opens. In the shortcut list on the left side, select the Replay category and click the WAP icon. You see the Phone tab.
Make sure the Custom option is selected from the Phone list box.
289
Click the Gateway tab. You see the following.
5 6 7
In the Host name or IP address text box, enter the name or IP address of the host that supports the WAP gateway. From the Connection type list, select Connection-less. Select OK.

Next, you must perform a trial run of the generated test script. The object of this trial run is to make sure the script contains no errors. It will accurately reproduce the interaction between the WAP browser and the WAP gateway.
Trying out the scripts
Procedure To try out the test script that produces WAP traffic: 1 In the Workflow bar, click Try Script.
290
2 3
Make sure the WAPSample_01 script is selected in the Script list. Click Run. SilkPerformer runs a single virtual user, called VUser, which performs all the actions that you have performed during the previous recording session. While the single-user test is running, SilkPerformer displays progress information in the Monitor window, for example, the number of transactions executed, the response time of the last transaction, and the average response time.
291
The Monitor window looks like this.
In addition, the Data Explorer opens and displays the WAP pages that the virtual user downloads via the WAP gateway. 4 Monitor the load test and wait until the user has finished executing its tasks. a In the top part of the Monitor window, select an agent computer or a user group that you want to monitor. In the bottom part of the Monitor window, SilkPerformer displays overview information about all virtual users running on the selected agent computer or belonging to the selected user group. b In the Virtual User window, SilkPerformer will display detailed runtime information about the selected user. The type of information displayed depends on the options you have selected at the top of the Monitor window, for example, the transactions and functions the user executes, and the data the user sends to and receives from the server. Display Errors. Select this button to display an error message indicating the probable cause of a user-related error, each time a user-related error occurs for the selected user. Display Transactions. Select this button to display a message when a user has finished executing a transaction; the message will indicate whether the transaction was successful or not.
292
10 LOAD TESTING A WAP APPLICATION Tutorial 3: Customizing the generated test script
Display Functions. Select this button to display a message for each function call a given user performs, including the function name and all its parameters. Display Info. Select this button to display messages containing information about the current action a selected user performs. Display Data. Select this button to show which data the selected user exchanges with the server. Display all Errors of all Users. Select this button to display error messages for all errors of all users. Each error message will indicate user, agent and probable cause of the error. 5 6 7
Close the Data Explorer. From the menu bar, select File/Close to close the Monitor window. Repeat the steps 1 to 6 for the second test script, but this time select the WAPSample_02 script in the Workflow Try Script dialog box.
In Tutorial 2, you learned how to: Set up an application profile Create a load-testing project Record HTTP traffic between a WAP browser emulator and a Web server Generate two different test scripts based on the recorded traffic Try out the generated test scripts

If you use your test script as it now is, your load test will only repeatedly reproduce the exact behavior recorded on one particular occasion. This kind of repetition will not produce realistic Web traffic, and, therefore, it will not provide very accurate results. To realistically emulate the varied traffic of a large number of different users, your virtual users need to be as different as real users are. Two key tasks will help you create a real-world simulation: 1 Replacing constant values with random variables 2 Assigning different tasks to virtual users Note You must use Benchmark Description Language (BDL), SilkPerformers high-level scripting language, to customize generated test scripts. Although knowledge of BDL is not required
293
for this tutorial, it might be helpful to browse the introductory BDL Reference topics in the SilkPerformer Online Help for more information about BDL before you begin.

Where randomized data is necessary, random variables are employed to provide realistic user data. In this way, SilkPerformer furnishes the virtual users with varied personal data like name, address, credit card number, user ID and password, and so on. In our example we show you how to provide different user IDs and passwords for logging on to the application.
Procedure To replace constant values with random variables: 1 In the Workflow bar, click Customize Test. The Workflow Customize Test dialog box opens.
2 3
Click the edit your script link. The script opens for editing. A help file that contains valid user IDs and passwords is provided with the sample application. Locate this file WAPTutorialUserNames.CSV in the Working\Samples\Wireless folder. Copy this file to your current directory of your load-testing project, Working\Projects\WAPSample. To declare the variables that are required for reading the file, insert the following code into your test script, before the dcluser section.
var hFile : number; sName, sPass : string; // file handle // user ID and password
294
Insert the following function call into the initial transaction (TInit). This call reads the user IDs and password from the file and makes them available to SilkPerformer. The code you have to insert is shown in bold.
transaction TInit begin FileCSVLoad(hFile, "WAPTutorialUserNames.csv", ";"); end TInit;
Advise the virtual user to randomly select a user ID and a password from the list of user IDs and passwords. To do so, insert the function calls shown in bold after the WebUrl function call that loads the login.wml document.
WebUrl("http://bach/wap/login.wml", 5.00); FileGetRndRow(hFile); sName := FileGetCol(hFile, 1, sizeof(sName)); sPass := FileGetCol(hFile, 2, sizeof(sPass)); WapFormPost("http://bach/wap/validate.asp", WAP_VALIDATE_ASP001, 2.50);
Adapt the Web form declaration that contains the user ID and the password. You find the Web form declarations in the dclform section in the bottom part of your test script. The form declaration should then look similar to the following. The code shown in bold type is what you should change.
dclform WAP_VALIDATE_ASP001: "name" := sName, "password" := sPass;
When you have made the changes in the script file, select File/Save from the menu bar.
You have now randomized your test script so that virtual user will have different user IDs and passwords.

Usually a load test simulates a number of different types of users. In the test script, you must specify which actions each type of virtual user will perform.
Procedure To specify which tasks each user will perform: 1 Navigate to the dcluser section of the test script. You can do this by selecting User Groups/VUser in the Active Script window. You see the following.
dcluser user VUser transactions TInit : begin; TMain : 1;
295
10 LOAD TESTING A WAP APPLICATION Tutorial 4: Replaying the customized test scripts
In this section, a single user group is defined, called VUser. By default, this user group will perform the transactions you created, TInit and TMain, once each. 2 Edit the dcluser section of the script as the example below shows. The code in bold is what you must change or insert.
dcluser user VUser transactions TInit : begin; TMain : 5;
Move the following statements from the beginning of the TMain transaction to the TInit transaction.
WapUrl("http://bach/wap/welcome.wml", 1.90); WapUrl("http://bach/wap/logo.wbmp", 5.14); WapUrl("http://bach/wap/login.wml", 6.41); FileGetRndRow(hFile); //select randomly a row of the help file sName := FileGetCol(hFile, 1, sizeof(sName)); sPass := FileGetCol(hFile, 2, sizeof(sPass)); WapFormPost("http://bach/wap/validate.asp", WAP_VALIDATE_ASP001, 2.32);
In the edited version of the script, the user group VUser performs the TInit transaction and then the TMain transaction, five times. 4 5 6 7
Select File/Save from the menu bar to save your changes. In the Workflow toolbar, click Customize Test. The Workflow Customize Test dialog box opens. Click Yes to confirm that you are done customizing the test script. Repeat the customizing steps for your second script.
Tutorial 4: Replaying the customized test scripts

After you have created a test script by recording traffic and then customized the script, you are ready to load-test your server by replaying the script. To run a load test, you must perform the following steps: Find the test baseline
Confirm the test baseline Set up server monitoring for your load test Execute the load test

After you have customized the load-testing script, you need to determine baseline performance. This is the ideal performance of your application when it is not under real pressure. To obtain this test baseline, the fully customized script is run with just one user per user group. This will provide you with a solid basis for comparison with the situation when the application is fully taxed by a load test.
Procedure To find the load test baseline: 1 In the Workflow toolbar, click the Find Baseline button. The Workflow - Find Baseline dialog box opens
This dialog box lists all the user groups you have set up in your testing script. 2 Click Run. SilkPerformer runs one virtual user of each user group that you have declared in the test script. While the test is running, you can watch its progress in the Monitor window.

After running the baseline test, you must confirm that the test results reflect the desired performance of the tested server. To do this, you inspect the results of the test. If they are satisfactory, the baseline is established and will form the basis for a later comparison with results from full load tests.
297
10 LOAD TESTING A WAP APPLICATION Tutorial 4: Replaying the customized test scripts Confirming the baseline
2 3 4 5 6
Click the Baseline Report button. The Baseline Report opens. Check the report carefully. In particular, make sure that no errors have occurred during your baseline test. Click Accept Baseline button in the Baseline Report. Click Yes and OK by the Message boxes that come up. If your baseline report indicates no errors, click Yes in the Workflow Confirm Baseline dialog box to confirm that you have found the baseline.

298
This dialog box shows all possible workload models, which can be selected. 2 3 Select Increasing workload model. Click OK. SilkPerformer now opens the Workload Configuration dialog box.

After you have adjust the workload, you are ready to run the full load test. The test script is run with multiple virtual users in order to test the targeted server. A large load test will need an appropriate testing environment set up in the local area network and must include a full complement of agent computers to host the virtual users. For this tutorial, only your local computer will be used.
Running the test
299
2 3
In the Max. VUsers column, change the number of virtual users for each script to 30. Specify to start with 10 users and add 5 users after 20 seconds.
You are now ready to run the load test. When you run a test, SilkPerformers sophisticated monitoring tool Performance Explorer will automatically generate a live graphical display of a default set of test data for the server you are testing. You can disable this default option by deselecting the setting Automatically start monitoring. You can also change the default monitoring settings by pressing the Active profile button (See Customizing server monitoring for your load test). Once monitoring is set up the way you want it, you can continue and run the test. 4 Click Run to start the test now, or Click OK to save the settings and start the test later. When you start the test, SilkPerformer will run the load test with the two customized scripts. If the (default) option Automatically start monitoring is enabled, Performance Explorer will open and generate a live graphical display of the specified set of test data. If you wish you can adapt the views by
300
adding or deleting specific measurements. For this you can expand the tree menu on the left and drag selected measurements into existing or new view graphs.

An important feature SilkPerformer provides is that you can monitor the server during an actual load test. Server monitoring will help you locate and analyze bottlenecks on the server. You can separately examine the performance of the operating system, the network and the server application, which in this case is the Web server. Server monitoring is performed with Performance Explorer, a powerful tool SilkPerformer incorporates. When you run a test, the default procedure is that Performance Explorer automatically opens a set of views containing a live graphical display of a selection of test data that is particularly significant for the server you are testing. You can disable this default option by deselecting the setting Automatically start monitoring in the Workload Configuration [.......] dialog box. You can also customize the default monitoring settings and select a particular set of data sources.
Setting up server
Procedure To customize server monitoring for your load test: 1 2 In the Workflow toolbar, click Run Test. The Workload Configuration dialog box opens. In the Settings section, click the Active Profile button.
301
The Profile [Profile1} - Results dialog box opens.
3 4
In the shortcut list on the left side, select the Replay category and click the Results icon. Select the Monitoring tab. The option Automatically start monitoring is activated by default. This means, that when you run a load test, Performance Explorer will open automatically, using a default template that invokes a display of relevant client information.
5 6
If you want to customize monitoring, enable Use custom monitoring template, and click the Create Customer Monitor Template button. Click the Edit Customer Monitor Template button to customize the new template and change which information is displayed. You can maintain or close the default monitoring windows. Also, you can add one or more windows to provide additional information. To set up Performance Explorer to display additional information, proceed as follows.
Click the Edit Customer Monitor Template button to customize the new template and change which information is displayed. You can maintain or close the default monitoring windows. Also, you can add one or more windows to provide additional information.
302
To set up Performance Explorer to display additional information, proceed as follows. a From the menu bar select Monitor/Add Data Source. The Data Source Wizard opens.
In the tree view, expand the folder that corresponds to the operating system on which the server you are testing is running. Within the folder, select System. Click Next.
303
In the Connection Parameters dialog box, enter connection parameters, like the host name or IP address of the computer that hosts the WAP sample application, the connection port, the user name, and the password. The data you must enter here depends on the operating system that is running on the computer you are monitoring.
f g
Click Next when you are done entering connection parameters. In the next dialog box, select the performance counters you want to monitor. Of particular interest are the processor and memory utilization. Click Finish.
The Performance Explorer will open a new window, displaying realtime data for the performance counters you have selected. Later, when you are running the load test, the monitor view will look similar to the following.
In Tutorial 4, you learned how to: Find the test baseline Confirm the test baseline Customize monitoring for your load test Adjusting the workload Execute the load test
304
10 LOAD TESTING A WAP APPLICATION Tutorial 5: Viewing the results of your load test

SilkPerformer incorporates Performance Explorer, a powerful graphing and analysis tool, to help you work with your results information. Performance Explorer allows you to obtain detailed test results, which can be displayed in real time generated graphics, or in extensive statistical performance reports. Both are supported by advanced graphical features. When you press the Explore Results button in the SilkPerformer workflow bar, Performance Explorer will SilkPerformer incorporates default templates of information for displaying. Results information may vary, depending on the type of application and/or server being tested. In general it falls into the following categories: Response time information: This is the total time it takes to process a given transaction; it provides application performance information from the point of view of the client. Throughput information: This is the average rate at which a given transaction is processed by the server; it allows you to analyze performance from the point of view of the server.

You can consult an HTML overview report that contains a summary of all measurements performed.
Procedure To generate and view an overview report: 1 In the Workflow toolbar, click Explore Results.
305
The Workflow - Explore Results dialog box opens.
Click the Performance Explorer button. The Performance Explorer opens and displays an overview report.
306
This report includes the most important test results in tabular and graphical form. It includes the following sections: General information Summary tables User groups Detailed charts
Exploring WAP-specific measurements

When you analyze the performance of an application from the point of view of the client, you examine the response times for transactions and individual timers. This enables you to find out how users will experience their interaction with the application. When you analyze the performance of a server from the point of view of the server, you examine the throughput rate. Throughput is the work done by the application within a specific time interval, for example, the number of requests that the application processes within a second, a minute, or an hour. A common goal in load-testing is to ensure that the throughput rate is above a specified, critical limit.
Procedure To explore detailed response time measurements: 1 In the Performance Explorer Workflow bar, click the Select Graph button. The Template dialog box opens.
In the Templates area, select the WAP option.

Click Finish. The Performance Explorer opens a new chart that contains a graph of the behavior of active users.
You see a graph with the average number of active users, the number of errors that occurred, the number of HTTP hits on the server, and average response time of all WAP requests. The load test that you ran in the previous tutorial lasted only two minutes, so there are only a few measurements to view and it is difficult to derive conclusive results from these. In actual use of SilkPerformer, however, you will run load tests that last several hours, a few days or even a week; these tests will then provide results information from which you can accurately analyze the performance of your server.
In Tutorial 5, you learned how to: Explore overall measurements Explore WAP-specific measurements
308
11
1e rh C t p a
Load Testing a Jacada Application

This chapter is replaced by a Powerpoint presentation shipped on the SilkPerformer product CD ROM. This presentation will give you an overview on how to use SilkPerformer for testing Jacada applications. It will guide you through the steps of creating a project and choosing the correct settings for recording and replaying Jacada scripts. To start the screen show, select Start from the Windows desktop, navigate to the SilkPerformer folder, select Doc and start the SilkPerformer Jacada Tutorial Powerpoint presentation. If you navigate to the doc folder in the SilkPerformer installation directory, you will find the Powerpoint slides in .PPS formats. If you do not have the installation CD available, contact Customer Care.
Introduction
309
11 LOAD TESTING A JACADA APPLICATION
310
12
2rh 1e C t p a
Load Testing IBM Mainframe Applications

This chapter contains a series of tutorials that will help you begin load-testing IBM TN3270/5250 protocol-based applications with SilkPerformer. This chapter contains the following sections:
Section Page
Overview Tutorial 1: Creating a Script with the Recorder Tutorial 2: Customizing the Generated Test Script Tutorial 3: Replaying the Customized Script
311 312 319 322
Overview
Each of the following tutorials provides step-by-step instructions for important SilkPerformer tasks. You should perform these tutorials in order as each tutorial builds on the lessons learned in the previous tutorial. The procedure for load testing IBM TN3270 and 5250 applications with SilkPerformer is almost identical. While this tutorial focuses on testing a 3270 application, it can be applied to a 5250 application too. Differences between testing the two protocols will be noted within the tutorial where applicable. You will learn how to do the following: Generate a test script by recording a mainframe system. Customize the recorded test script. Run the customized script in a TryScript run.
311
12 LOAD TESTING IBM MAINFRAME APPLICATIONS Tutorial 1: Creating a Script with the Recorder
Prerequisites
Installing a terminal emulator
Before you can begin recording a mainframe application, you need to install a terminal emulator. SilkPerformer records traffic between terminal emulation software and mainframe servers. While SilkPerformer supports most terminal emulators, it is recommended that you use Micro Focus RUMBA, available from http://www.microfocus.com/ products/RUMBA/.
Sample mainframe application Code page settings
For this tutorial, you will need access to a mainframe application that offers telnet access. There are few public domain telnet servers in service currently, so you will need to create a connection to your own terminal emulation site. If you will be testing an application that displays special characters, note that the host screens in TrueLog Explorer will not display special characters correctly. To correct this problem, you may have to adjust the terminal type and code page settings. To do this, select the Active Profile command from the Workbenchs Settings menu. Then select Terminal Client under the Record tab in the left pane. In the Host code page drop-down listbox, select the appropriate code page for the characters that are to displayed (IBM EBCDIC <country> for 3270/5250 applications).
Tutorial 1: Creating a Script with the Recorder

The SilkPerformer Recorder allows you to capture function calls that an IBM mainframe (TN3270/3270e/5250) terminal emulator performs. After you record function calls, you can save them as a test script. You can then easily customize and replay the script to simulate a large number of virtual users. Customizing and replaying a script is covered in Tutorials 2 and 3. This tutorial includes the following steps: Outlining a Project Setting up an Application Profile Modeling a Test Script Trying Out the Generated Test Script
Outlining a Project
Before you can begin recording, you must outline a new project with the correct application type.
312
12 LOAD TESTING IBM MAINFRAME APPLICATIONS Tutorial 1: Creating a Script with the Recorder Outlining a project
Procedure To create a new project: 1 2 3 From SilkPerformers menu bar, select File/New Project. The Workflow Outline Project dialog box opens. Enter a project name, for example TN3270_Tutorial, and a description for the new project. Select Terminal Emulation/TN3270 as the Application type Alternative For recording a TN5250 application, you would select Terminal Emulation/TN5250 as Application type. 4 Click OK to confirm your settings.
Setting up an Application Profile

When you want the SilkPerformer Recorder to capture and record the function calls that a client application performs, you must set up a profile for the client application. The profile specifies the type of client application and the type of function calls that are to be recorded. To record an IBM TN3270/5250 protocolbased application, the client application that needs to be recorded is a terminal emulator.
Procedure To set up a profile for the client application: 1 From SilkPerformers menu bar, select Settings/System. The System Settings Workbench dialog box opens.
313
In the shortcut list on the left side, click the Recorder icon. You see the following.
314
4 5 6
In the Application profile text box, enter a name for the application profile, for example Terminal Emulator. Click Browse and locate the emulator in your RUMBA installation directory. If youre using RUMBA as terminal emulator, check the Record executable is different from application path check box, then enter WDDspPag.exe in the Record executable field. From the Application type list box, select the Custom Application option. In the Protocol selection area, select the TCP/IP option. Click Web Settings. On the following dialog box, select ws2_32.dll in the WinSock list box and click OK to confirm. SilkPerformer adds the new application profile to the profile list in the System Settings Recorder dialog box.
7 8 9
10 Click OK on the Application Profile dialog box.
315
Modeling a Test Script

To test a mainframe application, the function calls that the client application performs need to be recorded and then described in a test script. The script ultimately enables any number of virtual users to perform actions similar to those performed during the recording session. Alternative For recording an IBM TN5250 application, youll have to connect to a 5250 application instead. Note If you encounter any problems with the screen display (characters not displaying as they should), make sure that youve defined the correct code page settings. While the default settings will work in most cases, you may need country-specific settings for your application recording. Code page settings can be changed in SilkPerformers Settings/Active Profile menu, under the Record/ Terminal Client option in the left pane. Here youll find the Host code page list (IBM EBCDIC <country> for recording TN3270/ 5250 applications).
2 3 4
In the Script area, select the Record option. From the Select application profile list box, select Terminal Emulator (the profile you defined previously). Click OK.
316
SilkPerformer opens the Recorder and starts the emulator. 5 6 7 8 Configure your emulator to connect to a mainframe application via a Telnet session. Once connected, perform a few simple operations on the server. For example, login/log out, and execute a search query. Close your terminal emulator. Stop the Recorder, save the BDF file, and close the Recorder. SilkPerformer automatically adds the script to your current load-testing project.
Trying Out the Generated Test Script

Now you will perform a trial run of the test script that youve created. The object of the trial run is to ensure that the script is error free, and that it will accurately reproduce the interaction between the client application and the mainframe application.
Procedure To try out the generated test script: 1 On the Workflow bar, click Try Script. The Workflow Try Script dialog box opens.
2 3 4 5
From the Script list box, select the TN3270_Tutorial script (if it is not pre-selected). Make sure that the VUser group is selected in the Usergroup list. Enable the Animated option. Click Run.
SilkPerformer runs a single virtual user, called VUser, which performs all the actions that you performed during the recording session. You can watch the progress while the single-user test runs. TrueLog Explorer supports the visualization of terminal emulation requests and responses in the same way it supports the visualization of HTTP client requests and HTTP/HTML server responses. The three windows that are displayed with terminal emulation TrueLogs are: Tree list (left-hand pane) - Lists all terminal emulation API calls that were included in the test run. Source window (upper right-hand pane) - Displays the state of the terminal emulation application at each API node. Note TrueLog screengrabs are captured only during TryScript runs, not load tests. Information window (lower right-hand pane) - Displays data related to the most recent test run. The view tabs in this pane that are active and applicable to terminal emulation TrueLogs are Info, BDL, in-data, outdata, and Host Screen Info.
In Tutorial 1, you learned how to: Set up an application profile Record traffic between a terminal emulator and a server
318
12 LOAD TESTING IBM MAINFRAME APPLICATIONS Tutorial 2: Customizing the Generated Test Script
Generate a test script based on the recorded traffic Try out the generated test script
Tutorial 2: Customizing the Generated Test Script

Customizing the test script you have generated allows you to insert time measurements, verifications, screen synchronizations and other customizations. In this tutorial you will focus on inserting a timer, verifying screen contents, and looking briefly at some functions in the script. Note You must use Benchmark Description Language (BDL), SilkPerformers high-level scripting language, to customize some parts of the generated test script. Although knowledge of BDL is not required for this tutorial, it may be helpful for you to browse the introductory BDL Reference topics in SilkPerformer Help for more information about BDL before you begin.
Adding a Timer to the Script

Now you will add a timer to our script so that you can measure the response time of a certain transaction during a test. This can be done visually in TrueLog Explorer. Procedure To add a timer to the script: 1 Within TrueLog Explorer, Right-click the node within the API node tree menu that displays the search screen where you executed the sample search query. Select Start new Timer.
319
3 4 5
In the Start Timer dialog box, enter the name Search, then click OK. One or two nodes down, the results screen of your search will be displayed. Right-click this node and select Stop Timer. On the Select timer dialog box, select the Search timer and click OK. Click OK again to confirm the script modification.
Adding Content Verification to the Script

Now that youve added a timer to measure how long a specified search transaction takes during replay, you need to verify that the results of the search are correct during replay. This can also be done visually in TrueLog Explorer, directly on the displayed host screen. Procedure To add content verification to the script: 1 2 With TrueLog Explorer still open, select the same node to which you added the Stop Timer. Look at the host screen displayed in the upper right-hand pane. For your content verification you may want to verify that, later during a test, the search query produces the same number of items as were identified
320
during script recording. To do this, highlight text on the host screen that indicates the number of search items that were returned (for example, ITEMS 1-4 OF 101). 3 Right-click the highlighted text and select Verify Selected Text.
On the Insert Verification Function dialog box, leave the settings as they are and confirm insertion of the verification function by clicking OK.
For detailed information about verification and parsing functions, refer to the TrueLog Explorer Help.
Analyzing the Script

At this point you should close TrueLog Explorer and take a look at the modified script in SilkPerformer. Some of the more interesting functions to consider are: WebTelnetScreenRecvRecordsUntilStatus: This function receives data (packets terminated by IAC EOR) from a given connection until the rendered screen contains a specified status. WebTelnetSendRecord: This function sends a Telnet record sequence to a terminal service server, which is a shortcut to <BinaryData> IAC EOR. In combination with StrToHostCP, which defines a user input command, the script sends user input to the terminal service server.
321
12 LOAD TESTING IBM MAINFRAME APPLICATIONS Tutorial 3: Replaying the Customized Script
WebTelnetScreenVerifyText: This function was inserted into the script via the content verification you created in TrueLog Explorer. It verifies rendered screen content in an active Telnet connection. WebTelnetRecvRecordsUntilClose: This function receives data (packets terminated by IAC EOR) from a given connection until the Telnet connection is closed. SilkPerformer automatically inserts this function at the end of a transaction to synchronize script replay with the actual termination of the connection.
In Tutorial 2, you learned how to: Insert a timer to measure response times Verify host screen content during replay Work with some common Telnet BDL functions
Tutorial 3: Replaying the Customized Script

Once you have created a test script by recording function calls that the client application performs and then customized the script, you can load test your server by replaying the script. To run a test, you must perform the following steps: Find the test baseline
Synchronization issues
Confirm the test baseline Define the workload model Execute the test
In some cases, synchronization between replay and a host application may fail. Refer to SilkPerformers Online Help for detailed information about scripting manual synchronization functions.
322
13
3rh 1e C t p a
Load Testing VT 100+ Applications

This chapter contains a series of tutorials that will help you to start load-testing VT 100, and later, protocol-based applications with SilkPerformer. This chapter contains the following sections:
Section Page
Overview Tutorial 1: Creating a Script with the Recorder Tutorial 2: Customizing the Generated Test Script Tutorial 3: Replaying the Customized Script
323 324 331 334
Overview
Each of the following tutorials provides step-by-step instructions for important SilkPerformer tasks. You should perform these tutorials in order as each tutorial builds on the lessons learned in the previous tutorial. The procedure for load testing VT 100 and VT 200+ applications with SilkPerformer is almost identical. The only difference lies in the application type you have to select when outlining the project. Differences between testing the two protocols will be noted within the tutorial where applicable. You will learn how to do the following: Generate a test script by recording a VT 100 application. Customize the recorded test script. Run the customized script in a TryScript run.
323
13 LOAD TESTING VT 100+ APPLICATIONS Tutorial 1: Creating a Script with the Recorder
Prerequisites
Installing a terminal emulator
Before you can begin recording a VT 100+ application, you need to install a terminal emulator. SilkPerformer records traffic between terminal emulation software and VT 100+ servers. While SilkPerformer supports most terminal emulators, it is recommended that you use Micro Focus RUMBA, available from http://www.microfocus.com/ products/RUMBA/.
Sample mainframe application Code page settings
For this tutorial, you will need access to a mainframe application that offers telnet access. There are few public domain telnet servers in service currently, so you will need to create a connection to your own terminal emulation site. If you are testing an application that displays special characters however, the host screens in TrueLog Explorer wont display the special characters correctly. To correct this problem, you may have to adjust the terminal type and code page settings. To do so, select the Active Profile command from SilkPerformer Workbenchs Settings menu. Then select Terminal Client under the Record tab in the left pane. In the Host code page list box, select the appropriate code page for the characters that will be displayed (any codepage except EBCDIC for VT 100+ applications).
Tutorial 1: Creating a Script with the Recorder

The SilkPerformer Recorder allows you to capture function calls that a VT 100+ terminal emulator performs. After you record function calls, you can save them as a test script. You can then easily customize and replay the script to simulate a large number of virtual users. Customizing and replaying a script is covered in Tutorials 2 and 3. This tutorial includes the following steps: Outlining a Project Setting up an Application Profile Modeling a Test Script Trying Out the Generated Test Script
Outlining a Project
Before you can begin recording, you must outline a new project with the correct application type.
324
13 LOAD TESTING VT 100+ APPLICATIONS Tutorial 1: Creating a Script with the Recorder Outlining a project
Procedure To create a new project: 1 2 3 From SilkPerformers menu bar, select File/New Project. The Workflow Outline Project dialog box opens. Enter a project name, for example VT100_Tutorial, and a description for the new project. Select Terminal Emulation/VT100 as the Application type Alternative For recording a VT 200+ application, you would select Terminal Emulation/VT 200+ as Application type. 4 Click OK to confirm your settings.
Setting up an Application Profile

When you want the SilkPerformer Recorder to capture and record the function calls that a client application performs, you must set up a profile for the client application. The profile specifies the type of client application and the type of function calls that are to be recorded. To record an VT 100+ protocol-based application, the client application that needs to be recorded is a terminal emulator.
Procedure To set up a profile for the client application: 1 From SilkPerformers menu bar, select Settings/System. The System Settings Workbench dialog box opens.
325
In the shortcut list on the left side, click the Recorder icon. You see the following.
326
4 5 6
In the Application profile text box, enter a name for the application profile, for example Terminal Emulator. Click Browse and locate the emulator in your RUMBA installation directory. If youre using RUMBA as terminal emulator, check the Record executable is different from application path check box, then enter WDDspPag.exe in the Record executable field. From the Application type list box, select the Custom Application option. In the Protocol selection area, select the TCP/IP option. Click Web Settings. On the following dialog box, select ws2_32.dll in the WinSock list box and click OK to confirm. SilkPerformer adds the new application profile to the profile list in the System Settings Recorder dialog box.
7 8 9
10 Click OK on the Application Profile dialog box.
327
Modeling a Test Script

To load test a VT 100+ application, the function calls that the client application performs need to be recorded and then described in a test script. The script ultimately enables any number of virtual users to perform actions similar to those performed during the recording session. Note If you encounter any problems with the screen display (characters not displaying as they should), make sure that youve defined the correct code page settings. While the default settings will work in most cases, you may need country-specific settings for your application recording. Code page settings can be changed in SilkPerformers Settings/Active Profile menu, under the Record/ Terminal Client option in the left pane. Here youll find the Host code page list (any code page but EBCDIC for recording VT 100+ applications can be selected).
2 3 4
In the Script area, select the Record option. From the Select application profile list box, select Terminal Emulator (the profile you defined previously). Click OK. SilkPerformer opens the Recorder and starts the emulator.
328
5 6 7 8
Configure your emulator to connect to a mainframe application via a Telnet session. Once connected, perform a few simple operations on the server. For example, login/log out, and execute a search query. Close your terminal emulator. Stop the Recorder, save the BDF file, and close the Recorder. SilkPerformer automatically adds the script to your current load-testing project.
Trying Out the Generated Test Script

Now you will perform a trial run of the test script that youve created. The object of the trial run is to ensure that the script is error free, and that it will accurately reproduce the interaction between the client application and the Telnet application.
Procedure To try out the generated test script: 1 On the Workflow bar, click Try Script. The Workflow Try Script dialog box opens.
2 3 4 5
From the Script list box, select the VT100_Tutorial script (if it is not preselected). Make sure that the VUser group is selected in the Usergroup list. Enable the Animated option. Click Run.
329
SilkPerformer runs a single virtual user, called VUser, which performs all the actions that you performed during the recording session. You can watch the progress while the single-user test runs. TrueLog Explorer supports the visualization of terminal emulation requests and responses in the same way it supports the visualization of HTTP client requests and HTTP/HTML server responses. The three windows that are displayed with terminal emulation TrueLogs are: Tree list (left-hand pane) - Lists all terminal emulation API calls that were included in the test run. Source window (upper right-hand pane) - Displays the state of the terminal emulation application at each API node. Note TrueLog screengrabs are captured only during TryScript runs, not load tests. Information window (lower right-hand pane) - Displays data related to the most recent test run. The view tabs in this pane that are active and applicable to terminal emulation TrueLogs are Info, BDL, in-data, outdata, and Host Screen Info.
In Tutorial 1, you learned how to: Set up an application profile Record traffic between a terminal emulator and a server
330
13 LOAD TESTING VT 100+ APPLICATIONS Tutorial 2: Customizing the Generated Test Script
Generate a test script based on the recorded traffic Try out the generated test script
Tutorial 2: Customizing the Generated Test Script

Customizing the test script you have generated allows you to insert time measurements, verifications, screen synchronizations and other customizations. In this tutorial you will focus on inserting a timer, verifying screen contents, and looking briefly at some functions in the script. Note You must use Benchmark Description Language (BDL), SilkPerformers high-level scripting language, to customize some parts of the generated test script. Although knowledge of BDL is not required for this tutorial, it may be helpful for you to browse the introductory BDL Reference topics in SilkPerformer Help for more information about BDL before you begin.
Adding a Timer to the Script

Now you will add a timer to our script so that you can measure the response time of a certain transaction during a load test. This can be done visually in TrueLog Explorer. Procedure To add a timer to the script: 1 Within TrueLog Explorer, Right-click the node within the API node tree menu that displays the search screen where you executed the sample search query. Select Start new Timer.
331
3 4 5
In the Start Timer dialog box, enter the name Search, then click OK. One or two nodes down, the results screen of your search will be displayed. Right-click this node and select Stop Timer. On the Select timer dialog box, select the Search timer and click OK. Click OK again to confirm the script modification.
Adding Content Verification to the Script

Now that youve added a timer to measure how long the specified search transaction takes during replay, you need to verify that the results of the search are correct during replay. This can also be done visually in TrueLog Explorer, directly on the displayed host screen. Procedure To add content verification to the script: 1 2 With TrueLog Explorer still open, select the same node to which you added the Stop Timer. Look at the host screen displayed in the upper right-hand pane. For your content verification you may want to verify that, later during a test, the search query produces the same number of items as were identified
332
during script recording. To do this, highlight text on the host screen that indicates the number of search items that were returned (for example, ITEMS 1-4 OF 101). 3 Right-click the highlighted text and select Verify Selected Text.
On the Insert Verification Function dialog box, leave the settings as they are and and click OK. Click OK on the following dialog box to confirm insertion of the verification function.
For detailed information about verification and parsing functions, refer to the TrueLog Explorer Help.
Analyzing the Script

At this point you should close TrueLog Explorer and take a look at the modified script in SilkPerformer. Some of the more interesting functions to consider are: WebTcpipScreenRecvPacketsUntilCursor: This function receives packets from a Telnet server until cursor is detected at a specified position. This function is used for synchronizing replay and the actual Telnet server response. WebTcpipSend: This function sends a string to the remote host.
333
13 LOAD TESTING VT 100+ APPLICATIONS Tutorial 3: Replaying the Customized Script
WebTelnetTypeKeys: This function simulates a user input to a Telnet server. This function sends alphanumeric character data that is specified at a specific rate and optionally verifies data echoed by the server. WebTelnetScreenVerifyText: This function was inserted into the script via the content verification you created in TrueLog Explorer. It verifies rendered screen content in an active Telnet connection. WebTcpipRecvClose: This function retrieves data from the remote host until the connection is closed by the server. SilkPerformer automatically inserts this function at the end of a transaction to synchronize script replay with the actual termination of the connection.
In Tutorial 2, you learned how to: Insert a timer to measure response times Verify host screen content during replay Work with some common Telnet BDL functions
Tutorial 3: Replaying the Customized Script

Once you have created a test script by recording function calls that the client application performs and then customized the script, you can load test your server by replaying the script. To run a load test, you must perform the following steps: Find the test baseline
Synchronization issues
Confirm the test baseline Define the workload model Execute the test
In some cases, synchronization between replay and a host application may fail. Refer to SilkPerformers Online Help for detailed information about scripting manual synchronization functions.
334
A
A
Setup and Configuration
This appendix comprises information and step-by-step instructions on how to set up and configure the sample applications that are used in the tutorials. This chapter contains the following sections:
Section Page
Setting up the Person1 application Setting up the PersonPB application
336 338
Setting up the SilkCentral Performance Manager WAP sample application340
For Load Testing a CORBA Application, the Bank application is one of the automatically installed samples that accompany VisiBroker. To set up VisiBroker, follow the setup instructions given in the VisiBroker documentation. For Load Testing a TUXEDO Application, the Bank application is one of the automatically installed samples that accompany BEA TUXEDO. To set up the BEA TUXEDO System follow the setup instructions given in the TUXEDO documentation. For Load Testing a Jolt Application, follow the setup instructions given in the TUXEDO and Jolt documentation.
335
A SETUP AND CONFIGURATION Setting up the Person1 application
Setting up the Person1 application

This section provides step-by-step guidance through the configuration of the database sample application, Person1. You need this application to perform the steps described in the tutorials in Load Testing a Database through ODBC. As your database you will use the Microsoft Data Engine (MSDE). This is a client/server data engine that provides local data storage on a smaller computer system (such as a single-user computer or small workgroup server) and is compatible with Microsoft SQL Server 2000.
Installing a database
You can download MSDE from http://www.microsoft.com/downloads/. After completing the download, follow the instructions of the setup wizard. After you have installed your database server, you need to set up an ODBC data source on your SilkPerformer controller computer. The data source stores information about the database server and makes this information available to applications.
Setting up a data source
Procedure To set up an ODBC data source: 1 On your SilkPerformer controller computer, select Settings/Control Panel/ODBC Data Sources from the Windows Start menu. The ODBC Data Source Administrator dialog box opens at the User DSN tab. 2 Click the System DSN tab. You see the following dialog box.
Click Add.
336
A SETUP AND CONFIGURATION Setting up the Person1 application
The Create New Data Source dialog box opens. 4 5 In the list, select the SQL Server option. Click Finish. The Create a New Data Source to SQL Server dialog box opens.
6 7 8
In the Name text box, enter Person1. This is the name by which the ODBC data source will be identified. In the Server text box, enter the host name or IP address of the computer on which you have installed MSDE. Click Next. You see the following dialog box.
Select the With SQL Server authentication using a login ID and password entered by the user option.
10 Click Next.
337
A SETUP AND CONFIGURATION Setting up the PersonPB application
11 In all remaining dialog boxes, just retain the default settings and click the appropriate button to proceed (OK, Next, or Finish). The new data source is added to the list in the System DSN tab of the ODBC Data Source Administrator dialog box. 12 In the ODBC Data Source Administrator dialog box, click OK. The Person1 application is now configured properly. When you start the application, enter the following data in the Login dialog box.
Field Value
Data source user name password
Person1 repuser repuser
Setting up the PersonPB application

This section provides step-by-step guidance through the configuration of the sample Oracle database application called PersonPB. You need this application to perform the steps described in the tutorials in Load Testing an Oracle OCI7 Database.
Installing Oracle
Procedure To install the Oracle software: 1 On the computer that you want to use as your sever, install the Oracle server software. Refer to the Oracle documentation for a detailed description of the setup process. 2 On your SilkPerformer controller computer, install the Oracle client software. Refer to the Oracle documentation for a detailed description of the setup process. After you have installed the Oracle server and client software, you need to set up a database alias on your SilkPerformer controller computer. The alias stores information about the database server and makes this information available to applications.
Setting up an alias
Procedure To set up a database alias: 1 On your SilkPerformer controller computer, select Programs/Oracle/ SQL Net Easy Configuration from the Windows Start menu.
338
A SETUP AND CONFIGURATION Setting up the PersonPB application
The SQL *Net Easy Configuration dialog box opens.
2 3
Select the Add Database Alias option. Click OK. The Choose Database Alias dialog box opens.
4 5
In the Database Alias text box, enter PersonPB. This is the name by which the alias will be identified. Click OK. The Choose TCP/IP Host Name and Database Instance dialog box opens.
In the TCP/IP Host Name edit text box, enter the host name or IP address of the computer on which you have installed the Oracle server software. In the Database Instance text box, retain the default entry ORCL.
339
A SETUP AND CONFIGURATION Setting up the SilkCentral Performance Manager WAP sample application
Click OK. The Confirm Adding Database Alias dialog box opens.
Double-check the information you have entered. If you want to change any of the settings, click Back.
10 Click Yes. 11 In the SQL *Net Easy Configuration dialog box, click Cancel. The PersonPB application is now configured properly. When you start the application, enter the following data in the Login dialog box.
Field Value
Alias user name password
PersonPB scott tiger
The user scott with the password tiger is set up by default by the Oracle software.
Setting up the SilkCentral Performance Manager WAP sample application

This section provides step-by-step guidance through the installation of the sample WAP application, called SilkCentral Performance Manager performance monitoring. You need this application to perform the steps described in the tutorials in Load Testing a WAP Application. Note This description explains how to set up and publish the WAP application to Microsofts Internet Information Server 5.0 (MS IIS). If you are using a different Web server, the installation procedure
340
will differ slightly, but the principles are basically the same. See the appropriate sections of your Web server administration guide on how to publish a Web application to your server. Procedure To set up the SilkCentral Performance Manager application on the Web server. 1 Start the IIS Internet Services Manager. The Internet Services Manager welcomes you with the Microsoft Internet Information Services Manager window. All the Web-services installed on your computer and their operational states are shown. Depending on the configuration of MS IIS, additional computers within your network and their services may also be shown in the window.
2 3
Select Default Web Site. From the menu bar, select Action/New/Virtual directory. The Virtual Directory Creation Wizard dialog box opens and guides you through the process.
4 5 6
Click Next. The wizard asks you to name the alias for the virtual directory. Enter WAP and click Next. To enter the path to the directory where the content of the sample application is stored click Browse... and navigate to the directory \SampleApps\WAP\ within your SilkPerformer installation directory. Click Next.
341
8 9
Select the access permissions as shown in the screenshot above. Click Next. Now you have to add some new file types to enable the Internet Information Server to handle the requests properly.
10 In the ensuing dialog box, click Finish.
11 Select the new virtual directory (WAP). 12 From the menu bar, select Action/Properties. 13 Click the HTTP Headers tab. 14 Click the File Types... button. 15 Enter the following file types by clicking New Type.... You have to enter all types separately.
.wbmp .wml .wmlc .wmls .wmlsc image/vnd.wap.wbmp text/vnd.wap.wml application/vnd.wap.wmlc text/vnd.wap.wmlscript application/vnd.wap.wmlscriptc
342
The File Types dialog box should now look like the following.
16 Click OK to continue. 17 In the ensuing dialog box, click OK to close the Properties dialog box. 18 Close the Internet Information Services Manager.
Problems when accessing the WAP sample application
Possible problem that can occur when trying to access the WAP sample application: If you are not able to connect to the sample application with your WAP browser (for example, Nokia WAP toolkit) you should stop and then restart the WWW service on your computer. This can also be done with the Internet Information Services Manager.
343
344

Silkperformer 2010: Tutorials

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Silkperformer 2010: Tutorials

Uploaded by

Copyright:

Available Formats

Tutorials

Chapter 5 Load Testing a CORBA Application

Chapter 6 Load Testing a TUXEDO Application

Chapter 3 Load Testing an Oracle OCI7 Database 41

Chapter 7 Load Testing a Jolt Application 183

Chapter 4 Load Testing an Oracle OCI8 Database 81

Chapter 8 Load Testing a COM Application 215

Chapter 9 Load Testing an ADO Application

Appendix A Setup and Configuration 245

Chapter 10 Load Testing a WAP Application 273

Chapter 11 Load Testing a Jacada Application

Chapter 12 Load Testing IBM Mainframe Applications 311

Chapter 13 Load Testing VT 100+ Applications

What you will learn

Overview Workflow Bar Where to Go Multi-Protocol Recording

INTRODUCTION Multi-Protocol Recording

INTRODUCTION Multi-Protocol Recording

Load Testing a Web Application

1 LOAD TESTING A WEB APPLICATION

Load Testing a Database through ODBC

Introduction What you will learn

Tutorial 1: Running a predefined test

Creating a load-testing project

2 LOAD TESTING A DATABASE THROUGH ODBC Tutorial 1: Running a predefined test

The Workflow Outline Project dialog box opens.

Adding a load-testing script

2 LOAD TESTING A DATABASE THROUGH ODBC Tutorial 1: Running a predefined test

The Workflow Model Script dialog box opens.

Configuring load test settings

2 LOAD TESTING A DATABASE THROUGH ODBC Tutorial 1: Running a predefined test

Executing the test script

2 LOAD TESTING A DATABASE THROUGH ODBC Tutorial 1: Running a predefined test

Tutorial 2: Creating a script with the Recorder

Setting up an application profile

The Application Profile dialog box opens.

Click OK to close the dialog box.

Modeling a test script

Modeling a test script

In the Recorder, create a new transaction called TSearch.

Trying out the generated test script

The Workflow Try Script dialog box opens.

Tutorial 3: Customizing the generated test script

Replacing constant values with random variables

The Workflow Customize Test dialog box opens.

The following dialog box opens.

Specifying which tasks each user will perform

Tutorial 4: Replaying the customized script

Finding the test baseline

Confirming the test baseline

Adjusting the workload

The Workflow - Select Workload Model dialog box opens.

Running the load test

Customizing server monitoring for your load test

The Profile Results dialog opens.

The Data Source Wizard opens.

m The Data Source Wizard opens again. n

What you have learned

In Tutorial 4, you learned how to:

Tutorial 5: Viewing the results of your load test

Overview report of performed measurements

The Workflow - Explore Results dialog opens.

Detailed response time measurements