Neoload Manual Document

NeoLoad® Documentation
3.1
NeoLoad® Documentation: 3.1
Published 25 October 2010
Copyright © 2005, 2010 Neotys.
All right reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical,
photocopying, recording, or otherwise, without written permission from the publisher and the copyright holder.
Table of Contents
I. Getting Started ................................................................................................................ 1
1. Overview ............................................................................................................... 3
Welcome to NeoLoad Help .................................................................................. 3
Contents .................................................................................................... 3
Formats .................................................................................................... 3
Legal Issues ............................................................................................... 3
About Load Testing ............................................................................................ 3
Why Load Test Web Applications ? ............................................................... 3
Load Testing with NeoLoad ......................................................................... 4
2. Installation ............................................................................................................. 5
Requirements ..................................................................................................... 5
Operating System ....................................................................................... 5
Disk Space ................................................................................................ 5
CPU & Memory ......................................................................................... 5
Installation ........................................................................................................ 5
Installing the Controller ............................................................................... 5
Installing a Load Generator .......................................................................... 6
License Key Management .................................................................................... 7
The Standard Key ....................................................................................... 7
The Floating Key ...................................................................................... 10
Changing Mode ........................................................................................ 12
Running NeoLoad ............................................................................................. 12
Running the Controller .............................................................................. 12
Launching the Load Generator Agent ........................................................... 14
Stopping the Agent ................................................................................... 14
Files ............................................................................................................... 15
The Installation Directory ........................................................................... 15
The User Directory ................................................................................... 15
Project Directory ...................................................................................... 16
Log Files ................................................................................................. 17
Advanced Installation ........................................................................................ 17
Using a Firewall Between the Controller and Load Generator ............................ 17
Increasing Available Memory for Load Generators .......................................... 18
Increasing Available Memory for the Controller ............................................. 18
3. Quick Start .......................................................................................................... 20
Recording the Test Scenario ............................................................................... 20
Running the Test .............................................................................................. 24
Test Results ..................................................................................................... 25
To Learn More ................................................................................................. 28
II. Reference Guide ........................................................................................................... 29
4. Menus ................................................................................................................. 34
5. Preferences ........................................................................................................... 37
Global Preferences ............................................................................................ 37
HTTP Recorder Settings ............................................................................ 37
Proxy Settings .......................................................................................... 38
Browser Settings ....................................................................................... 39
Skins ...................................................................................................... 40
Graphs .................................................................................................... 41
Frameworks ............................................................................................. 43
License ................................................................................................... 44
Oracle Forms ........................................................................................... 44
iii
Adobe Flex/AMF ...................................................................................... 46

Advanced Parameters ................................................................................ 47
Project Preferences ............................................................................................ 48
Page Naming Policy .................................................................................. 48
SSL Client Certificates .............................................................................. 49
Runtime .................................................................................................. 51
Oracle Forms ........................................................................................... 53
Libraries Manager ..................................................................................... 54
CA Application Performance Management .................................................... 59
dynaTrace ................................................................................................ 64
6. Design ................................................................................................................. 67
Recording a Test Scenario .................................................................................. 67
Recording HTTP Applications ..................................................................... 67
Recording Adobe RTMP Applications .......................................................... 68
Starting Recording .................................................................................... 69
Creating a Virtual User Profile .................................................................... 69
The Recording Bar .................................................................................... 70
Post-Recording Wizard .............................................................................. 71
Troubleshooting ........................................................................................ 81
Servers ............................................................................................................ 81
Authentication .................................................................................................. 82
Supported authentication mechanisms ........................................................... 82
The Negotiate scheme with SPNEGO and Kerberos ................................. 83
Scheme priority order ................................................................................ 83
Virtual Users .................................................................................................... 83
Creating a Virtual User .............................................................................. 84
Virtual User Runtime Settings ..................................................................... 84
Customizing a Virtual User ........................................................................ 85
Checking a Virtual User ............................................................................. 88
Web pages ....................................................................................................... 94
Requests .......................................................................................................... 95
HTTP Requests ........................................................................................ 95
SOAP requests ........................................................................................ 111
Oracle Forms Requests ............................................................................. 119
Adobe Flex/AMF requests ........................................................................ 128
Adobe RTMP Requests ............................................................................ 138
Google Web Toolkit requests .................................................................... 148
Java Serialization Requests ....................................................................... 156
Polling Requests ..................................................................................... 165
Streaming Requests ................................................................................. 168
Push Messages ........................................................................................ 172
Validation .............................................................................................. 178
Variable Extractors .................................................................................. 179
Advanced Parameters ............................................................................... 185
Shortcuts ................................................................................................ 186
Logical Actions .............................................................................................. 187
Delay .................................................................................................... 187
Loop ..................................................................................................... 187
While .................................................................................................... 188
If ... Then ... Else .................................................................................... 189
Variable Modifier .................................................................................... 190
Containers .............................................................................................. 190
Random Containers ................................................................................. 191
Try ... Catch ........................................................................................... 192
iv
Stop Virtual User .................................................................................... 192

Fork ...................................................................................................... 192
Wait Until .............................................................................................. 193
JavaScript .............................................................................................. 194
Rendezvous ............................................................................................ 200
Frameworks ................................................................................................... 204
Concept ................................................................................................. 204
Framework Dynamic Parameter Handling .................................................... 204
Generic Dynamic Parameter Handling ......................................................... 209
Searching for Dynamic Parameters in NeoLoad ............................................ 211
Push Frameworks ............................................................................................ 212
Context .................................................................................................. 212
Definition .............................................................................................. 212
Modified Virtual Users ............................................................................. 213
Frameworks ........................................................................................... 214
Shared Containers ........................................................................................... 226
Sharing a Container ................................................................................. 227
Using a Shared Container ......................................................................... 227
Actions on Shared Containers .................................................................... 228
Populations .................................................................................................... 228
Percentage ............................................................................................. 229
Bandwidth ............................................................................................. 229
Browser ................................................................................................. 229
Use cookies ............................................................................................ 229
Connection ............................................................................................. 229
Cache management .................................................................................. 229
Variables ....................................................................................................... 229
Creating a Variable ................................................................................. 230
The Variable Extractor ............................................................................. 232
Testing a Variable ................................................................................... 232
Using Variables ...................................................................................... 232
Search and Replace ......................................................................................... 233
Overview ............................................................................................... 233
Search Criteria ........................................................................................ 233
Replacements ......................................................................................... 249
Flags ............................................................................................................. 249
Flagging Criteria ..................................................................................... 250
Scope .................................................................................................... 251
Importing and exporting a project ...................................................................... 251
Importing a project .................................................................................. 251
Exporting a Project .................................................................................. 252
7. Monitors ............................................................................................................ 255
Overview ....................................................................................................... 255
Presentation ............................................................................................ 255
Creating and Configuring a Monitored Machine ............................................ 256
Creating and Configuring a Monitor ........................................................... 258
Creating and Configuring a Counter or an Indicator ....................................... 260
Setting and Configuring a Counter Alert Threshold ........................................ 262
Operating Systems ........................................................................................... 265
Linux Monitor ........................................................................................ 265
Solaris Monitor ....................................................................................... 269
AIX Monitor .......................................................................................... 273
HP-UX Monitor ...................................................................................... 277
Microsoft Monitors .................................................................................. 280
v
Microsoft Windows Monitor ..................................................................... 281

Network ........................................................................................................ 283
RSTAT Monitor ...................................................................................... 283
SNMP Monitor ....................................................................................... 285
Databases ....................................................................................................... 287
Oracle DB monitor .................................................................................. 287
Microsoft SQL Server Monitor .................................................................. 294
MySQL Monitor ..................................................................................... 296
DB2 Monitor .......................................................................................... 302
PostgreSQL Monitor ................................................................................ 308
Web/EJB Tier ................................................................................................. 311
Microsoft IIS Monitor .............................................................................. 311
Apache Monitor ...................................................................................... 312
Microsoft .Net Monitor ............................................................................. 314
WebLogic 8 Monitor ............................................................................... 316
WebLogic 9/10 Monitor ........................................................................... 323
WebSphere Monitor ................................................................................. 331
JBoss Monitor ........................................................................................ 335
Tomcat 5.5/6.0 Monitor ............................................................................ 341
Oracle Application Server 9.X-10.X Monitor ................................................ 346
Oracle Application Server 10.1.3 Monitor .................................................... 348
JOnAS Monitor ...................................................................................... 353
GlassFish Monitor ................................................................................... 359
SAP NetWeaver Monitor 7.0 ..................................................................... 367
SAP NetWeaver Monitor 7.1 ..................................................................... 374
LiveCycle Data Services Monitor ............................................................... 381
8. Runtime ............................................................................................................. 387
Test Settings .................................................................................................. 387
Scenarios ............................................................................................... 387
Duration Policy ....................................................................................... 388
Load Policy ............................................................................................ 388
Load Generator Hosts .............................................................................. 389
Population Advanced Settings ................................................................... 393
Scenario Advanced Settings ...................................................................... 394
Runtime supervision ........................................................................................ 397
Starting the Test ..................................................................................... 398
Stopping the Test .................................................................................... 399
Runtime Overview .................................................................................. 399
Real-Time Graphs ................................................................................... 401
Real-Time Errors .................................................................................... 403
Real-Time Alerts ..................................................................................... 405
Viewing Virtual Users in Real Time ........................................................... 406
9. Results ............................................................................................................... 408
General Information ......................................................................................... 408
Selecting a Test ...................................................................................... 408
Deleting a Test ....................................................................................... 408
Filtering by Load Generator, Population or Virtual User ................................. 408
Virtual User, Container, Web Page and HTTP Request Statistics ...................... 408
Push Message Statistics ............................................................................ 409
The Results Manager ....................................................................................... 409
Select .................................................................................................... 410
Compare ................................................................................................ 410
Filtering ................................................................................................. 410
Test folder ............................................................................................. 410
vi
Generating a Report ................................................................................. 410

Deleting a Test ....................................................................................... 410
Test Summary ................................................................................................ 411
Selecting a Summary ............................................................................... 411
Content .................................................................................................. 411
Graphs .......................................................................................................... 414
Working with Graphs ............................................................................... 415
Graph Features ....................................................................................... 417
Features Specific to the Results Section ....................................................... 418
Values ........................................................................................................... 422
Element Types ........................................................................................ 423
Results Table .......................................................................................... 423
Plotting Curves ....................................................................................... 424
Indicators ............................................................................................... 424
Exporting Data ....................................................................................... 425
Errors ............................................................................................................ 425
General Information ................................................................................. 426
Detailed Error Information ........................................................................ 426
Selected Error Details .............................................................................. 426
Previous Request ..................................................................................... 427
Alerts ............................................................................................................ 427
General Information ................................................................................. 427
Alert Information .................................................................................... 428
Alert Graphs .......................................................................................... 428
Debug ........................................................................................................... 429
General User Runtime Information ............................................................. 429
Validating a User's Runtime ...................................................................... 429
Reports .......................................................................................................... 430
The Report Wizard .................................................................................. 430
Report Type ........................................................................................... 430
Report Contents ...................................................................................... 431
Output Options ....................................................................................... 432
Test Results Comparison .................................................................................. 433
Comparing Results in the GUI ................................................................... 433
Generating a Comparison Report ............................................................... 434
Test Result Filters ........................................................................................... 435
Filtering in the GUI ................................................................................. 435
Available Filters ...................................................................................... 435
Filtering Test Results ............................................................................... 437
Generating a Filtered Test Report ............................................................... 437
III. User guides ............................................................................................................... 438
10. Design User Guide ............................................................................................. 441
Key Steps ...................................................................................................... 441
To Learn More ............................................................................................... 444
11. Oracle Forms User Guide .................................................................................... 445
Overview ....................................................................................................... 445
Prerequisites ........................................................................................... 445
Configuring NeoLoad .............................................................................. 445
Configuring the Oracle Forms Server .......................................................... 445
Examples of Recordings ................................................................................... 445
Preview ................................................................................................. 445
Message Object ...................................................................................... 446
Message Structure ................................................................................... 446
Request Naming ...................................................................................... 447
vii
Advanced Configuration ................................................................................... 448

General Settings ...................................................................................... 448
Project Settings ....................................................................................... 448
Advanced Design ............................................................................................ 449
Understanding the Context ........................................................................ 449
A Component's Life cycle ......................................................................... 449
Correlating Dynamic Component Names ..................................................... 450
Limitations ............................................................................................. 451
Best Practices ................................................................................................. 451
Design ................................................................................................... 452
Validation .............................................................................................. 452
Runtime ................................................................................................. 452
Troubleshooting .............................................................................................. 452
Design ................................................................................................... 452
Runtime ................................................................................................. 456
12. Best Practices .................................................................................................... 462
Defining Objectives ......................................................................................... 462
Types of objective ................................................................................... 462
Defining criteria for success or failure ......................................................... 462
Producing a Realistic Test ................................................................................ 463
Defining the number of Virtual Users. ........................................................ 463
Defining several types of Virtual Users ....................................................... 463
Using different user accounts and values ..................................................... 463
Testing load balancers .............................................................................. 463
Simulating actual user bandwidth ............................................................... 464
Tips ...................................................................................................... 464
Making your Results Talk ................................................................................ 464
Producing informative results .................................................................... 464
Using results .......................................................................................... 465
13. Heavy Load Testing Guide .................................................................................. 467
Introduction .................................................................................................... 467
NeoLoad Scenarios .......................................................................................... 467
Minimize the Number of Validations .......................................................... 467
Avoid Validations and Extractions on Bulky Inputs ....................................... 467
Optimize Regular Expressions ................................................................... 468
Optimize Extractions from XML Responses ................................................. 468
Avoid Multiplication of Virtual Users ......................................................... 468
Minimize the Use of JavaScript Actions ...................................................... 469
NeoLoad Controller ......................................................................................... 469
Launch Scenarios with a Fixed Duration ..................................................... 469
Monitor Using a Top-down Approach ......................................................... 469
Avoid Debug Mode ................................................................................. 469
Warm Up Your Application Server ............................................................ 469
Plan for Large Amounts of Memory for the NeoLoad Controller ...................... 469
Reduce Error Management ........................................................................ 470
Save your Projects Locally ....................................................................... 470
Adapt the Controller/Load Generator Time Limit to Your Specific Project
Requirements .......................................................................................... 470
NeoLoad Load Generators ................................................................................ 470
Allocate Sufficient Memory to the Machines Hosting Controllers and Load
Generators ............................................................................................. 470
Make Sure the Machines Running the Generators are Adequately Dimensioned
............................................................................................................. 471
Caution when using virtual environments .................................................... 471
viii
Network Tuning and Configuration .................................................................... 471

Increase the Number of Simultaneously Opened Sockets ................................. 472
Use Several Network Cards for Load Generators ........................................... 472
Distribute NeoLoad Communication Channels Over Different Networks ............ 472
Prefer a "Server" Tagged Operating System for your Application Servers ........... 472
IV. Tutorials, F.A.Q and Troubleshooting Guide ................................................................... 473
14. F.A.Q .............................................................................................................. 475
General .......................................................................................................... 475
Design ........................................................................................................... 479
Runtime ......................................................................................................... 482
Analysis ........................................................................................................ 485
Errors ............................................................................................................ 485
15. Troubleshooting Guide ........................................................................................ 487
16. Tutorials ........................................................................................................... 490
Introduction .................................................................................................... 490
Design - General ............................................................................................. 490
Creating Business Transactions .................................................................. 490
Logging in With Multiple Accounts Using a CSV File ................................... 496
Creating Realistic Populations ................................................................... 513
Validating a Server Response .................................................................... 514
Executing Java Code ............................................................................... 522
Design - Dynamic Parameters ........................................................................... 526
Choosing a Data Extraction Method ........................................................... 526
Handling an Application's Dynamic Parameters ............................................ 528
Creating a Variable Extractor .................................................................... 544
Submit a Form from the Previous Request ................................................... 557
Follow a link from the previous request ...................................................... 563
Using Framework Parameters to Automatically Search for Dynamic Parameters
............................................................................................................. 570
Design - Technologies ..................................................................................... 576
SOAP: Testing Web Services .................................................................... 576
Adobe Flex/AMF: Handling External Libraries ............................................. 601
Adobe Flex/AMF: Handling Polling and Streaming ....................................... 607
Adobe RTMP : Handling External Libraries ................................................. 623
Google Web Toolkit: Managing External Libraries ........................................ 628
Java Serialization: Handling External Libraries ............................................. 634
Oracle Forms: Designing a Scenario with Iterations ....................................... 639
Analysis ........................................................................................................ 648
Analyzing Errors in the Errors Panel ........................................................... 648
Comparing Several Test Results ................................................................. 656
Miscellaneous Items ........................................................................................ 657
Monitoring an Application Server or Database .............................................. 657
Using Additional Load Generators ............................................................. 662
Scheduling a Test .................................................................................... 666
V. Appendix ................................................................................................................... 668
A. Regular Expressions ............................................................................................ 672
Overview ....................................................................................................... 672
Introduction ............................................................................................ 672
Using regular expressions ......................................................................... 672
Quick Reference ............................................................................................. 672
Special character definitions ...................................................................... 672
Character classes ..................................................................................... 673
Pre-defined character classes ..................................................................... 673
Examples ....................................................................................................... 673
ix
Extracting a URL parameter value .............................................................. 673

Extracting a Form Parameter Value ............................................................ 674
Extracting HTTP headers .......................................................................... 676
Extracting miscellaneous values ................................................................. 676
Common Errors & Tips .................................................................................... 676
Use of the question mark '?' ...................................................................... 676
Brackets ................................................................................................ 677
Spaces ................................................................................................... 677
Multi-Line ............................................................................................. 677
Links to Regex Resources ................................................................................ 677
Links to Regex Testers .................................................................................... 677
B. Status Code Definitions ........................................................................................ 678
Informational 1xx ............................................................................................ 678
100 Continue .......................................................................................... 678
101 Switching Protocols ........................................................................... 678
Successful 2xx ................................................................................................ 678
200 OK ................................................................................................. 678
201 Created ............................................................................................ 679
202 Accepted ......................................................................................... 679
203 Non-Authoritative Information ............................................................. 679
204 No Content ...................................................................................... 679
205 Reset Content ................................................................................... 680
206 Partial Content .................................................................................. 680
Redirection 3xx .............................................................................................. 680
300 Multiple Choices ............................................................................... 681
301 Moved Permanently ........................................................................... 681
302 Found ............................................................................................. 681
303 See Other ........................................................................................ 682
304 Not Modified ................................................................................... 682
305 Use Proxy ........................................................................................ 682
306 (Unused) .......................................................................................... 683
307 Temporary Redirect ........................................................................... 683
Client Error 4xx .............................................................................................. 683
400 Bad Request ..................................................................................... 683
401 Unauthorized .................................................................................... 683
402 Payment Required ............................................................................. 683
403 Forbidden ........................................................................................ 684
404 Not Found ....................................................................................... 684
405 Method Not Allowed ......................................................................... 684
406 Not Acceptable ................................................................................. 684
407 Proxy Authentication Required ............................................................ 684
408 Request Timeout ............................................................................... 684
409 Conflict ........................................................................................... 685
410 Gone ............................................................................................... 685
411 Length Required ............................................................................... 685
412 Precondition Failed ............................................................................ 685
413 Request Entity Too Large ................................................................... 685
414 Request-URI Too Long ...................................................................... 685
415 Unsupported Media Type ................................................................... 686
416 Requested Range Not Satisfiable .......................................................... 686
417 Expectation Failed ............................................................................. 686
Server Error 5xx ............................................................................................. 686
500 Internal Server Error .......................................................................... 686
501 Not Implemented .............................................................................. 686
x
502 Bad Gateway .................................................................................... 686

503 Service Unavailable ........................................................................... 687
504 Gateway Timeout .............................................................................. 687
505 HTTP Version Not Supported .............................................................. 687
C. NeoLoad Status Codes ......................................................................................... 688
D. NeoLoad Javascript API ....................................................................................... 693
Class Logger .................................................................................................. 693
Synopsis ................................................................................................ 693
debug(String) .......................................................................................... 694
error(String) ........................................................................................... 694
fatal(String) ............................................................................................ 694
info(String) ............................................................................................ 694
isDebugEnabled() .................................................................................... 695
isErrorEnabled() ...................................................................................... 695
isFatalEnabled() ...................................................................................... 695
isInfoEnabled() ....................................................................................... 696
isWarnEnabled() ..................................................................................... 696
warn(String) ........................................................................................... 696
Class RendezvousManager ................................................................................ 696
Synopsis ................................................................................................ 697
hasRendezvous(String) ............................................................................. 697
isEnabled(String) ..................................................................................... 698
setEnabled(String, Boolean) ...................................................................... 698
unblock(String) ....................................................................................... 699
unblock(String, int) .................................................................................. 699
unblockAll() ........................................................................................... 699
Class RuntimeContext ...................................................................................... 699
Synopsis ................................................................................................ 700
currentVU .............................................................................................. 700
variableManager ...................................................................................... 700
fail() ..................................................................................................... 700
fail(String) ............................................................................................. 701
fail(String, String) ................................................................................... 701
Class VariableManager ..................................................................................... 701
Synopsis ................................................................................................ 701
changeValue(String) ................................................................................ 702
getValue(String) ...................................................................................... 702
parseString(String) ................................................................................... 703
setValue(String, String) ............................................................................ 703
Class VirtualUser ............................................................................................ 703
Synopsis ................................................................................................ 703
id ......................................................................................................... 704
name ..................................................................................................... 704
get(Object) ............................................................................................. 704
put(Object, Object) .................................................................................. 704
remove(Object) ....................................................................................... 705
setCookieForServer(String, String) ............................................................. 705
stop() .................................................................................................... 706
Glossary ........................................................................................................................ 707
Index ............................................................................................................................ 711
xi
List of Examples
5.1. Apache-Tomcat server on Windows : ............................................................................. 59
5.2. Apache-Tomcat server on Windows : ............................................................................. 60
7.1. Oracle JDBC URL: ................................................................................................... 287
7.2. MySQL JDBC URL: ................................................................................................. 296
7.3. DB2 JDBC URL: ...................................................................................................... 303
7.4. PostgreSQL JDBC URL: ............................................................................................ 308
16.1. Example of load balancing according to load factor ....................................................... 666
xii
Part I. Getting Started
Table of Contents
1. Overview ....................................................................................................................... 3
Welcome to NeoLoad Help .......................................................................................... 3
Contents ............................................................................................................ 3
Formats ............................................................................................................ 3
Legal Issues ...................................................................................................... 3
About Load Testing .................................................................................................... 3
Why Load Test Web Applications ? ....................................................................... 3
Load Testing with NeoLoad ................................................................................. 4
2. Installation ..................................................................................................................... 5
Requirements ............................................................................................................. 5
Operating System ............................................................................................... 5
Disk Space ........................................................................................................ 5
CPU & Memory ................................................................................................. 5
Installation ................................................................................................................ 5
Installing the Controller ....................................................................................... 5
Installing a Load Generator .................................................................................. 6
License Key Management ............................................................................................ 7
The Standard Key ............................................................................................... 7
The Floating Key .............................................................................................. 10
Changing Mode ................................................................................................ 12
Running NeoLoad ..................................................................................................... 12
Running the Controller ...................................................................................... 12
Launching the Load Generator Agent ................................................................... 14
Stopping the Agent ........................................................................................... 14
Files ....................................................................................................................... 15
The Installation Directory ................................................................................... 15
The User Directory ........................................................................................... 15
Project Directory .............................................................................................. 16
Log Files ......................................................................................................... 17
Advanced Installation ................................................................................................ 17
Using a Firewall Between the Controller and Load Generator .................................... 17
Increasing Available Memory for Load Generators ................................................. 18
Increasing Available Memory for the Controller ..................................................... 18
3. Quick Start .................................................................................................................. 20
Recording the Test Scenario ....................................................................................... 20
Running the Test ...................................................................................................... 24
Test Results ............................................................................................................. 25
To Learn More ......................................................................................................... 28
2
Chapter 1. Overview
Welcome to NeoLoad Help
NeoLoad is a load testing tool providing an easy and efficient way to test web applications such as intranets
or websites.
Contents
This documentation contains:
• an Introduction to load testing,

• an Installation Guide,
• a Quick Start Guide to run your first load test,
• a Reference Guide to obtain further details,
• a Best Practices Guide,
• an F.A.Q,
• Tutorials,
• a Troubleshooting Guide with solutions to common problems
• a Glossary.
When using NeoLoad, press (F1) at any time to obtain context-sensitive help.
Thank you for choosing NeoLoad.
Any comments, feedback or suggestions are welcome, either by mail to <feedback@neotys.com>.
Formats
The NeoLoad documentation is available on the Neotys website in several formats (PDF, HTML, ...).
http://www.neotys.com/support/documentation.html
Legal Issues
Third party software license terms can be found in the /legal sub-directory of the NeoLoad installation
directory.
This software includes software libraries developed by the Apache Software Foundation (http://
www.apache.org).
This software includes software libraries developed by L2FProd.com (http://www.L2FProd.com/).
This product includes software developed by the Indiana University Extreme! Lab (http://
www.extreme.indiana.edu/).
About Load Testing

Why Load Test Web Applications ?
Load testing is necessary to:
3
Overview
• test a web site's vulnerability to crashing under load.

• check response times under the predicted load.
• determine the number of simultaneous users supported by the application.
• define hardware and bandwidth requirements.
Load Testing with NeoLoad

1. Recording HTTP traffic between browser and server
NeoLoad includes a proxy server that records all server requests and responses.
2. Defining test parameters
Define virtual user behavior and set scenario parameters such as load policy (constant, ramp-up, peak
or custom) or the number of virtual users to be simulated in the test.
Set performance monitors (CPU, memory, disk usage,...) for your servers.
3. Running the test
Monitor the ongoing test with the aid of real-time graphs and stats.
4. Analyzing the results
Obtain a summary of the test and then examine its details using the graphs and statistical tables.
NeoLoad records and replays browser requests to the server, which means that NeoLoad:
• can simulate requests made by components such as plug-ins, Java applets, ActiveX, Flash
animations,...
• cannot simulate local actions such as updating a graphical component using client-side JavaScript.
To run your first test, please refer to the Quick Start guide.
4
Chapter 2. Installation
Requirements
Operating System
This software supports the following operating systems:
• Windows NT, Windows 2000, Windows 2003, Windows 2008, Windows XP, Windows Vista,
Windows 7.
• Linux x86 (kernel 2.6) - tested on Red Hat 9 and Mandriva 10.
• Solaris SPARC (8+). System patches may be required. See the "System Requirements" section in http://
java.sun.com/javase/6/webnotes/install/jre/install-solaris.html.
NeoLoad is written in Java and should run on any platform supporting Java 6:
Procedure 2.1. Installing NeoLoad on an unsupported Unix platform:

1. Follow the installation instructions for the command-line version for Linux or Solaris.
2. Replace the bundled JRE (<install_dir>/jre) with a Java interpreter (JRE) from a Java SE
Development Kit (JDK) compatible with the platform used (Java 6 required). To do this, install a
JDK 1.6 on your platform, then copy the <jdk install_dir>/jre directory into the NeoLoad
installation directory.
Disk Space
The controller and load generator require 230 Mb disk space each for installation.
CPU & Memory

Hardware requirements differ widely from one test to another. The greater the stress placed on the
web server, the greater the demand placed on hardware resources by the load generator. Furthermore,
requirements increase with the complexity of the scenario. Additional load generators may be used to
further increase the load.
During the test, the load generator's CPU and memory usage is monitored in the Runtime screen. If the
CPU or memory usage level regularly exceeds 90%, either the number of virtual users must be reduced,
or the think time between pages increased. Alternatively, additional load generators may be used.
A minimum of 1024 Mb system memory is recommended.
As a guideline, the controller requires 75 Mb of memory to run a test involving 250 virtual users and with
a 3-second wait time between pages, when using its built-in load generator. A stand-alone load generator
requires 60 Mb of memory to run the same test.
Installation
Installing the Controller
The controller is used to:
5
Installation
• design scenarios using the GUI,

• manage the load generators during the test and collect test data, and
• analyze the test results.
Note
The controller has a built-in load generator.
Windows:
Run neoload_windows_<version>.exe
Unix (GUI installer):
Run ./neoload_<platform>_<version>.sh
Unix (command line):
Extract the compressed archive to the desired destination directory: tar -xzf
neoload_<platform>_<version>.tar.gz
Installer in console mode
If the installer is invoked with the -c argument, interaction with the user is
performed in the terminal from which the installer was invoked. For example: ./
neoload_linux_3_1_0.sh -c
Installing a Load Generator

The controller features a built-in load generator. Load generators may be installed on other machines to
further increase the loading.
Windows:
run loadGenerator_windows_<version>.exe
Unix (GUI installer):
run ./loadGenerator_<platform>_<version>.sh
Unix (command line):
Extract the compressed archive to the desired destination directory: tar -xzf
loadGenerator_<platform>_<version>.tar.gz
Install in console mode
If the installer is invoked with the -c argument, interaction with the user is
performed in the terminal from which the installer was invoked. For example: ./
loadGenerator_linux_3_1_0.sh -c
Warning
When the agent is installed using the root account under Unix, the agent is automatically
declared as a service on the system. The AgentService service is subsequently launched each
time the system is started.
6
Installation
Note
See the section called “Advanced Installation” for more information about firewall and memory
issues.
License Key Management

Neotys uses two types of license for its products:
• Standard license. Either permanent or temporary, this license is linked to a machine and cannot
easily be moved.
• Floating license. The floating license allows the product to be used on several machines, but not
simultaneously.
This license makes collaboration on a NeoLoad project much simpler. Using the NeoLoad controller
on several machines (consecutively) is very quick and easy.
Warning
The license key is stored in the user profile of the account used to launch NeoLoad. If several
users use different accounts on the same machine, the license must be activated for each of these
users. A floating license reserved by one user can only be released by that same user.
The Standard Key

Definition
Whether permanent or temporary, the standard license is linked to a single workstation and cannot easily
be moved.
7
Installation
Installing the license key
Procedure 2.2. Installing the standard license:

1. Open the license management panel via the "Help / License management..." menu item.
2. In the "License" section, select "Use a license file".
3. Click the "Enter a license key..." button.
The licenses, excepting those for trial versions, must be activated once the key has been installed. See the
section called “Activating the license key”.
Activating the license key

The installed license key must be activated before using NeoLoad. This procedure will link the key to a
unique machine. Once activated, the key may be transferred to another machine (see the section called
“Transferring the license key”).
Note
Keys for trial versions do not need activating.
8
Installation
After installation of the license key, and if that key requires activating, the Activation Wizard is displayed :
Note
The Activation Wizard also may be run via the "Help / License management..." menu
item and clicking the "Activate license" button.
There are two ways to activate the license:
• Activating on-line: NeoLoad connects to the Internet and automatically registers and activates your
license key.
• Activating by e-mail or web form:
1. NeoLoad generates a license activation request file named "license.req".
2. You will need to send this file to Neotys either using the web form, found at http://
www.neotys.com/support/licenseManagement.html , for an immediate activation, or by e-mail to
<activation@neotys.com>.
3. You will receive in return a file containing the license activated for the machine that issued the
request.
4. Once the activated license file has been received, run the Activation Wizard by selecting "Help /
License Management..." and "Activate license key...".
5. Select "Enter an activated license key".
6. Select the activated license file on your hard disk. The activated license is now installed.
9
Installation
Transferring the license key

The license may be transferred to a different machine. To do this, you first need to disable the license on
the machine on which it is currently enabled.
Once the key has been disabled, it can be re-enabled on the new machine.
The transfer procedure can take a few hours to be processed by Neotys.
Procedure 2.3. Transferring the license key
2. Click the "Transfer to another computer..." button.
3. NeoLoad generates a disable request file named "license-inactivation.req".
4. Send this file to Neotys by e-mail at <activation@neotys.com>.
5. You will receive a return e-mail from Neotys confirming that the key has been disabled for that
machine.
6. You may then use the license on another machine. See the section called “Installing the license key”.
Warning
Please transfer the license before uninstalling NeoLoad.
The Floating Key

Definition
The floating license allows the product to be used on several machines, but not simultaneously.
The license is reserved from a license server, the Neotys License Server. Once reserved by a user,
and until its release, the license is no longer available to other users.
Installing the floating key

The floating key must be installed on a license server, the Neotys License Server. The key cannot
be installed directly in NeoLoad.
Download Neotys License Server from the download page at: http://www.neotys.fr/support/
download.html.
10
Installation
Reserving a floating key
The procedure for reserving a license key from the license server is described below.
Procedure 2.4. Reserving a key
1. In NeoLoad, open the license management panel via the "Help / License management"
menu item.
2. In the "License configuration" section, select the "Connect to a license server"

option.
3. Check or enter the license server parameters. The default port is 7777.
4. Click on the "Get" button to display the list of licenses on the server.
5. Select the appropriate license, then click on the "Get" button.
6. Choose the reservation type :
• Per Session. NeoLoad automatically releases the key when the user quits the application.
11
Installation
Check "Automatically reserve the next time NeoLoad starts" to try to reserve
this same license each time NeoLoad starts. If the license is not available at start-up, another license
must be selected.
• Permanent. The user must deliberately release the license by clicking on the "Release..."
button in the license management panel, under Preferences.
Note
The list of licenses only contains the licenses compatible with the current version of NeoLoad.
Releasing a floating key

To deliberately release a key, thereby making it available to other users:
2. Click on the "Release..." button.
Changing Mode
Switching from a standard license to a floating license
Once a standard key has been installed and activated, it's possible to use a floating key reserved from the
license server.
In this case, there are two choices:
1. Either retain the key for later use, after returning to standard license mode, or
2. Transfer the key to another machine
Switching from a floating license to a standard license

After reserving a floating key, a standard key may be used from the hard disk.
In this case, there are two choices:
1. Either release the floating key, or
2. Retain the floating key for later use, upon returning to the license server-based mode.
Running NeoLoad
Running the Controller
Running the graphical interface
Windows: <install_dir>\bin\NeoLoadGUI.exe.
Unix: <install_dir>/bin/NeoLoadGUI.
12
Installation
Running from the command line

Windows: Use N<install_dir>\bin\NeoLoadCmd.exe for command line options.
Unix: Use <install_dir>/bin/NeoLoadCmd for command line options.
Command line options:
usage: neoload -project <file> -launch <scenario> [-options]

-launch <scenario> Starts the test with the specified scenario
from the project specified by -project <file>.
-description <description> Test description.
-exit In GUI mode, exit NeoLoad when the test has
finished.
-help Print this message
-inactivateKey Disable the NeoLoad License key for this computer.
-noGUI Launch NeoLoad in non GUI mode.
-project <file> Use given project file (*.nlp).
-report <file> Generates a test report at the end of the test.
NeoLoad configures the report format from the file
extension (.html, .pdf, .xml).
Note
Paths are relative to the NeoLoad directory.
Sample
neoloadCmd -project projects/jpetstore/jpetstore.nlp -launch scenario1

-noGUI -report projects/jpetstore/reports/report.xml
Using NeoLoad with ANT

Integrating NeoLoad with your ANT script is easy. Just use the NeoLoad task provided in
<install_dir>/lib/ant-neoload.jar. To make the NeoLoad task available to ANT, you
must first insert a taskdef element to tell ANT where to find the task definition. Here is an example
of using the task in an ANT build file:
<taskdef name="neoload"
classname="com.neotys.nl.ant.NeoLoad"
classpath="${NEOLOAD.install.dir}/lib/ant-neoload.jar" />
<neoload
projectFile="projects/jpetstore/jpetstore.nlp"
scenarioname="scenario1"
testdescription="Nightly Load-Test ${testID}"
showgui="false"
report="projects/jpetstore/reports/report.xml"
exit="true"
/>
Note
Paths are relative to the NeoLoad directory.
13
Installation
The taskdef definition must occur only once in each ANT build file and can appear anywhere on the
top level, below the project element.
If you move the ant-neoload.jar archive to another location, then you must specify the location of the
NeoLoad command line executable using the controllerExecutable parameter.
Parameters:
• projectFile (mandatory) : the project file (*.nlp).

• scenarioname (mandatory) : the scenario name.
• testdescription (optional) : the test description.
• showgui (optional) : if true, shows the graphical interface during the test. Default value is false.
• report (optional) : generate an end of test report. NeoLoad will output the report in the format
specified by the extension (.html, .pdf, .xml)
• controllerExecutable (optional) : path to the NeoLoad executable (<install_dir>/bin/
NeoLoadCmd.exe). This parameter is optional if you pick the ant-neoload.jar archive from
the NeoLoad installation directory. The parameter is mandatory if you move the archive to another
directory.
Launching the Load Generator Agent

For each test, the load generator is launched by an agent. Do not launch the load generator directly; always
launch the agent instead.
There are various ways of launching the agent:
Windows:
• As a service: Start "NeoLoad Agent" in the Windows Services control panel.

• Using the "Start Agent" shortcut in the Start menu.
• By launching the <install_dir>\bin\Agent.exe. program.
Unix:
• Starting the agent using <install_dir>/bin/AgentService start
• Starting the agent using <install_dir>/bin/Agent
• If installed with the root account, by launching service AgentService start with the root account.
Stopping the Agent

There are various ways of stopping the agent:
Windows:
• If the agent was started as a service, by stopping "NeoLoad Agent" in the Windows Services control
panel.
• Using the NeoLoad icon in the Windows system notification area.
• Using the "Shutdown Agent" shortcut in the Start menu.
• By entering the command line <install_dir>\bin\Agent.exe -stop
Unix:
• If the agent was started with <install_dir>/bin/AgentService start, by launching <install_dir>/bin/

AgentService stop.
14
Installation
• If the agent was started with service AgentService start, by launching service AgentService stop.
• In all cases, by entering the command line <install_dir>/bin/Agent -stop.
• Using the NeoLoad icon in the system notification area (if displayed).
Files
The Installation Directory
The program's installation directory, for example c:\program files\NeoLoad\ , contains the
following items:
• /bin - the executables,
• /conf - configuration files that cannot be edited in the GUI
• /jmxlib - libraries required for JMX access to J2EE application servers.
• /jre - Java Virtual Machine
• /jslib - libraries required by the JavaScript engine
• /legal - license files for the external components and libraries used by NeoLoad.
• /lib - libraries required by the program
• /mibs - MIBS, SNMP
• /swinglf - GUI themes.
The User Directory

NeoLoad stores the controller configuration file and all the log files (controller, agent, load generator) in
a user profile directory. The user profile used corresponds to the account used to launch the program.
• Windows. The user directory under Windows is: %ApplicationData%/Neotys/NeoLoad/

v<version>/
For example:
# Under Windows XP: C:\Documents and Settings\username\Application Data

\Neotys\NeoLoad\v3.1\
# Under Windows Vista: C:\Users\username\AppData\Roaming\Neotys\NeoLoad

\v3.1\
• Unix. The user directory under Unix/Linux is: <HOME>/.neotys/neoload/v<version>/
For example: /home/username/.neotys/neoload/v3.1/
Agent started as a Windows service

With a system administrator's account, the "NeoLoad Agent" Windows service is started by default.
The log files for the load generator and its agent are stored in the user profile for this system account.
15
Installation
Under Windows 2000/2003/XP
This account, named "LocalService" in Windows XP and 2003, or "LocalSystem" in Windows

2000, is hidden by default in Windows Explorer.
Procedure 2.5. Un-hiding the system account

1. In Windows Explorer, go to the "Tools / Folder options".
2. Click on the "View" tab.
3. Un-check the "Hide protected operating system files (recommended)" box.
Under Windows Vista
In Windows Vista, the default account user profile is stored in:
c:\windows\system32\config\systemprofile\AppData\Roaming\
Load generator logs

The load generator log files are retrieved at the end of a load test and stored on the controller side in the
project's test results' logs directory: <Project Name>/test_X/logs. One log file is created per
load generator and is stored in zip format.
If a log file is too big, the log files will not be retrieved. You may change the maximum size
setting in bytes for retrieved log files in the <agent>/conf/agent.properties file under
collected.lg.logs.size.max key in the Logs section. The default size is 10 Mb (10485760).
If a log file's retrieval from one of the load generators exceeds a certain time limit, it is terminated to allow
the test to finish. The default timeout is 30 seconds, but it may be edited in the controller's <neoload>/
conf/controller.properties file under the collected.lg.logs.timeout key in the
Runtime section.
Project Directory
Each NeoLoad project contains the following:
• /client-certificates - the client certificates.
• /lib - the libraries used by the project. These are divided into the following sub-directories:
# /jslib - the Java libraries used in the JavaScript code.
# /plugins - the libraries required to decode module requests (AMF, Oracle Forms, GWT, Java
Serialization and RTMP).
• /recorded-requests - requests executed during the recording.
• /recorded-responses - responses received during the recording.
• /recorded-screenshots - screenshots made during the recording.
• /scripts - JavaScript libraries saved in NeoLoad.
• /SqlTemp - the data for SQL-type variables is temporarily stored in this directory.
16
Installation
• /test_X - test directory. Each test directory contains the results of the test, plus the following sub-
directories:
# /debug - this is only created when a test has been launched in debug mode, and contains the files
relating to the virtual users' runs.
# /logs - the log files for the load generators used in the test.
# /results_db - the statistics retrieved during the test's running.
# /summary - the resources for the summary displayed in NeoLoad's "Results" section.
• /Project.nlp - the NeoLoad project descriptor file.
• /config.zip - contains the configuration for the entire project. Project backups are made regularly and
are named config.zip.<date>.bak
Note
The projects' default directory may be changed in the NeoLoad preferences ( "Edit /
Preferences" menu item, "General Settings" tab, "Advanced" section).
Log Files
By default, the NeoLoad controller, agent and load generator store their log files in the logs subdirectory
of the user directory.
Tip
You may quickly access the logs directory via NeoLoad's "Help / Open log
directory..." menu item, or the "Open log directory..." item in the menu accessed
via the Agent icon in the notification area.
Advanced Installation
Using a Firewall Between the Controller and Load
Generator
To use a controller and load generator either side of a firewall, you need to open ports TCP 7100
and 7101 on the load generator's interface. These connections are established in the controller to load
generator direction.
Opening these two ports is sufficient to allow you to use the remote generator. Other ports must be opened
on the firewall if you want to use the automatic discovery function: UDP 1359 in the controller to generator
direction and TCP 4569 in the generator to controller direction. If these ports remain closed, you will need
to declare the load generating machine's host name manually on the controller.
Procedure 2.6. Changing the default ports

1. Port TCP 7100 is opened by the generator's agent. This port may be changed by
editing the [Network]agent.server.port key in the <Load Generator>/conf/
agent.properties file on the generator side, and the [Network]agent.port key in the
17
Installation
<Controller>/conf/controller.properties file on the controller. Note that all agents

must use the same port.
2. Port TCP 7101 is opened by the load generator. This port may be changed by
editing the [Network]lg.server.port key in the <Load Generator>/conf/
agent.properties file on the generator side. The load generators may use different ports.
3. Port TCP 4569 is opened by the controller. This port may be changed by
editing the [Network]controller.server.port key in the <Controller>/conf/
controller.properties file.
4. Port UDP 1359 is opened by the generator's agent. This port may
be changed by editing the [Network]multicast.port key in the
<Load Generator>/conf/agent.properties file on the generator side,
and the [Network]agent.multicast.port key in the <Controller>/conf/
controller.properties file on the controller. Note that all the generators must have the same
port declared.
NeoLoad and Windows XP SP2 Firewall

Windows XP SP2 features a built-in firewall that is activated by default. When manually running the
generator agent with Agent.exe, Windows Firewall prompts the user to add the program to the exceptions.
When running the program as a service, the firewall does not issue the prompt and automatically blocks
the program, so the firewall must be configured manually. Add the following ports to the list of exceptions:
TCP 7100 and TCP 7101 at the very least, plus TCP 4569 to allow automatic discovery.
Increasing Available Memory for Load Generators

As with any Java program, the load generator's memory is limited. This limit must be raised whenever the
load generator's memory level indicator regularly exceeds 90% during the test.
For each load generator:
1. Edit the <install_dir>/conf/agent.properties file:
2. Edit the [LoadGenerator]lg.launcher.vm.parameters key to set the new limit in Mb.
3. For example: [LoadGenerator]lg.launcher.vm.parameters=-Xmx512m sets the limit

at 512Mb.
Note
This limit must not exceed the maximum physical memory available in order to avoid the use
of swap files.
Increasing Available Memory for the Controller

As with any Java program, the NeoLoad controller's memory is limited. This limit must be raised whenever
the controller needs to process a large volume of test results.
Edit the <NeoLoad>/bin/NeoLoadGUI.vmoptions and <NeoLoad>/bin/

NeoLoadCmd.vmoptions files and increase the number of Mb in the VM argument: -Xmx850m.
These modifications will allow the controller to use up to 850Mb of memory. The default memory
allocation is 512 Mb, sufficient for most projects.
18
Installation
Note
This limit must not exceed the maximum physical memory available in order to avoid the use
of swap files.
19
Chapter 3. Quick Start
Learn the basics of NeoLoad by performing a first test:
Recording the Test Scenario

1. Starting the recording
Click on the "Start recording" button on the controller to start recording the scenario.
2. Browser settings
NeoLoad will capture pages and record them into a virtual user profile. Choose the name of the profile
to record, then select "Adobe RTMP" if your application is using the RTMP protocol. By default,
NeoLoad records only HTTP traffic.
Next, specify which web browser is to be used for the recording and whether the browser's cache and
cookies should be cleared before recording.
3. Entering the URL to be recorded
The browser displays the NeoLoad recording page, indicating that the browser settings are correct.
The browser is now ready to record the scenario. Enter the URL of the site to be tested and browse
as normal.
20
Quick Start
4. Grouping recorded pages by business transaction
At any time during the recording, you may create named containers in which to group the visited
pages. These containers represent the business transactions within your scenario.
5. Stopping the recording
Close the browser to stop recording. You may also click on the controller's "Stop recording"
button.
6. Creating your first virtual user
Once the recording is finished, a pop-up wizard is displayed. Follow the steps through the wizard
(See the section called “Post-Recording Wizard”).
21
Quick Start
On the "Virtual Users" tab, you may configure the think time for the user. The think time is a
simulation of the time spent by the user on the previous page before accessing the current page. This
delay may be for each page individually, for all pages globally or variable within a given range.
7. Checking the validity of the virtual user
Complex scenarios may require advanced settings. A failure to implement these settings will result
in errors and an unexpected behavior for the virtual user. For example, the virtual user will not create
entries in the database.
Check the validity of the virtual user via the "Run / Start checking" menu item.
The "Check Virtual User" dialog displays the HTTP request and the HTTP response of each
NeoLoad request.
22
Quick Start
NeoLoad automatically flags in error any responses whose HTTP response code is an error code,
for example "500 Internal Error". Nevertheless, many applications return error messages
within a valid "200 OK" response. In these cases, NeoLoad does not automatically detect the error.
If the virtual user does not behave as expected, check the responses to see if they contain an error
message or an unexpected content.
Failure to handle a dynamic parameter will cause an error. See the section called “Handling an
Application's Dynamic Parameters”.
Generally, it means that you may need to extract and inject some data. See the section called “Creating
a Variable Extractor”.
8. Creating a population
Click on the "Populations" tab. A pop-up wizard prompts you to create a population for the test.
A population is a group of virtual users. In this example, the population only contains the previously-
recorded virtual user.
23
Quick Start
Running the Test

1. The Scenarios tab
Click on the "Runtime" button, then on the "Scenarios" tab.
Configure the settings such as test duration, load policy (constant, ramp-up, peaks, custom) and the
number of virtual users.
Run the test by clicking on "Run" top menu, and then click on the "Start playing" button.
24
Quick Start
2. The Runtime Overview tab
This panel monitors the test sequence. It provides immediate statistics such as hits/sec., average
response time and errors. The test may be stopped at any time by clicking on the "Stop" button.
Test Results
1. The Test Summary tab
The test summary provides general statistics for the test, including total test duration, throughput,
total number of hits, number of errors and average response time, together with important information
such as slowest pages, pages with the highest error rates etc.
25
Quick Start
2. The Values tab
This tab allows you to:
• quickly plot all the graph curves for a web page, HTTP request, a monitor or an indicator.
• sort the request and web page statistics.
Use "Filters" to filter the displayed results by load generator, population or virtual user.
Use the "Type" drop-down list to switch between Web Pages, HTTP Requests, Performance
counters and Indicators.
26
Quick Start
3. The Graphs tab
The "Graphs" tab can be used to plot a graph curve for any statistic in any request. Simply select
the required statistic among average response time, hits/sec., error rate etc., then drag and drop a Web
Page, a HTTP request or a Performance counter into the graph pane to the right.
You may also plot a curve for a previous test by selecting that test in the Results drop-down list
or compare two tests by selecting "Compare..." .
4. The Errors tab
This tab displays detailed information on request errors encountered during the test. It itemizes
the requests sent to the server, the server's response and the results of the assertions checking its
validity. To help pinpoint the source of the error, you may access the request that precedes the request
containing the error from this tab.
27
Quick Start
Click on "Response" or see Appendix C, NeoLoad Status Codes to obtain an explanation of the
response codes.
To Learn More
The Design User Guide is a short guide that summarizes the steps in designing a virtual user. We
recommend you read the guide before carrying out your first tests.
28
Part II. Reference Guide
Table of Contents
4. Menus ......................................................................................................................... 34
5. Preferences ................................................................................................................... 37
Global Preferences .................................................................................................... 37
HTTP Recorder Settings .................................................................................... 37
Proxy Settings .................................................................................................. 38
Browser Settings ............................................................................................... 39
Skins .............................................................................................................. 40
Graphs ............................................................................................................ 41
Frameworks ..................................................................................................... 43
License ........................................................................................................... 44
Oracle Forms ................................................................................................... 44
Adobe Flex/AMF .............................................................................................. 46
Advanced Parameters ........................................................................................ 47
Project Preferences .................................................................................................... 48
Page Naming Policy .......................................................................................... 48
SSL Client Certificates ...................................................................................... 49
Runtime .......................................................................................................... 51
Oracle Forms ................................................................................................... 53
Libraries Manager ............................................................................................. 54
CA Application Performance Management ............................................................ 59
dynaTrace ........................................................................................................ 64
6. Design ......................................................................................................................... 67
Recording a Test Scenario .......................................................................................... 67
Recording HTTP Applications ............................................................................ 67
Recording Adobe RTMP Applications .................................................................. 68
Starting Recording ............................................................................................ 69
Creating a Virtual User Profile ............................................................................ 69
The Recording Bar ............................................................................................ 70
Post-Recording Wizard ...................................................................................... 71
Troubleshooting ................................................................................................ 81
Servers .................................................................................................................... 81
Authentication .......................................................................................................... 82
Supported authentication mechanisms ................................................................... 82
The Negotiate scheme with SPNEGO and Kerberos ........................................ 83
Scheme priority order ........................................................................................ 83
Virtual Users ............................................................................................................ 83
Creating a Virtual User ...................................................................................... 84
Virtual User Runtime Settings ............................................................................. 84
Customizing a Virtual User ................................................................................ 85
Checking a Virtual User .................................................................................... 88
Web pages ............................................................................................................... 94
Requests .................................................................................................................. 95
HTTP Requests ................................................................................................ 95
SOAP requests ................................................................................................ 111
Oracle Forms Requests ..................................................................................... 119
Adobe Flex/AMF requests ................................................................................ 128
Adobe RTMP Requests .................................................................................... 138
Google Web Toolkit requests ............................................................................ 148
Java Serialization Requests ............................................................................... 156
Polling Requests ............................................................................................. 165
Streaming Requests ......................................................................................... 168
30
Reference Guide
Push Messages ................................................................................................ 172

Validation ...................................................................................................... 178
Variable Extractors .......................................................................................... 179
Advanced Parameters ....................................................................................... 185
Shortcuts ....................................................................................................... 186
Logical Actions ...................................................................................................... 187
Delay ............................................................................................................ 187
Loop ............................................................................................................. 187
While ............................................................................................................ 188
If ... Then ... Else ............................................................................................ 189
Variable Modifier ............................................................................................ 190
Containers ...................................................................................................... 190
Random Containers ......................................................................................... 191
Try ... Catch ................................................................................................... 192
Stop Virtual User ............................................................................................ 192
Fork .............................................................................................................. 192
Wait Until ...................................................................................................... 193
JavaScript ...................................................................................................... 194
Rendezvous .................................................................................................... 200
Frameworks ........................................................................................................... 204
Concept ......................................................................................................... 204
Framework Dynamic Parameter Handling ............................................................ 204
Generic Dynamic Parameter Handling ................................................................. 209
Searching for Dynamic Parameters in NeoLoad .................................................... 211
Push Frameworks .................................................................................................... 212
Context .......................................................................................................... 212
Definition ...................................................................................................... 212
Modified Virtual Users ..................................................................................... 213
Frameworks ................................................................................................... 214
Shared Containers ................................................................................................... 226
Sharing a Container ......................................................................................... 227
Using a Shared Container ................................................................................. 227
Actions on Shared Containers ............................................................................ 228
Populations ............................................................................................................ 228
Percentage ..................................................................................................... 229
Bandwidth ..................................................................................................... 229
Browser ......................................................................................................... 229
Use cookies .................................................................................................... 229
Connection ..................................................................................................... 229
Cache management .......................................................................................... 229
Variables ............................................................................................................... 229
Creating a Variable ......................................................................................... 230
The Variable Extractor ..................................................................................... 232
Testing a Variable ........................................................................................... 232
Using Variables .............................................................................................. 232
Search and Replace ................................................................................................. 233
Overview ....................................................................................................... 233
Search Criteria ................................................................................................ 233
Replacements ................................................................................................. 249
Flags ..................................................................................................................... 249
Flagging Criteria ............................................................................................. 250
Scope ............................................................................................................ 251
Importing and exporting a project .............................................................................. 251
Importing a project .......................................................................................... 251
31
Reference Guide
Exporting a Project .......................................................................................... 252

7. Monitors .................................................................................................................... 255
Overview ............................................................................................................... 255
Presentation .................................................................................................... 255
Creating and Configuring a Monitored Machine .................................................... 256
Creating and Configuring a Monitor ................................................................... 258
Creating and Configuring a Counter or an Indicator ............................................... 260
Setting and Configuring a Counter Alert Threshold ............................................... 262
Operating Systems ................................................................................................... 265
Linux Monitor ................................................................................................ 265
Solaris Monitor ............................................................................................... 269
AIX Monitor .................................................................................................. 273
HP-UX Monitor .............................................................................................. 277
Microsoft Monitors .......................................................................................... 280
Microsoft Windows Monitor ............................................................................. 281
Network ................................................................................................................ 283
RSTAT Monitor .............................................................................................. 283
SNMP Monitor ............................................................................................... 285
Databases ............................................................................................................... 287
Oracle DB monitor .......................................................................................... 287
Microsoft SQL Server Monitor .......................................................................... 294
MySQL Monitor ............................................................................................. 296
DB2 Monitor .................................................................................................. 302
PostgreSQL Monitor ........................................................................................ 308
Web/EJB Tier ......................................................................................................... 311
Microsoft IIS Monitor ...................................................................................... 311
Apache Monitor .............................................................................................. 312
Microsoft .Net Monitor ..................................................................................... 314
WebLogic 8 Monitor ....................................................................................... 316
WebLogic 9/10 Monitor ................................................................................... 323
WebSphere Monitor ......................................................................................... 331
JBoss Monitor ................................................................................................ 335
Tomcat 5.5/6.0 Monitor .................................................................................... 341
Oracle Application Server 9.X-10.X Monitor ....................................................... 346
Oracle Application Server 10.1.3 Monitor ............................................................ 348
JOnAS Monitor .............................................................................................. 353
GlassFish Monitor ........................................................................................... 359
SAP NetWeaver Monitor 7.0 ............................................................................. 367
SAP NetWeaver Monitor 7.1 ............................................................................. 374
LiveCycle Data Services Monitor ....................................................................... 381
8. Runtime ..................................................................................................................... 387
Test Settings .......................................................................................................... 387
Scenarios ....................................................................................................... 387
Duration Policy ............................................................................................... 388
Load Policy .................................................................................................... 388
Load Generator Hosts ...................................................................................... 389
Population Advanced Settings ........................................................................... 393
Scenario Advanced Settings .............................................................................. 394
Runtime supervision ................................................................................................ 397
Starting the Test ............................................................................................. 398
Stopping the Test ............................................................................................ 399
Runtime Overview .......................................................................................... 399
Real-Time Graphs ........................................................................................... 401
Real-Time Errors ............................................................................................ 403
32
Reference Guide
Real-Time Alerts ............................................................................................. 405

Viewing Virtual Users in Real Time ................................................................... 406
9. Results ....................................................................................................................... 408
General Information ................................................................................................. 408
Selecting a Test .............................................................................................. 408
Deleting a Test ............................................................................................... 408
Filtering by Load Generator, Population or Virtual User ......................................... 408
Virtual User, Container, Web Page and HTTP Request Statistics .............................. 408
Push Message Statistics .................................................................................... 409
The Results Manager ............................................................................................... 409
Select ............................................................................................................ 410
Compare ........................................................................................................ 410
Filtering ......................................................................................................... 410
Test folder ..................................................................................................... 410
Generating a Report ......................................................................................... 410
Deleting a Test ............................................................................................... 410
Test Summary ........................................................................................................ 411
Selecting a Summary ....................................................................................... 411
Content .......................................................................................................... 411
Graphs .................................................................................................................. 414
Working with Graphs ....................................................................................... 415
Graph Features ............................................................................................... 417
Features Specific to the Results Section .............................................................. 418
Values ................................................................................................................... 422
Element Types ................................................................................................ 423
Results Table .................................................................................................. 423
Plotting Curves ............................................................................................... 424
Indicators ....................................................................................................... 424
Exporting Data ............................................................................................... 425
Errors .................................................................................................................... 425
Detailed Error Information ................................................................................ 426
Selected Error Details ...................................................................................... 426
Previous Request ............................................................................................. 427
Alerts .................................................................................................................... 427
Alert Information ............................................................................................ 428
Alert Graphs .................................................................................................. 428
Debug ................................................................................................................... 429
General User Runtime Information ..................................................................... 429
Validating a User's Runtime .............................................................................. 429
Reports .................................................................................................................. 430
The Report Wizard .......................................................................................... 430
Report Type ................................................................................................... 430
Report Contents .............................................................................................. 431
Output Options ............................................................................................... 432
Test Results Comparison .......................................................................................... 433
Comparing Results in the GUI ........................................................................... 433
Generating a Comparison Report ....................................................................... 434
Test Result Filters ................................................................................................... 435
Filtering in the GUI ......................................................................................... 435
Available Filters .............................................................................................. 435
Filtering Test Results ....................................................................................... 437
Generating a Filtered Test Report ....................................................................... 437
33
Chapter 4. Menus
Description of the NeoLoad controller menus:
1. File.
• New: Display a new project window.
Note
You may change the default NeoLoad project directory in the global preferences ("Edit /
Preferences"), in the "Advanced" section.
• Open... : Open an existing NeoLoad project.
• Close: Close the current project and display the NeoLoad welcome screen.
• Save: Save the current project to disk.
• Save as...: Save the current project in another directory.
• Import project...: Import a project into the current project.
For more information, see the section called “Importing a project”.
• Export project...: Export the current project either to disk in a ZIP archive or to NeoLoad Support.
For more information, see the section called “Exporting a Project”.
• <Recent Projects>: List of recently-opened NeoLoad projects.
• Exit: Close the NeoLoad graphical user interface and exit the program.
2. Edit.
• Undo: Undo the user's last action in "Design" view.
• Redo: Re-do the user's last action in "Design" view.
• Preferences: Open the NeoLoad preferences pane (global preferences and current project
preferences).
For more information, see Chapter 5, Preferences.
• Variables: Open the variable editing panel. Use this panel to create, edit or delete NeoLoad variables.
For more information, see the section called “Variables”.
• Results Manager: Display the Results Manager. Use this to select, filter, edit or delete a result, or
to compare two test results.
For more information, see the section called “The Results Manager”.
• JS Libraries: Display the JavaScript library manager. Use this to add, edit or delete JavaScript
libraries.
34
Menus
For more information, see the section called “JavaScript libraries”.
• Search and replace: Display the "Design" view of NeoLoad and launch the "Search and Replace"
Wizard.
For more information, see the section called “Search and Replace”.
3. Record.
• Start recording: Display the new virtual user window in order to begin a new recording.
For more information, see the section called “Recording a Test Scenario”.
• Recording preferences...: Short-cut to NeoLoad's HTTP recorder preferences.
For more information, see the section called “HTTP Recorder Settings”.
4. Run.
• Start playback: Display the NeoLoad "Runtime" section and start the test for the current scenario.
For more information, see the section called “Starting the Test”.
When a test is running in normal mode, this menu is replaced by "Stop test", which allows you
to stop the test being run.
• Start debug: Display the NeoLoad "Runtime" section and start the test for the current scenario
in debug mode.
For more information, see the section called “Starting the Test”.
When a test is running in debug mode, this menu is replaced by "Stop test", which allows you
to stop the test being run.
• Start check: Display the virtual user validation window.
For more information, see the section called “Checking a Virtual User”.
5. Help.
• Help: Display the NeoLoad off-line help file.
Context-sensitive help is available by pressing F1; you may also carry out a search in the "Search
Help" toolbar.
Note
Help is also available on-line in HTML and PDF formats on the Neotys web site. See the
"Documentation Center" menu.
• Documentation center...: Launch the machine's default web browser and display the Neotys on-line
documentation center.
• Open logs folder...: Open the machine's file explorer and display the NeoLoad log files directory.
For more information, see the section called “Log Files”.
35
Menus
• Support...: Launch the machine's default web browser and display the Neotys on-line support request
page.
• License Management...: Short-cut to the NeoLoad license preferences.
For more information, see the section called “License”.
• Check for updates now...: Manually check for updates.
For more information, see the section called “Advanced Parameters”.
• About NeoLoad...: Display copyright and license information and the NeoLoad version number.
36
Chapter 5. Preferences
The NeoLoad preferences can be accessed from the "Edit / Preferences" menu item.
Global Preferences
HTTP Recorder Settings
Set the port for the recording proxy . The HTTP recorder uses a proxy that records the requests passing
between your browser and the web server.
Enter the regular expression patterns to filter the URLs to be recorded.
• Include list. If the Include list contains an entry, then NeoLoad will only record those URLs matching
at least one regular expression pattern. Use the Include list only to record requests sent to one or two
servers.
• Exclude list. The request will be recorded if it does not match any of the regular expression patterns
in the list. Use the Exclude list to avoid recording requests sent to certain listed servers, or requests for
jar or image files for example. Note that URLs authorized by the Include list must pass through the
Exclude filter, otherwise they will be rejected.
All the filters consist of regular expressions. Remember to escape special characters such as the period.
Here is an example of a filter: http://windowsupdate\.microsoft\.com.*
37
Preferences
Proxy Settings
Configure the user proxy .
The proxy settings are used both in recording a scenario and in playing back a test. When a scenario is
recorded, the recorder connects to the server via this proxy. Likewise, when a test is played back, the load
generator connects to the server via this same proxy, which means the proxy itself is load tested during
the test. Therefore, the proxy can be a source of bottlenecks that slow down performance.
There are three ways to configure the proxy in NeoLoad. If more than one method is selected, they are
executed in the following order: auto-detect settings, automated script, and manual setting.
• Automatically detect settings
This option automatically detects the proxy settings. It requires implementation of the WPAD protocol
over the network (via the DHCP or DNS server).
• Use automatic configuration script
With this option, you may specify the address of the automated configuration script (PAC file), if your
network has one. If the URL is incorrect, NeoLoad will switch to Manual mode or, failing that, not
use a proxy at all.
• Manual setting
This option allows you to manually enter the addresses of the HTTP, HTTPS and FTP proxies and their
ports (the three fields may be identical if one proxy handles all three protocols).
38
Preferences
The exceptions list lets you specify the names of the machines or IP addresses for which the proxy should
not be used (direct connection). Each element must be separated by a semicolon. The "*" (star) character
can be used to enter a wild card string. For example, to specify all the machines in the mydomain.com
domain, you can enter *.mydomain.com.
• Advanced settings
# Authentication
NeoLoad handles basic, Digest, NTLM and Negotiate (Kerberos) authentications. This option,
therefore, is used to specify the user name and password for identification on the proxy.
# Caching policy
This option is linked to the auto-detect and automated script modes. It allows the user to specify the
optimization level to be applied by NeoLoad when executing the automatic configuration script.
# Cache per generator: each load generator will share the proxy settings among all the virtual users.
This is the fastest method, but it can produce distorted results with some complex automated scripts.
If you have only one proxy, use this method.
# Cache per virtual user: each virtual user will use its own settings. This intermediate method should
be used if each user always uses the same proxy, for example, if the automated setting is based on
the client's IP address for the purposes of load balancing.
# No cache: if this option is selected, the automated script will be played at each request. This can
adversely affect test performance, but it provides the most accurate simulation. This option is
useful, for example, in the case of random method load balancing.
Browser Settings
Define the browsers that may be launched automatically on recording. The browsers are discovered and
added to the browser list when NeoLoad is run. You may add other browsers using the "Add" button.
Select the default browser to be used for recording by checking the "Default" box. Please refer to the
Recording chapter for details on browsers and recording scenarios.
39
Preferences
Skins
Change the look of NeoLoad Controller and the language used. The program must be restarted for the
changes to take complete effect.
40
Preferences
Graphs
This section allows to define NeoLoad's graph parameters, in particular the plotting interval.
41
Preferences
Definition: The plotting interval is the time lapse between two plotted points. For example, a curve with
a plotting interval of 30 secs will have a point plotted every 30 seconds. The plotted value is the average
of the values obtained over the plotting interval.
Runtime graphs
Configure the graph parameters displayed during the test runtime ( "Runtime / Runtime Graphs")
Result analysis graphs

Configure the rendering of analysis graphs displayed in the Results section ( "Results / Graphs" panel).
42
Preferences
Frameworks
Frameworks can be used to define rules for NeoLoad to configure the user profiles automatically after
a recording. Each framework can contain dynamic parameters (see the section called “Frameworks”) as
well as the specific rules for handling Push technologies (see the section called “Push Frameworks”).
43
Preferences
License
See the section called “License Key Management”.
Oracle Forms
Oracle Forms preferences are divided into two tabs :
• General settings: these settings are for defining regular expressions used to identify Oracle Forms
requests and responses.
• Session settings: these settings are for defining session identifiers used by NeoLoad to differentiate
concurrent Oracle Forms applets.
44
Preferences
General settings
Oracle Forms general settings allow the user to define :
• The regular expression that identifies the Content-type header in Oracle Forms requests and
responses. In most cases, Oracle Forms requests and responses are sent in binary format; therefore, the
Content-type header value is generally application/octet-stream.
• The regular expressions that identify the User-agent and Server HTTP headers. In NeoLoad,
several values may be defined for each HTTP header.
NeoLoad considers a request an Oracle Forms request if:
# The Content-type HTTP header in the request and response matches the given regular expression.
# The User-agent HTTP header matches at least one of the given regular expressions.
# The Server HTTP header matches at least one of the given regular expressions.
Care should be taken in modifying these settings. Any incorrect configuration can cause NeoLoad to
wrongly identify Oracle Forms requests.
All these settings have preconfigured default values that allow the recording of Oracle Forms requests
using an Oracle Forms 9i or 10g application server.
45
Preferences
Session settings
In order to differentiate between Oracle Forms applets executing simultaneously in a same web page
(or simultaneously in different browser tabs), NeoLoad needs a unique identifier for each Oracle Forms
session: the session identifier. NeoLoad is able to look for session identifiers in Applet URL requests.
Example: The Oracle Forms applet sends a request to http://myserver:8889/forms/servlet;jsessionid=... ;

in this example, the session identifier is "jsessionid". When NeoLoad tries to find this session identifier in
the Oracle Forms request URL, the search process is case insensitive so "JsessionId" or "JSESSIONID"
will give the same result as "jsessionid".
Session settings are preconfigured for Oracle Forms 9i and 10g application servers.
Adobe Flex/AMF
AMF is a binary transport protocol between client and server operating over HTTP in the network
application layer. This protocol is used by some Adobe Flash applications developed using Adobe Flex
language.
The Adobe Flex global preferences allow you to define AMF response error codes that NeoLoad should
NOT treat as errors.
AMF error code handling

The AMF error codes abide by the following rules:
46
Preferences
• AMF response error codes are automatically extracted from AMF responses.
• The extracted AMF error codes are compared to the ones configured in this panel. If the error code is
not listed here, the request will be displayed as having encountered an error.
Advanced Parameters
Allows you to modify the NeoLoad advanced parameters.
47
Preferences
• Folders: Change the default NeoLoad projects directory.
• Updates:
# Enable or disable automatic check for updates.
# Change the automatic update check frequency.
# Check for updates manually.
Note
Bugfix versions (e.g. 3.1.X) may be installed using the NeoLoad update utility.
Minor and major versions (adding new features, e.g. 3.X, 4.X...) must be downloaded and
installed manually. A specific license may be required to use these versions.
Project Preferences
Page Naming Policy
By default, when the scenario is recorded, the page name is the URL of the first request on the page. You
may change this behavior and specify several page naming templates.
48
Preferences
The templates may contain various values characterizing the page:
• $plugin$ : represents the name of the XML request played when it is the first request in the page.
• $path$ : represents the URL of the first request played.
• $title$ : represents the page's title.
• $param.<name>$ : retrieves the value of the <name> parameter.
You may define a list of templates. The pages will be named according to the first template; if one of the
values cannot be found (page title or parameter), the next template is applied. If none of the templates can
be applied, the default page naming is applied.
SSL Client Certificates

The Client Certificate Manager allows you to connect to SSL applications that require highly-secure
authentication based on client certificates. No setting is required at this point for normal SSL applications
(those not requiring certificates).
The Client Certificate Manager is accessed from the: "Edit / Preferences / Project
preferences / Certificate management" menu item.
49
Preferences
Importing certificates
Certificates must be imported before they can be used. Use the "Import certificates" button to add
certificates to a project. This import procedure merely copies the files selected in the project's "client-
certificates" directory. It is possible therefore to copy the files directly to this directory.
The certificates must contain the private key and therefore must be in PKCS12 format, the file extension
usually being .pfx, .p12 or .pkcs12.
Use the "Check certificate" button to check the password, format and content of a certificate.
The Recording Certificate

The certificate to be used for recording the scenario must be installed. As NeoLoad intervenes between
the web browser and the server to record the requests, the certificate is required for authentication with
the server.
Select the file to be used in the drop-down list, or enter the file name manually together with the
certificate's password. The file name must be the same as in the '"client-certificates" directory
(e.g. user1.pfx).
Note that, for security reasons, the password is stored encrypted.
Playback certificates
During the test, the virtual users may use:
• a single certificate: the one set for the recording,
• a different certificate for each virtual user.
50
Preferences
Procedure 5.1. Using a different certificate for each virtual user

1. Import all the certificates as described in the section called “Importing certificates”.
2. Create a variable containing the file names and corresponding passwords (or modify a file containing
existing accounts).
• Using the Edit / Variables menu, create a List or File type variable. The value change
policy must be "For each virtual user".
• Depending on the variable type, either create a CSV file or directly enter the data via the graphical
interface
• Each line must represent a virtual user and each column a piece of data relating to the user.
Some columns may also contain information useful for your particular application (name, address,
telephone number...) and others the following information: the user certificate's file name and also
its corresponding password.
3. Select "Use different certificate for each user".
4. Use the variable picker to use the appropriate variable.
Example
An example of data:
login ; lastName ; firstName ; certificate ; passwd

jsmith ; smith ; john ; jswith.pfx ; s2cr3t
jdoe ; doe ; john ; jdoe.pfx ; p4ssw4
Declare the accounts file-type variable and rename the columns by clicking on the column header. Then
use ${accounts.certificate} for the name and ${accounts.passwd} for the password used
within the certificate manager.
Tip
Variable names may be used in combination, for example, "${accounts.login}.pfx" .
Security concerns
The recording certificate password is stored in the NeoLoad project in encrypted form. However, this does
not ensure its total security.
Playback passwords, and all NeoLoad variables, are stored in plain-text format. Therefore, it is important
when testing to use test certificates and not real certificates, and only to test a system that is in not in
production.
If this is not the case, then access to the NeoLoad project must be secured in order to protect the certificates
and their relevant passwords.
Runtime
The runtime settings allow you to set the NeoLoad logging level.
51
Preferences
JavaScript
See the section called “Logger”
Error handling
NeoLoad can be configured not to flag as errors some requests that failed on recording. This is required
when some errors are "normal" for the application. NeoLoad should play these requests to be realistic but
should not flag them as error.
This is typically the case for missing resources (images, css,..) that send back a "404 Not Found" error
code. Check the "Do not mark the specified error code..." box to ignore the errors with
the "404" code if the recorded code was "404". Note that requests with a valid return code ("200 OK")
on recording will be flagged as errors if a "404" error occurs at runtime.
Statistics
The "Collect separate statistics from each load generator" option allows NeoLoad
to collect different statistics (average response time, hits/s,...) for all project items, such as requests or
containers, for each load generator.
This option is useful for a test that uses several load generators located in different geographic locations.
In that case you may wish to obtain generator-specific, and thus location-specific, statistics. This will
highlight any performance glitches due to the user's geographical position with regard to the web
application being load tested.
This "per load generator" data is available;
• by using the filters of the "Results" section. (See the section called “Filtering by Load Generator,
Population or Virtual User”).
52
Preferences
• by generating a filtered test result. (See the section called “Test Result Filters”).
Warning
This option may impact considerably the time spent to compute statistics at the end of the test
and the time needed to generate a report, since it multiplies the amount of data collected by the
number of load generator used during the test.
Oracle Forms
Configures how Oracle Forms components are managed during runtime. For more information about
Oracle Forms components, please see the Oracle Forms sample message.
Three options are available:
• On recording, automatically remove invalid components in requests.
During the recording, references to components that previously have been destroyed or have never been
created are removed from requests.
• On runtime, automatically replace component identifiers in requests.
When an Oracle Forms response is received, it is correlated with the recorded response to determine
which handlerId may have changed.
If a handlerId has changed during runtime, the recorded value is replaced by the runtime value in
the subsequent requests using it.
• On runtime, flag requests containing invalid components as errors.
When sending an Oracle Forms request, NeoLoad checks all handlerIds. When a handlerId does
not exist, an NL-OF-PLUGIN-ENGINE-03 error for the request is displayed in the virtual user validity
check and in the results errors pane. This can be useful, since Oracle Forms Server does not report a
request sending an unknown handlerId as an error.
Note
It's recommended to leave all these options enabled.
53
Preferences
Libraries Manager
The libraries manager allows you to select the libraries needed to decode requests and responses for the
AMF, RTMP, GWT and Java Serialization modules.
Adobe Flex/AMF
These preferences allow you to:
• Select the server-side AMF implementation; "Adobe" is the value selected by default. Implementations
provided by Adobe and GraniteDS are officially supported.
• AMF libraries must be declared according to the selected implementation.
# Adobe Flex/AMF project preferences allow you to declare/delete AMF libraries on-the-fly, without
the need to restart NeoLoad.
# When a JAR file has been successfully loaded, the JAR file is copied into the currently-open project's
directory (in the <NeoLoad Project>/lib/plugins/amf/ directory).
# Each time an AMF library is declared, every AMF request within the project is inspected; NeoLoad
will try to repair the requests whose content has not been fully converted into XML format.
# When load testing an Adobe Flex/AMF application, the declared AMF libraries are copied
automatically to each load generator selected in the scenario.
Adobe AMF Server

Select "Adobe" server-side implementation for LiveCycle or BlazeDS -based servers.
54
Preferences
In this case, implementing java.io.Externalizable server-side allows you to customize how Java
objects are sent over the network. To display these objects correctly in NeoLoad, JAR files containing the
Java classes need to be declared (including all dependent Java classes and third party libraries).
To declare one or more AMF libraries:
1. Select "Adobe" implementation.
2. Click on the "+" button and select the JAR files used by the Flex application being tested.
3. NeoLoad automatically repairs all AMF requests not already successfully converted into XML.
4. In the event of failure, more information is available in the appropriate log file plugins.log.XXX
(the logs directory can be opened from the NeoLoad menu by clicking "Help / Open logs
folder...").
Note
AMF libraries can be drag and dropped from the file explorer into the declared libraries table.
GraniteDS AMF Server

GraniteDS is an open-source server-side implementation of the AMF protocol. NeoLoad supports Flex
applications based on GraniteDS 1.1.0 RC4 or higher.
GraniteDS allows you to customize the way objects are sent over the network. To display these objects
correctly in NeoLoad, the following elements need to be declared:
• granite-config.xml: describes the GraniteDS custom flex application mechanisms.
• JAR files containing Instanciator, Externalizer, Descriptor...: all custom mechanisms

declared in granite-config.xml.
• JAR files containing Java Beans: the Java objects exchanged between the client and the server using
custom mechanisms and all their Java dependents.
To declare one or more AMF libraries (Jar and/or XML files):
1. Select "GraniteDS" implementation.
2. Click on the "+" button and select the granite-config.xml file on your hard disk drive.
3. Click on the "+" button again and then select the JAR files containing the custom GraniteDS
mechanisms and the Java Beans used by the Flex application being tested.
4. NeoLoad automatically repairs all AMF requests not already successfully converted into XML.
(the logs directory can be opened from NeoLoad menu by clicking "Help / Open logs
folder...").
Note
AMF libraries can be drag and dropped from the file explorer into the declared libraries table.
55
Preferences
Adobe RTMP
To decode these RTMP requests and responses correctly in NeoLoad, JAR files containing the Java classes
need to be declared (including all dependent Java classes and third party libraries).
To declare one or more RTMP libraries:
1. Click on the "+" button and select the JAR files used by the RTMP application being tested.
2. NeoLoad automatically repairs all RTMP requests not already successfully converted into XML.
(the logs directory can be opened from the NeoLoad menu by clicking "Help / Open logs
folder...").
Note
RTMP libraries can be drag and dropped from the file explorer into the declared libraries table.
56
Preferences
Google Web Toolkit

For NeoLoad to decode the GWT requests and responses into XML, the required libraries must be declared.
The libraries that are required are:
• Java objects that are transmitted over the network between client and server using GWT-RPC.
• The interfaces of the services called by the client application using GWT-RPC.
Declare these items using the following procedure:
1. Click the "+" button, then select the JAR files used by the GWT applications to be tested.
2. NeoLoad automatically repairs any GWT requests flagged as incorrectly converted to XML.
3. If the repair fails, you will find further information on the error in the log file: plugins.log.XXX
(the logs directory can be accessed via the "Help / Open logs folder..." NeoLoad menu
item).
Note
GWT libraries can be drag and dropped from the file explorer into the declared libraries table.
57
Preferences
Java Serialization
For NeoLoad to decode the Java Serialization requests and responses into XML, the required libraries
must be declared. The libraries that are required are:
• Java objects that are transmitted over the network between client and server.
• The interfaces of the services called by the client application.
Declare these items using the following procedure:
1. Click the "+" button, then select the JAR files used by the Java Serialization applications to be tested.
2. NeoLoad automatically repairs any Java Serialization requests flagged as incorrectly converted to XML.
3. If the repair fails, you will find further information on the error in the log file: plugins.log.XXX
(the logs directory can be accessed via the "Help / Open logs folder..." NeoLoad menu
item).
Note
Java libraries can be drag and dropped from the file explorer into the declared libraries table.
58
Preferences
CA Application Performance Management

The NeoLoad CA APM Integration Module sends HTTP headers with information about virtual users
and transactions to the Introscope module of CA Application Performance Management
(CA APM) from CA Technologies. This makes it easier to analyze the root causes of slow or failed
transactions which occur during load tests with CA APM which segregates web page response times and
other performance metrics using the information provided by NeoLoad. To enable the integration, you
need to:
1. install an additional component in the monitored application's CA APM Java agent;
2. enable CA APM support in NeoLoad.
Install the Synthetic User Field Pack extension in the CA APM

agent
1. Install a CA APM (Introscope) Java agent (version 7.x or above) on the server hosting the application
to be monitored.
2. Copy the <neoload_install_dir>/conf/ca apm/SynthHttpServletTracer.jar

file into the CA APM Java agent's ext directory.
3. Edit the j2ee.pbd file in the CA APM Java agent's installation directory.
Example 5.1. Apache-Tomcat server on Windows :

C:\Program Files\apache-tomcat-5.5.12\wily\j2ee.pbd
• Replace the keywords "HttpServletTracer" with "SynthHttpServletTracer".
59
Preferences
• Find the line:
TraceOneMethodWithParametersIfFlagged: HttpServletTypeSpecificServiceTracing
and add the following two lines immediately before it.
Here is the first line which is a single line even though it appears multiple lines in this document:
SetTracerClassMapping: SynthHttpServletTracer
com.wily.introscope.agent.trace.SynthHttpServletTracer
com.wily.introscope.probebuilder.validate.ResourceNameValidator
Second line :
SetTracerParameter: SynthHttpServletTracer useblame true
Warning
It's recommended to copy the correct lines from the j2ee.pbd sample file located in the
<neoload_install_dir>/conf/ca apm/ directory in order to avoid any character
coding problems resulting from a cut and paste from this document.
4. Edit the IntroscopeAgent.profile file in the CA APM Java agent's installation directory:
Example 5.2. Apache-Tomcat server on Windows :
C:\Program Files\apache-tomcat-5.5.12\wily\IntroscopeAgent.profile
• The three keys under the "URL Grouping Configuration" heading must not start with the
# character and must be filled in as follows:
introscope.agent.urlgroup.keys=default
introscope.agent.urlgroup.group.default.pathprefix=*
introscope.agent.urlgroup.group.default.format=
Note
See the CA APM documentation for more details on configuring URL grouping.
• The two keys under the "Transaction Tracer Configuration" heading must not start
with the # character and must be filled in as follows:
introscope.agent.transactiontracer.userid.method=HttpServletRequest.getHeader
introscope.agent.transactiontracer.userid.key=Synthetic_Trace_By_Vuser
Warning
It's recommended to copy the correct lines from the IntroscopeAgent.profile sample
file located in the <neoload_install_dir>/conf/ca apm/ directory in order to
avoid any character coding problems resulting from a cut and paste from this document.
Enable and configure CA APM support in NeoLoad

The CA APM settings panel allows you to enable and configure support for CA APM in NeoLoad.
60
Preferences
CA APM support enabled in NeoLoad
When the CA APM option is enabled, NeoLoad sends additional HTTP request headers with information
about virtual users and transactions. This information is extracted by the CA APM Java agents and enables
CA APM to segregate web page response times and other performance metrics by virtual users and
transactions under the Frontends branch of the Investigator window in the CA APM Workstation and
WebView tools. Here's an example of a NeoLoad virtual user profile:
61
Preferences
As the scenario is run, data relating to the virtual users simulated is fed into the CA APM Java agents and
stored in CA APM's SmartStor database along with all other metrics.
62
Preferences
Categories to be included in the request path
Three option boxes are used to configure the path of the executed request. Each element in the path
represents a tree node in the CA APM Investigator view.
• When the Virtual user name option is selected, the names of the virtual users are displayed in the CA
APM Investigator view.
• When the Container name option is selected, the container names are displayed in the CA APM
Investigator view.
• When the Other action names option is selected, the names of any other actions (such as Loop, If...
The... Else etc.) are displayed in the CA APM Investigator view.
63
Preferences
Enable tracing by virtual user
When the Enable tracing by virtual user option is enabled, Introscope traces a percentage of the virtual
user instances. This percentage must be a decimal number between 0 and 100. This value expresses the
probability a virtual user instance has of being traced. For example, a load test using 100 virtual users and
with a tracing percentage set at 10% will return specific metrics for approximately 10 instances and global
statistics for the remaining 90. The metrics provided for the non-traced virtual users are merged into a
same node labelled with the name of the virtual user.
dynaTrace
During a test, NeoLoad can send data to enable the correlation of requests sent by NeoLoad, the analysis
being done by the dynaTrace® server from dynaTrace Software.
64
Preferences
Activating support for dynaTrace

When the "dynaTrace" option is selected, NeoLoad sends a specific HTTP header that allows the
NeoLoad requests to be correlated using dynaTrace's code analysis. The information relating to the
NeoLoad requests can then be viewed in the dynaTrace client's "Diagnose Performance / Tagged
Web Requests" section.
Activating automatic session recording for a test

When the "Automatic session recording" option is selected, NeoLoad starts a dynaTrace session
recording at the beginning of the test and stops the recording at the end of the test.
dynaTrace 2.X
The recording is always carried out using the default name.
NeoLoad communicates with dynaTrace using the JMX protocol. Enter the connection parameters:
• "Server": the name of the dynaTrace machine
• "Port": the JMX port on the dynaTrace server (default: 2020)
• "Login": administrator account login (default: admin)
• "Password": administrator account password
• "System": the dynaTrace system's name. Click the "Fill in" button to fill in the list of available
systems automatically.
dynaTrace 3.X
With dynaTrace 3.0, the recording is always carried out using the default name.
With dynaTrace 3.1, the recording's name takes the form: "NeoLoad-<project name>-<scenario name>".
65
Preferences
NeoLoad communicates with dynaTrace using the JMX protocol. The dynaTrace JMX monitoring and
management service must be activated for automatic session recording to function (Menu Tools > Manage
servers... , Services section, Management tab).
The connection parameters are:
• Server: the name of the dynaTrace machine.
• Port: the JMX port on the dynaTrace server (default: 1099).
• System: the dynaTrace system's name. Click the "Fill in" button to fill in the list of available
systems automatically.
Warning
No authentication is required to use the dynaTrace 3.X JMX interface.
66
Chapter 6. Design
Recording a Test Scenario
Recording HTTP Applications
Set-up
NeoLoad allows you to record a scenario using just a basic browser. The NeoLoad Recorder, seen as a
proxy by the browser, records each HTTP request and response to and from the server:
Where the browser already accesses the server via a proxy, the recording proxy will use this same user
proxy to access the server:
Configure the user proxy settings in the Preferences.
SSL support
The recorder supports SSL secured servers. When first accessing the server during the recording, the
browser will generate security alerts concerning the validity of the server's certificate. These alerts are
quite normal, since the recorder intercepts the traffic from the server and provides its own certificate. You
may ignore these alerts and continue to browse as normal.
To create a scenario on an application that requires client certificates, it's necessary to install these
certificates into NeoLoad before starting recording. Client certificates should be installed from the project
preferences.
To allow NeoLoad to capture the HTTPS requests sent from a Java Applet, the Java plug-in of the browser
must be configured to use the NeoLoad recording proxy as a proxy server.
To configure this setting:
• Go into the configuration panel and open the Java settings

• Open the General tab, then click on the Network settings button.
• Choose Use the proxy server and set localhost as the host name and the NeoLoad proxy
port (default is 8090).
• Confirm this choice, make sure you close all the browser instances, then re-start your browser before
making a new recording.
Manually configuring the recording proxy settings

For HTTP and HTTPS protocols, use "localhost" or "127.0.0.1" as the proxy host. The default port for the
recorder is 8090 (HTTP and HTTPS); the port may be changed in the preferences
67
Design
To change the proxy settings in Internet Explorer, click on Tools/Internet options , then on the
Connections tab.
• If you connect to the server via a local network, go to the Local Area Network (LAN)
settings section and click on the LAN settings button.
• If you connect via a modem, go to the Dial-up and Virtual Private Network Settings
section and click on the Settings button.
For other browsers, the proxy settings are accessible via the browser's preferences.
Test the set-up by entering the URL http://neoload/. If the page displays correctly, the settings
are correct (this URL is not recorded).
Filtering out unwanted requests

When using Internet Explorer, unwanted requests may be recorded. Indeed, the Internet Explorer proxy
settings are shared by numerous other programs that connect to the Internet using the HTTP protocol.
Thus, the recorded test scenario may contain requests emanating from Windows Update, MSN Messenger's
login, spyware etc..
The recorder's exclusion filter already blocks a certain number of access requests by default. If other
unwanted requests remain, these must be either deleted after recording or added to the filter (See the section
called “HTTP Recorder Settings”).
Recording Adobe RTMP Applications

How it's done
NeoLoad allows you to record applications using Adobe RTMP. As it's not based on HTTP, the browser
doesn't use a proxy to exchange RTMP data with the server. NeoLoad registers itself as the network adapter
driver in order to record the RTMP traffic between the machine and the server.
68
Design
Note
You need to purchase the optional RTMP module for RTMP requests to be handled. This module
is included in the demo version of NeoLoad.
Limitations
There are certain limitations regarding the recording of Adobe RTMP applications:
• Recording is only possible using Windows.
• NeoLoad must be started using an administrator-level account for it to be able to register itself as the
network adapter driver.
• Under Windows Vista / 7, when User Account Control (UAC) is activated, NeoLoad must be launched
by right-clicking on the program file and selecting "Run as Administrator" in the pop-up menu.
• An application cannot be recorded if the server is the local machine.
• An application cannot be recorded if the connection to the server is across a VPN.
Starting Recording
The Start recording button is accessed from either the toolbar or the virtual user profiles description
panel.
Creating a Virtual User Profile

Starting a new recording will create a new virtual user profile and place all the web pages visited during
the recording into that profile. At the beginning of the recording, you may delete the cookies and clear
the browser cache.
69
Design
• Virtual user name. In the "Name" text field, enter the virtual user name. When the recording ends,
the virtual user with this name will contain all the recorded pages and requests.
• Recorded protocols. Select the protocols you want NeoLoad to record.
NeoLoad records the HTTP protocol by default.
If the license permits, you may activate recording for Adobe RTMP (Real Time Messaging Protocol).
RTMP is a streaming protocol developed by Adobe that works on top of TCP/IP. See the documentation
on the RTMP module for more information.
Warning
Recording a RTMP application in NeoLoad is subject to certain limitations. See the recording
limitations for more information.
• Launch browser. Automatically launches the selected browser and opens the test URL http://
neoload/ using the automatically-configured proxy settings. If this page displays correctly, the recording
proxy has been set up correctly. Closing the browser stops the recording.
Clear this option to manually configure the recording proxy settings , manually launch the browser and
record the scenario.
• Delete cookies. Deletes cookies prior to recording in order to simulate a user's first visit to the
application.
Cookies are restored when recording ends. As Internet Explorer's cookies may be cached in the system
memory, this browser is not recommended if a precise monitoring of cookies is required.
• Clear cache. Clears the browser's cache in order to simulate a user's first visit to the application.
With Internet Explorer, the cache is permanently cleared; with other supported browsers, the cache is
restored when recording ends.
Supported browsers
Browsers for which automatic proxy management, cache clearing and cookie deletion are supported:
• For Windows: IE5, IE6 , IE7, IE8, Mozilla, Firefox, Netscape 6/7, Netscape 4.7.
• For Unix: Mozilla, Firefox, Netscape 6/7, Netscape 4.7 and Konqueror (Linux).
Other browsers may be used to record test scenarios but these must be configured manually. Browsers that
are not detected automatically may be manually entered in the preferences.
The Recording Bar

The recording bar allows you to modify the virtual user during the recording.
•
Clicking the "Stop" button stops the recording and opens the Post-Recording Wizard.
Enter a container name for the subsequent web

pages to be recorded within that container. A container is used to identify and collect a group of web
70
Design
pages. Delete the container name to end the collection of new pages within the container and to allow
the creation of a new container.
•
Click on the "Rendezvous" icon to insert a rendezvous point. See the section called
“Rendezvous” for more details.
Post-Recording Wizard
At the end of the recording, NeoLoad gives you the option of carrying out various tasks on the scenario
you have just recorded. The wizard comprises several modules that are displayed according to the recorded
scenario's characteristics. These modules are:
• Java library handling. Some web applications using the Adobe Flex/AMF, Adobe RTMP, GWT and
Java Serialization technologies require Java libraries to be declared in order to play back the virtual user's
requests correctly. See the documentation for each technology for more details on the Post-Recording
Wizard.
For example, see the section called “Post-Recording Wizard” for the Adobe Flex/AMF module.
• Push application handling. Some web applications using Push technology need advanced
configuration in order to play back the virtual user correctly. NeoLoad can create part of this advanced
configuration for a number of frameworks. For more information of the frameworks supported, see the
section called “Push Frameworks”. For more details on the automation provided by NeoLoad, see the
section called “Frameworks”.
• Dynamic parameter handling. Certain form or request parameters are server-generated and must
be extracted from the server response during the test. This step detects and automatically configures
these dynamic parameters.
See the section called “Frameworks”
• Think time between pages. The think time between pages is an important component in any load
test. The think time between pages must be realistic for each user type if a realistic server load is to
be generated.
71
Design
The wizard gives you the option of either using the think times as recorded, or overriding the think time
value for all a virtual user's pages with a new value.
Warning
When overriding the think time value for all pages is selected, the current virtual user's settings
are updated.
Note
The think time for each page may be set in the Virtual Users section. You may also
override the think time for all a virtual user's pages in the Runtime parameters panel in
the Design / Virtual Users section.
• Basic, Digest, NTLM or Negotiate authentication. When NeoLoad detects a Basic, Digest, NTLM
or Negotiate authentication during recording, the wizard gives you the option of configuring the
authentication either to use the recorded account for all virtual users or to vary the accounts for each user.
72
Design
When the "Use the recorded account" option is selected, the account used is the one used in
the recording. The account may be changed by editing the server settings.
When the "Use multiple accounts" option is selected, the accounts data is sourced either from
a list of static values (to be entered directly via the NeoLoad interface), or from a CSV file.
# Using a list-type variable. NeoLoad creates a list-type variable and configures the server used in
the recording to use that variable for NTLM authentication. The values for the variable are specified
in the user login handling panel.
73
Design
Note
The column names can be changed by clicking on each column's header.
# Using a file-type variable. NeoLoad creates a file-type variable and configures the server used in
the recording to use that variable for NTLM authentication. The values for the variable are specified
in the user login handling panel.
74
Design
Note
The column names can be changed by clicking on each column's header
Once the variable has been filled in, you must specify the column to be used for logins and the column
to be used for passwords.
• Form-based authentication. When NeoLoad detects a form-based authentication during recording,

the wizard gives you the option of configuring the authentication to use multiple accounts using
NeoLoad variables. A form-based authentication is detected when a form containing at least one text
field and one password field is sent.
When an authentication form is detected, NeoLoad presents you with a list of possible forms for basic
authentication. Check the authentication forms in the list, then click Next.
75
Design
The list contains all the text -type fields found in the form. Select the field containing the user login
id among the fields shown.
76
Design
The list contains all the password -type fields found in the form. Select the field containing the user
password among the fields shown.
You may use the recorded account for all instances of the virtual user profile or use multiple user
accounts.
77
Design
When the "Use the recorded account" option is selected, the account used is the one used in
the recording. The account may be changed by editing the server settings.
When the "Use multiple accounts" option is selected, the accounts data is sourced either from
a list of static values (to be entered directly via the NeoLoad interface), or from a CSV file.
78
Design
# Using a list-type variable. NeoLoad creates a list-type variable and configures the server used
in the recording to use that variable for form-based authentication. The values for the variable are
specified in the user login handling panel.
79
Design
Note
# Using a file-type variable. NeoLoad creates a file-type variable and configures the server used
in the recording to use that variable for form-based authentication. The values for the variable are
specified in the user login handling panel.
Note
Once the variable has been filled in, you must specify the column to be used for logins and the column
to be used for passwords.
80
Design
Troubleshooting
If you have any problems with recording, please refer to the Troubleshooting Guide .
Servers
The servers pane is used to declare and modify the web servers used in the scenario. The servers are
automatically created when the scenario is recorded. The server settings are centralized, which means the
target server for the test can be quickly changed. It is possible, for example, to quickly switch from the
development to the pre-production server.
Select the server to bring up its settings pane:
81
Design
• Http server. Displays the Http server definition. Change hostname and port to switch physical server
for all requests using the current server.
# Authorization. User accounts used to authenticate to the server. The password-protected zones
(realms and domains) are detected during the recording and automatically added. The accounts may
be dynamic and changed for each user being simulated, using variables.
See the section called “Authentication” for more details on how authentication works in NeoLoad.
# HTTP URL rewriting. Session tracking is automatically enabled when cookies are used. For
servers that use URL rewriting to track a session, the session argument must be defined (e.g.
SESSIONID or JSESSIONID for most servers). When detected during recording, the argument is
automatically filled in.
• Server. Displays the non-Http server definition. Change hostname and port to switch physical server
for all requests using the current server.
Authentication
Supported authentication mechanisms
NeoLoad supports the following authentication mechanisms: Basic, Digest, NTLM and Negotiate.
82
Design
The Negotiate scheme with SPNEGO and Kerberos

SPNEGO is at the heart of the HTTP Negotiate authentication mechanism. When using SPNEGO, the
browser and server negotiate as to which underlying mechanism to use, Kerberos or NTLM. If Kerberos
-the default protocol- fails, Negotiate will try NTLM.
Note that Integrated Windows Authentication on Microsoft IIS uses both Kerberos v5 and
NTLM authentication.
For performance reasons however, NeoLoad uses NTLM in place of SPNEGO as the default underlying
mechanism for Negotiate, since SPNEGO+Kerberos has a major impact on Load Generator performance.
When SPNEGO+Kerberos is used, a Load Generator cannot generate as many Virtual Users.
Enabling SPNEGO therefore, is not recommended. If it is absolutely required however, follow this
procedure:
Procedure 6.1. Enabling SPNEGO
1. Edit the <neoload>/conf/controller.properties file.
2. Change the value of the [Authentication]scheme.negotiate.subprotocol= key to

spnego (default value is ntlm)
3. Edit the <neoload>/conf/krb5.conf file and set the Key Distribution Center (KDC) for each
Realm and Domain.
Scheme priority order

Some servers support multiple schemes for authenticating users. NeoLoad prioritizes them in the order
Negotiate, NTLM, Digest, Basic to reflect the order used by regular browsers.
In certain cases, you may wish to change this default order:
Procedure 6.2. Modifying scheme priority
1. Edit the <neoload>/conf/controller.properties file.
2. Edit the value of the [Authentication]scheme.priority key.
Virtual Users
A virtual user simulates the browsing activity of a real visitor. The virtual user is a succession of web pages,
which may contain logical actions such as containers, loops or delays to create a more complex behavior.
In NeoLoad, virtual users are created and managed in the "Design" section's "Virtual Users" tab.
83
Design
Creating a Virtual User

The usual way to create a new virtual user is to record one or more business usage cases using a web
browser. See the section called “Recording a Test Scenario”.
To create a new, empty virtual user, right-click on the "Virtual User Profiles" node and select
the "New virtual user" menu item.
Virtual User Runtime Settings

Stop conditions
By default, a virtual user will continue running even in the event of an error. Where a virtual user uses
link or form extractors, an error in a preceding request may cause the extractor to fail. In these cases, we
recommend that you configure the virtual user to stop in the event of an error. Likewise, a virtual user may
be stopped in the event of a failed assertion.
Note
A virtual user will not stop running within a try container.
Think time
The think time simulates the time spent by a user on the preceding page before accessing the current page.
This time delay may be set for each individual page, or globally for all pages.
The think time options available for each virtual user are:
84
Design
• Use think time defined on pages: By default, the think time set for each page is the think
time measured during recording.
• Override think time for all pages with: Use a global think time for all the virtual
user's pages. You may use a variable to obtain a dynamic behavior.
• Apply this factor for each page: Apply a factor to the think time used for the pages. For
example, by entering a factor of 130%, you can increase the think time for the pages by 30%. A factor
under 100% will reduce the pages' think time.
The "Add a random delay of +/- X %" option can be used to add a random element to the delay.
The time delay thus obtained is between "delay + x%" and "delay - x%".
Tasks
This panel is used to access the following tasks:
• Check the virtual user validity. Opens the virtual user checking window with the current virtual
user preselected. See the section called “Checking a Virtual User”.
• Search for dynamic parameters. Starts a search for dynamic parameters. See the section called
“Frameworks”.
Customizing a Virtual User
Virtual user content

The basic components of a virtual user are the pages, which are themselves made up of requests. For more
information on these components, see the section called “Web pages” and the section called “Requests”.
For a more complex behavior, NeoLoad allows you to add control components such as loops, conditions,
containers etc. See the section called “Logical Actions”.
Editing a virtual user
Adding an element
To add an element such as a loop or a simple container to a container, use the right-click pop-up menu
and select "Insert into". The menu displays the child elements compatible with the selected parent
element.
To add one element directly after another, use the right-click pop-up menu and select "Insert after".
The menu displays the elements that may be inserted at the specified location.
An alternative is simply to drag and drop the element from the "Actions" pane located beneath the virtual
users tree. See the section called “Moving an element” for more information on dragging and dropping
in the virtual users tree.
Deleting an element
To delete an element, use the right-click pop-up menu and select "Delete" or use the "Delete" button
in the button array to the right of the virtual users tree.
85
Design
Confirmation is required prior to any deletion.
Moving an element
To move an element:
• Use the button array to the right of the tree. You may move the selected element up or down the
tree using the "Up" and "Down" buttons in the button array. Use the ">" button to place the selected
element in last position in the first container encountered above the selected element. Use the "<" button
to place the selected element immediately after its parent.
• Drag and drop. When dropping, there are three target zones: the top zone indicates that the moved
element will be inserted above the target element, the middle zone indicates that the moved element
will be inserted inside the target element, and the bottom zone indicates that the moved element will
be inserted below the target element.
When over the middle zone, the target element is only highlighted if insertion is allowed. In the case of
the top or bottom zone, a hyphen is displayed to show that the insertion is allowed.
Warning
A page is a container, since it can contain other pages (frames or iframes). Be careful not to
place one page inside another accidentally. Make sure the hyphen is displayed before dropping
a page.
Note
Confirmation of a move is required when the time delay between drag and drop is very short
in order to avoid any accidental moves. When the delay is longer, NeoLoad assumes the move
is deliberate and does not ask for confirmation.
The pop-up menu

Right-click to display a pop-up menu for the selected element.
Description of the menus common to all elements:
• Insert after. Inserts a new element immediately after the selected element.
• Insert in. Inserts a new element into the selected container.
86
Design
• Shared. Shares a container element so that it can be re-used in several virtual users. See the section
called “Shared Containers”.
• Flag requests... Opens the flags window to search for requests in the current virtual user. See the
section called “Flags”.
• Cut. Places the element on the clipboard. Once pasted, the element is removed.
• Copy. Places a copy of element on the clipboard.
• Paste after. Inserts the clipboard contents after the selected element.
• Paste in. Inserts the clipboard contents into the selected container.
• Delete. Permanently deletes the selected element after confirmation.
• Duplicate. Makes a copy of the selected element.
• Select in "Check virtual user" window. Opens the virtual user checking window with the current
virtual user preselected and displays the selected element.
This option is only available if the current virtual user has been previously validated. See the section
called “Checking a Virtual User”.
• Select in results panel. Displays the "Values" tab in the "Results" section and selects the element
in the results table.
This option is only available if the element was played back during the test corresponding to the current
results. See the section called “Values”.
• Expand all. Recursively expands all the tree nodes below the selected node.
• Collapse all. Recursively collapses all the tree nodes below the selected node.
The following have additional menu items:
• Virtual user.
# Check this virtual user. Opens the virtual user checking window with the current virtual user
preselected. See the section called “Checking a Virtual User”.
# Search for dynamic parameters. Starts a search for dynamic parameters. See the section called
“Frameworks”.
# Search and replace. Launches the Search and Replace Wizard. See the section called “Search
and Replace”.
# Advanced / Rename pages. Allows you to change the page naming policy and to apply that policy
to the selected virtual user's pages for bulk re-naming. See the section called “Page Naming Policy”.
# Advanced / Apply recording filter. Applies the recording filter to omit requests already recorded
after the filter was modified. See the section called “HTTP Recorder Settings” for more information
on URL include and omit filters.
• Requests.
# Add the server to the omit list. Allows you to omit the server from the request in subsequent
recordings. NeoLoad generates a regular expression for the appropriate server and adds it to the omit
87
Design
list. See the section called “HTTP Recorder Settings” or more information on URL include and omit
filters.
Afterward, you may use the "Advanced / Apply recording filter" menu option for the
current virtual user to remove all the requests using the same server as the selected request.
Checking a Virtual User

Checking a virtual user's validity is highly recommended prior to running a complete test, as the pages used
may require fine tuning. This is almost always the case when the server generates links containing dynamic
parameters such as /results?searchID=345365. In this example, the corresponding request either
should be converted into a link extractor or a variable extractor should be used.
Use the "Run / Start checking" menu item to display the checking window.
Correct any errors in the virtual user profiles.
During the checking process, NeoLoad runs a virtual user and displays details of all the actions played,
be they logical actions (pages, container ...) or requests.
Summary
At the end of the checking process, a summary is displayed containing the statistics for the virtual user
just played:
• Page count: the number of pages played during the checking process.
88
Design
• Request count: the number of requests played during the checking process.
• Push message count: the number of Push messages played during the checking process.
• Virtual user size: overall size of all the pages played during the checking process (sum of the sizes of
all the server responses).
• Virtual user duration: total time taken to run the virtual user. During the virtual user check, think times
are not played by default. However, the virtual user duration includes the calculated think times to reflect
the actual time that will be taken by the virtual user during the test.
Note
See the section called “Advanced settings” to play think times when checking the virtual user.
• Errors count: total number of requests containing errors ( HTTP and validation errors).
• View used variables during the validation: link to view the variables used and extracted during the
checking process.
89
Design
Request
For each request, a detailed analysis can be made of the request sent by NeoLoad, the server response
and any assertions. To do this, you just need to click on the request in the table and select the detail to be
displayed (Request, Response, Assertions, Variables) in the Details section.
Note
For quick and easy selection, the request and page names are linked to the virtual user profiles.
90
Design
A server response may be displayed in a browser window. In this case, NeoLoad opens a browser that
displays the page containing the server response returned during the checking process. This allows you
to preview the page itself, rather than view the HTML source code. Images are not displayed during this
preview, as only the HTML code for the current request is sent to the browser.
You may also compare the request and server response with those recorded.
91
Design
Pages
For each page, the details include the page duration (including think time -not played during the checking
process) and its size (sum of the sizes of all the requests in the page).
Tip
For quick and easy selection, the page name is linked to the virtual user profiles.
Note
As some requests are played concurrently, the page duration is not the sum of the request response
times.
An HTML view of the page is available in the "HTML Rendered" tab, displaying the page as seen by
the virtual user during the check. This view is available during the checking process when the think times
are played.
HTML page rendering

Click on the "HTML Rendering" tab for the selected page to view the page seen by the virtual user
during the during process. This view allows you to make sure that the scenario run by the virtual user does
not contain any errors and that it behaves as expected.
During the checking process, the HTML rendering of each played-back page may be enabled automatically
when think times are played. To enable the automatic rendering of HTML pages, edit the advanced settings:
make sure "Play virtual user-defined think times" is checked, then check "Enable
page rendering during validation".
92
Design
Important
The HTML rendering may be incorrect (missing images, page layout), especially with AJAX
applications. The rendering is provided for information purposes to quickly detect any problems
with the scenario and cannot precisely reflect the rendering obtained by the real user.
Advanced settings
When checking a virtual user, some of the virtual user's advanced settings may be modified:
• download and upload bandwidth
• browser
• cookie handling
• number of simultaneous server connections allowed
• cache behavior
• load generator used to check the virtual user
• use the URL exclusion filter for the current scenario.
• play think times and display pages in HTML automatically.
Export
The current check also may be exported. In this case, NeoLoad creates an XML file containing all the sent
requests as well as the server responses. This may be useful for analyzing a script or when contacting our
technical support team. Here is a sample of an XML export:
<?xml version="1.0" encoding="UTF-8" ?>

<Project user="JPetStore" population="Check-JPetStore-04997-Population" lghost="loc
<StartContainer checkID="0" timestamp="703" objectID="2" objectName="JPetStore"
<StartContainer checkID="1" timestamp="797" objectID="3" objectName="Index JPet
<StartPage checkID="2" timestamp="860" objectID="4" objectName="/jpetstore/
<Transaction checkID="3" timestamp="1000" objectID="5" objectName="http
93
Design
<Request binary="false">
<Body><![CDATA[GET http://host/jpetstore/ HTTP/1.1...]]></Body>
</Request>
<Response code="200" type="text/html; charset=UTF-8">
<Headers><![CDATA[HTTP/1.1 200 OK...]]></Headers>
<Body><![CDATA[...]]></Body>
</Response>
</Transaction>
...
</Project>
Import
You may import a virtual user check that has been exported in XML format by clicking the "Import"
button and selecting the file to be imported.
Warning
The user whose check file has been exported must be in the same state (requests, logical actions...)
at importation as it was at exportation.
Web pages
The web page is the page as rendered by a web browser. It consists of the HTML page and all its sub-
components, such as image files and CSS style sheets.
• Name: the name of the web page in NeoLoad.

• URL: the URL of the first HTTP request forming the page is displayed here for information purposes.
• Description: enter a description of the web page here if required.
• Think time: the think time is the interval before a web page is accessed. This corresponds to the time
a real user would spend reading the page displayed by the browser before clicking on a link or filling
94
Design
in a form before submission. Use this box to set the think time for this page or click on the link to the
runtime settings pane to set a global think time for all pages. The default policy is to use the think time
defined for each page (to change this policy, click on the same link).
Note
In the virtual user definition, you will find several ways of managing think times (add a factor
to all think times, vary the think times by a random amount ...).
• Page screenshot: a screenshot of the browser content at the instant the web page was recorded.
Please note that this function is only available in Windows and is merely a reminder of what was
displayed in the browser window when the web page was recorded. Screenshots are only available for
web pages with an HTML content. If the screenshot does not mirror the actual web page, it may be
deleted.
Automatic screenshots during recording may be turned off by changing the value of the
recorder.screenshot.enabled key in the [GUI] section of the <NeoLoad>/conf/
controller.properties file to false.
• Advanced: Web page advanced settings.
# Request playback: The NeoLoad default setting is to play back requests in compliance with the
HTTP protocol with the browser using several parallel connections to retrieve a page's resources.
For specific needs, you may force NeoLoad to play the requests sequentially and according to their
order in the page definition contained in the Virtual User profiles.
Requests
HTTP Requests
In NeoLoad, an HTTP request is a request sent over a network using the HTTP or HTTPS protocol.
Normally the request is followed by a server response, which can be in the form of an HTML web page,
image or CSS file among others.
95
Design
Type
The request type can be defined in four ways:
• Use a manual definition. Manually define the request. Allows you to enter the URL and set the
parameters to be used for the request. See the section called “Use a manual definition”.
• Follow a redirect of the previous request. Indicates that the present request is the target of an HTTP
redirect in the response to the preceding request. See the section called “Follow the redirect of the
previous request”.
• Follow a link from the previous request. Extracts and follows a link matching a dynamic definition.
This option should be used when a scenario includes a click on a dynamically-generated link. The load
generator dynamically extracts the link from the results of the preceding request (referrer) and follows
the link. See the section called “Follow a link from the previous request”.
• Submit a form from the previous request. Extracts and submits a form from a form in the previous
request. This option should be used when a scenario includes the submission of a form containing a
dynamic hidden field. The load generator dynamically extracts the form from the results of the preceding
request (referrer), allowing the dynamically-extracted values to be submitted. See the section called
“Submit a form from the previous request”.
96
Design
Use a manual definition
The manual definition of a request includes:
• The method (GET, POST, HEAD, PUT, DELETE, OPTIONS, TRACE, CUSTOM).
• The server.
• The path (may contain variables).
• The parameters (each parameter may contain variables in the name or value).
Request parameters
Parameters may be defined for any type of request (GET, POST, HEAD, PUT...). Some may be applied
to static values and others to dynamic values by using variables.
Editing a parameter name or value is done in a dedicated window. Double-click on a name or value in the
parameters table to open the window.
97
Design
Parameter Name
The name may contain plain text or a NeoLoad variable. When the Encode name box is checked,
the specified name is encoded in MIME application/x-www-form-urlencoded format before
being submitted (e.g. spaces are encoded as %20). Clear the check box if the name is already encoded.
Parameter Value
Two options are available for the parameter's value:
Use an expression. The value's expression may contain plain text and NeoLoad variables. The value
may comprise several lines in the case of a POST.
98
Design
Use an extracted value. This option allows you to define a value extracted from a previous server
response. This option typically is used in the case of a server-generated dynamic value that changes for
each user.
The extractor to be used can be modified manually using the "Edit extractor configuration"
button. Clicking the button displays the variable extractor interface, giving you the additional option of
selecting the request on which the extraction should be carried out. If no configuration is applied, NeoLoad
offers the option of configuring the extractor automatically (see below).
Clicking the "Automatic configuration" button starts a search for the parameter in the previous
requests. NeoLoad searches the previous requests for the parameter's value and for the best regular
expression to extract it. If one of the tested configurations works, NeoLoad will replace the existing
extractor with the one found.
The "Add to framework parameters" button allows you to add the variable extractor as a
framework parameter and carry out a dynamic parameter search. For more details, see the section called
“Frameworks”
If the "Encode value" box is checked, the specified value is encoded in MIME application/x-
www-form-urlencoded format before being submitted (e.g. spaces are encoded as %20). Clear the
check box if the value is already encoded.
POST parameters
Whatever the type, POST-type requests may have parameters contained within the URL. The POST and
URL parameters may be processed separately using the tabs provided.
In the above example, the URL obtained during the test will be: http://jack:80/loadtest/
form/doit.jsp?
firstname=john&lastname=smith&email=john.smith@company.com.
POST requests with binary content
POST requests with an "application/octet-stream" -type content or non-standard charset are

processed by NeoLoad as if they were binary content. This ensures that no URL or charset encoding is
carried out on the contents before playing.
99
Design
POST requests with text content

POST requests with a "text/..." -type content. The contents of these requests may contain NeoLoad
variables for generating dynamic content.
Multi-part POST parameters

POST requests with a "multipart/form-data" -type content have modifiable parameters and use
a specific interface.
100
Design
Each part is described by a name attribute and a value. It also features an optional specific content type,
charset and transfer encoding. Refer to RFC1867 [http://www.ietf.org/rfc/rfc1867.txt] for more details.
Each field may be replaced by a variable. The value may be a string or a file input.
Fields specific to the file part
The filename field describes the file name within the part. The part's content data is described by the source
file field. The file may be identified using a set path or one related to the project. The files are automatically
copied to all the load generators when the test is started.
Follow the redirect of the previous request
Indicates that the present request is the target of an HTTP redirect in the response to the preceding request.
When a request is defined as an HTTP redirect, the load generator will not use the recorded URL or
101
Design
the parameters to play the request. Instead it will use the result of the preceding request dynamically
(the preceding request must have a response of the type "302 Moved Temporarily"). This is
extremely useful in the case of pages causing redirects containing dynamically-generated parameters (e.g.
/searchresult.jsp?searchID=481825 where searchID is generated by the server).
In this mode, it's possible to edit the referrer, in other words the request whose response is the redirect.
This request must be located earlier than the current request in the scenario. NeoLoad then displays the
redirect URL used in the recording.
Follow a link from the previous request
Extracts and follows a link matching a dynamic definition. This option should be used when a scenario
includes a click on a dynamically-generated link. The load generator dynamically extracts the link from
the results of the preceding request (referrer) and follows the link. The referrer may be changed by clicking
on "Change the referrer"; note that the referrer must always be located earlier in the scenario
than the current request.
When defining the link to be extracted, you may specify the HTML attributes of the link to be followed
(name, id, link text, alt), or define all the link's elements (URL, parameters). A typical case is
where one or more of the link's parameters are dynamic.
Warning
When using a regular expression for the HTML attribute or for the path, the regular expression
special characters must be escaped. The following characters must be escaped using "\": [ ]
^ \ { } ( )
Where several links in the server response match the definition, the last option in the panel allows you to
extract a link randomly or specify the occurrence to be extracted.
102
Design
Request parameters
Parameter definition is used to define, in particular, the request's dynamic parameters. Each parameter in
the definition must be present in the link to be extracted. NeoLoad will be able to use a link that contains
additional parameters to those present in the definition.
When extracting a link, you may automatically create NeoLoad variables containing the parameter values
when the link is executed. This allows you to extract the dynamic part of the link and use it in subsequent
requests. If, for example, the application frequently uses the same dynamic parameter, you may define
a link extractor at the parameter's first use and use the variable in all the other requests that use that
same parameter. This avoids multiplying searches in the server response pages and results in better load
generator performance.
Parameter Name
103
Design
Parameter Value
Three options are available for the parameter's value:
The value must be an expression. The value's expression may contain plain text and NeoLoad
variables. The link that NeoLoad is going to extract must contain this parameter with this value. This
implies that the value is static and that any link containing this parameter but with a different value should
be ignored.
The parameter must exist, whatever its value. The link that NeoLoad is going to extract must contain
this parameter, whatever its value. This generally implies that the parameter's value is dynamic and is
not known beforehand. This dynamic value may then be placed in a NeoLoad variable by editing the
"Extract in variable" column in the parameters table.
The value must match a regular expression. The link that NeoLoad is going to extract must contain
the parameter and the value must match the regular expression. This generally implies that part of the
parameter's value is dynamic and is not known beforehand. The value used may then be placed in a
NeoLoad variable by editing the "Extract in variable" column in the parameters table.
Example
Let's look at an example: the web application generates a search id named searchID, and this id is
transferred from page to page as a request parameter. The request's recording looks like this:
104
Design
During a test, NeoLoad will play back the request using the searchID that was recorded.
Therefore, we need to replace the searchID with the appropriate value. The preceding
page contains the following link: <a href="http://ServerHostname/search.php?
searchID=<mygoodsearchid>&page=2">Page2</a>
So this manual request must be changed to a "Follow a link from the previous request"
type:
105
Design
In this example, the searchID's value is set at <MUST BE PRESENT>, which means that the
searchID may have any kind of value. Using this configuration, NeoLoad will search for a link using:
• the path: /loadtests/search/index.jsp.
• a page parameter with a value of 2.
• a searchID parameter.
As the server response contains only one link matching the description, NeoLoad will use this link with
the searchID parameter value present in the server response.
We can also set the "page" parameter to "<MUST BE PRESENT>". If the response contains several
links such as:
<a href="search.php?searchID=<mygoodsearchid>&page=2">page2</a>
then all these links match the definition and NeoLoad will select either one at random or a specific
occurrence, depending on how the parameter has been configured.
Submit a form from the previous request
Extracts and submits a form from a form in the previous request. This option should be used when
a scenario includes the submission of a form containing a dynamic hidden field. The load generator
dynamically extracts the form from the results of the preceding request (referrer), allowing the dynamically
extracted values to be submitted.
Using this option allows you to define a target form on which to work. Selecting the form is done via
the button in the Extracted Form section, which displays a new window with further options. Once
the form has been selected, the forms various elements can be used in the request to be submitted (URL,
parameter value).
106
Design
Defining the form to be extracted
The form to be extracted must be present in the response to the referring request. You may change the
referrer by clicking the "Change the referrer" button; note that the referrer must always be located
earlier in the scenario than the current request. Three options are available when defining the form to be
extracted:
• Form's id or name HTML attribute. This field may contain a regular expression.
• Form's occurrence within the page (e.g. extract the 2nd form in the server's response).
• Form matching the following definition: URL, and parameter names are required (NeoLoad will not be
able to use a link that contains additional parameters to those present in the definition).
Warning
When using a regular expression for the HTML attribute or for the path, the regular expression
special characters must be escaped. The following characters must be escaped using "\" : [ ]
^ \ { } ( )
Where several forms in the server response match the definition, the last option in the panel allows you to
extract a link randomly or specify the occurrence to be extracted.
107
Design
Request parameters
Parameter definition is used to define, in particular, the request's dynamic parameters.
When extracting a form, you may automatically create NeoLoad variables containing the parameter values
when the form is submitted. This allows you to extract a dynamic parameter in a form and use it in
subsequent requests. If, for example, the application frequently uses the same dynamic parameter, you
may define a form extractor at the parameter's first use and use the variable in all the other requests that use
that same parameter. This avoids multiplying searches in the server response pages and results in better
load generator performance.
Parameter Name
108
Design
Parameter Value
Three options are available for the parameter's value:
Use an expression. The value's expression may contain plain text and NeoLoad variables. The value
may comprise several lines.
Use value from extracted form. NeoLoad will use the value from the extracted form for the parameter.
This generally implies that the parameter's value is dynamic and is not known beforehand. This dynamic
value may then be placed in a NeoLoad variable by editing the "Extract in variable" column in
the parameters table. Each "Submit a form from the previous request"-type request is
presumed to contain at least one parameter of this type.
Use an extracted value. This option allows you to define a value extracted from a previous server
response. It should be used typically in cases where a dynamic value generated by the server does not
appear in the form's HTML code (otherwise the "Use value from extracted form" option is
more appropriate). Usually, if the parameter value is generated in JavaScript, the value must be extracted
using a variable extractor.
The extractor to be used can be modified manually using the "Edit extractor configuration"
button. Clicking the button displays the variable extractor interface, giving you the additional option of
selecting the request on which the extraction should be carried out. If no configuration is applied, NeoLoad
offers the option of configuring the extractor automatically (see above).
The "Add to framework..." button allows you to move the variable extractor as a framework
parameter and carry out a dynamic parameter search. For more details, see the section called “Concept”
Clicking the "Automatic configuration" button starts a search for the parameter in the previous
requests. NeoLoad searches the previous requests for the parameter's value and for the best regular
109
Design
expression to extract it. If one of the tested configurations works, NeoLoad will replace the existing
extractor with the one found.
Example
Let's take the case of an application with a search form such as this one:
<form name="searchform" method="POST" action="search.jsp">

<input type="text" name="name" size="30" value="">
<input type="text" name="city" size="30" value="NY">
<select name="country" id="country">
<option value="US">US</option>
<option value="Canada">Canada</option>
<option value="China">China</option>
<option value="France">France</option>
<option value="UK">UK</option>
</select>
<input type="radio" name="fastsearch" value="YES">
<input type="radio" name="fastsearch" value="NO">
<input type="hidden" name="computedValue" value="4235">
<input type="submit" name="Submit" value="Submit">
</form>
In this example, the "computedValue" hidden field is generated server-side and is different for each
call.
The recorded request looks like this:
During a test, NeoLoad will play back the request using the value for the "computedValue" parameter
as recorded. It needs to be replaced with the appropriate value, so the manual request type must be changed
into a "Submit a form from the previous request" type:
110
Design
Using <FORM VALUE> as the value for computedValue allows you to extract the value generated
by the server.
Furthermore, using <FORM VALUE> for the country field means you can choose a random value among
those available for this option. Likewise, the fastsearch field will have a random "YES" or "NO" value
during the test.
Therefore, the form extractor not only allows you to extract the dynamic values generated by the server,
it also allows you to use the various form choices in a random manner.
SOAP requests
NeoLoad's optional SOAP module can be used to load test Web services using the SOAP protocol.
There are two ways of using this NeoLoad module:
• Declare, then enter, the SOAP request's call parameters (manually or using a WSDL description file)
• Record a SOAP request played by an existing client application, then modify its parameters.
Creating a SOAP request

This section describes how to create a SOAP request from the ground up. To record a request using an
existing client, see the next section
Procedure 6.3. Creating a SOAP request in a virtual user

1. In the "Design" section, click on the "Virtual Users" tab.
2. In the virtual user, container or page's pop-up menu, select "Insert as child / SOAP
Request".
3. Follow the wizard to select the parameter editing mode:
111
Design
a. Create a SOAP request using a WSDL description file:
i. Enter the URL containing the WSDL. Use the file browse button to select a file on
the hard drive, or enter a web server URL, for example: http://myserver/app/
myservice?WSDL.
ii. In the drop-down list, select the method (or operation) to be tested.
iii. Choose a pertinent name for the SOAP request.
iv. Enter the URL of the web service ("Endpoint"). The URL defined in the WSDL is displayed
by default.
b. Create a SOAP request by manually editing an XML request.
i. Choose a pertinent name for the SOAP request.
ii. Enter the URL of the web service ("Endpoint").
Recording a SOAP request

This section describes how to record the interaction between an existing SOAP client and the web services
server.
Procedure 6.4. Recording a SOAP request.

1. Alter the SOAP client's settings so that it uses NeoLoad as a proxy:
112
Design
• hostname: name or IP address of the machine currently running the NeoLoad Controller.
• port: the NeoLoad HTTP recorder's port, 8090 by default. This setting can be changed in the
NeoLoad preferences.
Please refer to the documentation accompanying your web services framework for instructions on
how to change the proxy settings. As a guide:
a. Axis: Modify the http.proxyHost and http.proxyPort system properties.
For example, place the following lines in your code:
System.setProperty("http.proxyHost", "localhost");
System.setProperty("http.proxyPort", "8090");
or modify the command line as follows:
java -Dhttp.proxyHost=localhost -Dhttp.proxyPort=8090 ...
b. .Net. The configuration file may be modified as follows:
<configuration>
<system.net>
<defaultProxy>
<proxy
usesystemdefault = "false"
proxyaddress="http://localhost:8090"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>
</configuration>
For further information, please see http://support.microsoft.com/default.aspx?scid=kb;

[LN];318140
2. Run NeoLoad
3. Start a recording (See the section called “Recording a Test Scenario”). Since the recording does not
require a browser, we recommend clearing the "Launch browser" option .
4. Launch your SOAP client application. Since the application has been configured to use the NeoLoad
recorder as a proxy, NeoLoad records the request.
5. Stop the recording.
Editing a SOAP request

Description of the SOAP request editing pane:
113
Design
• Name. Name of the request
• Description. Optional comments or notes.
• URL. Web service's URL, cannot be edited.
• Server. Web service server.
• Path. Path to the web service, depending on the selected server.
• WSDL. URL for the WSDL. For a file on the hard drive, the URL will take the form file:/
C:/... Use the file browse button to select the file. For an online file, use the standard http://
myserver/myapp/myservice?WSDL.
The Reload button allows the WSDL to be reloaded and to choose a method from the WSDL. It
reconfigures the request parameters according to the new selected method. After confirmation, the
request's original parameters are deleted.
• Edition mode.
# WSDL parameters mode
This mode is available if a WSDL file has been defined. It allows the call parameters to be entered
based on the WSDL definition. See the section called “Editing the parameters extracted from the
WSDL”.
# XML mode
This mode allows the request to be edited directly in XML format. See the section called “Editing
the XML content”.
• Method. SOAP Method to be called, cannot be edited directly. Another method can be selected when
clicking on the Reload button, if a WSDL is provided.
• Content. Edit the WSDL parameters or XML content, depending on the mode selected.
114
Design
• Parameters. URL parameters. See the section called “Request parameters”
• Test. Provides a quick way to test the request. Clicking on "Check" creates a virtual user containing
the edited request, then launches the virtual user check.
Note
The "Advanced..." and "Check..." buttons provide the same features as for a standard
HTTP request, allowing the editing of HTTP headers, the creation of variable extractors and the
checking of contents.
Editing the parameters extracted from the WSDL
When NeoLoad loads the WSDL file, it generates a default tree structure for the parameters and SOAP
headers. Optional parameters may be deleted and other parameters added if the WSDL description permits.
Parameters
The parameters tab allows the user to edit, delete or add parameters.
Parameter editing is limited by the restrictions imposed by the WSDL description.
There are two types of parameters:
• leaf elements, such as a text or numeric value which can be edited.
This value may be an actual value or a variable. Encoding allows special characters such as '>' and '<'
to be encoded. If the value is a variable, the "encode value" option may be cleared if the variable's
value is already encoded
115
Design
The value type displayed is the 'type' in the WSDL sense of the term, for example: {http://
www.w3.org/2001/XMLSchema}string. The user must ensure that the value type syntax is
adhered to.
• containers that contain other elements:
# Elements of type "Sequence" contain other elements in a specific order and follow the cardinality
described in the WSDL. For example, the S sequence must contain between zero and three A
elements and at least one B element, in that order;
# Elements of type "All" contain other elements once, and only once, in an unspecified order;
# Elements of type "Choice" contain a single child element among the various child elements allowed.
The container element's restrictions are displayed for information purposes in the "Children"
section at the bottom of the container's edit pane.
To add an element to a container , either click on the '+' button, or right-click on the element, then
select "Add". In either case, the list of elements to be added is limited by the child elements allowed by
the WSDL. The element is automatically inserted in the appropriate place, among the other child elements
where an order constraint exists.
To delete an element from a container , either click on the '-' button, or right-click, then select
"Delete".
To move an element within a container , use the appropriate direction button, or right-click, then select
"Move up" or "Move down".
116
Design
Note
If a restriction imposed on the container by the WSDL is not complied with, an error icon is
added to the container's icon. An error message also appears in the "Child elements" section
of the appropriate container's edit panel.
The attributes section allows the user to edit the parameter's attributes. The permitted attributes are listed
in the table. The first column, "Use", allows the attribute to be added to the parameter. Entering a value
in the value column automatically adds the attribute to the parameter. It is not possible to add attributes
not intended by the WSDL.
Headers
This tab is used to configure the SOAP headers declared in the WSDL.
Its use is similar to that of the Parameters tab.
The specific SOAP Header section allows the user to define the SOAP protocol's "Actor" attribute.
Advanced
This tab is used to define the following two parameters:
• message style. The styles supported are: RPC/Encoded, RPC/literal, Document/literal

and Wrapped Document/literal. The style selected is the one declared in the WSDL. Normally,
this parameter should not be changed, as the web service expects to be contacted using the predetermined
style (as set in the WSDL).
• encapsulation format for the binary attachments: MIME or DIME. As with the message style, this
parameter is extracted from the WSDL and should not normally be changed.
XML preview
This allows the user to preview the XML body of the request exactly as it will be generated. The preview
cannot be edited and only includes the XML body of the message (not the binary attachments, where
present).
Carry out a request validation to obtain a preview of the complete HTTP request.
117
Design
Editing the XML content

If the WSDL file is not defined, or if the WSDL parameters cannot be edited, the XML body of the message
may be defined manually.
To do this, edit either the XML text or the XML tree.
Flat XML
This tab allows the user to edit the XML text.
Tip
Right click or use 'Ctrl-F' to search.
XML Tree
This tab is used to edit the nodes of the XML tree using the open tree view. The variable picker in this
view makes it especially useful when using variables.
If a node value contains a variable, and this variable is already encoded, the option not to encode it
XML-wise is available. In this case, NeoLoad adds the attribute NeoLoad-encode="false" to the
corresponding node, visible in the XML text tab view. This additional attribute will be deleted during
the XML encoding phase of the test and will not be sent to the server.
Preview
This tab provides a read-only preview of the body of the request to be sent.
The variables are interpreted and the carriage returns deleted (see tip below).
Tip
The request has the carriage returns removed to make it more compact for the test. Right-click
and select "Format as pretty XML" to obtain a more readable presentation.
118
Design
Configuring the "SOAPAction" HTTP header
SOAP 1.1 requires the presence of the SOAPAction HTTP request header. This header is automatically
added, with the appropriate value, when the WSDL is loaded, or recorded if the request is recorded.
Edit the request's HTTP headers to modify this value. To do this, click on the "Advanced..." button
and select the "Request header" tab .
Testing a SOAP request

Click on the Check button in the Test section to test the current SOAP request.
NeoLoad creates a virtual user containing the single request, then displays the validation window for that
virtual user. Click on the Start check button.
The Details section provides details of the request sent and of the server's response, and access to the
assertion messages.
Tip
Right-click and select "Format as pretty XML" in the text field to obtain a more easily-
readable detail report for the sent request. Right-click and select "Find..." or use Ctrl-F
to search.
Oracle Forms Requests

Overview
The optional Oracle Forms module allows the user to load test Oracle Forms web applications. The module
supports versions 9i and 10g of the OC4J (Oracle Container 4 Java) application server. Oracle Forms is
a technology developed by the Oracle Corporation.
Recording
The diagram below shows how the Oracle Forms module functions during the recording:
119
Design
The binary data exchanged between the client and server transit via the Recording Proxy. It's during this
transit that the Oracle Forms module analyzes and decodes the requests. Once they've been translated into
XML, the requests are inserted in the project.
Execution
The diagram below shows how the Oracle Forms module functions when a test is run:
The variables in the XML request are calculated and the module's engine translates the XML into binary
data, which is then sent to the server. The binary response received is translated into XML, after which
the validations and variable extractors in the played request are executed.
Configuring NeoLoad
To record Oracle Forms requests, NeoLoad needs a JAR file, obtained from the Oracle 10g application
server. When recording an Oracle Forms request without this JAR file having been previously loaded,
NeoLoad displays a warning message.
To install this JAR file in NeoLoad:
1. Stop NeoLoad if it is already running.
2. If the Oracle server is a standard application server, open the <oracle_home>/forms/java

directory, where <oracle_home> is the application server's installation directory.
If the Oracle server is part of the Oracle Applications Suite, open the
<oracle_applications_home>/tech_st/<version>/forms/java directory, where
<oracle_applications_home> is the Oracle Applications installation directory and
<version> is the server version. For example, for the VISION demo version of Oracle E-Business
R12, the directory would be: c:\oracle\VIS\apps\tech_st\10.1.2\forms\java.
3. Copy the JAR file named frmall.jar.
4. Open the <NeoLoad Home>/lib/plugins/ext directory, where <NeoLoad Home> is the

NeoLoad installation directory.
5. Paste the copied file.
6. Restart NeoLoad.
Note
This JAR file is automatically copied to each Load Generator when a scenario is launched.
120
Design
Configuring the Oracle Forms Server

For the Oracle Forms module to function, the Oracle Forms application server needs to be configured to
enable NeoLoad to identify the Oracle Forms graphical components by name instead of by an ID number.
This configuration must be in active during both recording and test runtime.
There are several ways to enable component naming, depending on the Oracle Forms server's set-up:
Procedure 6.5. Modify the Oracle Forms applet's baseHTML file (default:
basejini.htm)
1. Open the applet's baseHTML file (default: <Oracle Home>/forms/server/
basejini.htm).
2. Locate the line <PARAM name="serverArgs" VALUE="............%otherParams

%">
3. At the end of the VALUE field, add the following: record=names
4. Once modified, the line should look like this: <PARAM name="serverArgs"
VALUE="............%otherParams% record=names">
5. If there is more than one occurrence of the serverArgs parameter, repeat the above modification
for each occurrence.
6. Save the file, then re-start the Oracle Forms server.
Procedure 6.6. Modify the Web CGI configuration file (default: formsweb.cfg)
1. Open the Web CGI configuration file (default: <Oracle Home>/forms/server/
formsweb.cfg).
2. Try to locate the line record=
3. If the line exists:
a. Replace it with record=names
b. Save the file, then re-start the Oracle Forms server.
4. If the line does not exist:
a. Add the following line anywhere in the file: xrecord=names
b. Open the applet's baseHTML file (default: <Oracle Home>/forms/server/

basejini.htm).
c. Locate the line <PARAM name="serverArgs" VALUE="............

%otherParams%" >
d. At the end of the VALUE field, add the following: record=%xrecord%
e. Once modified, the line should look like this: <PARAM name="serverArgs"
VALUE="............%otherParams% record=%xrecord%">
f. If there is more than one occurrence of the serverArgs parameter, repeat the above
modification for each occurrence.
121
Design
g. Save the file, then re-start the Oracle Forms server.
Procedure 6.7. Modify the user profile in the Oracle Applications suite
1. Once logged in as administrator to the Application Server Control Console, via the web browser,
click on the System Administrator link.
2. Then, in the browser window, select Profile System Values.
3. In the Find System Profile Values window, fill in the fields as follows:
a. Check the Site check box.
b. Check the User check box, then fill in the name of the required user.
c. Clear the Profiles with No Values check box.
d. In the Profile field, add the value %ICX%Launch%.
e. Click on the Find button.
4. In the System Profile Values window, locate the line that refers to the profile ICX: Forms
Launcher, and insert the user value ?play=&record=names
5. Save the changes and exit the application.
6. Connect to the Oracle Forms application, always using the specially-configured user account.
Recording Oracle Forms Requests

The following conditions are required before starting an Oracle Forms recording:
• The JAR file containing the Oracle Forms applet must have been copied into NeoLoad.
• Component naming must be enabled on the Oracle Forms server.
• All running browser instances connected to an Oracle Forms application must be closed.
Recording SSL-Secure Oracle Forms Requests

In the case of an applet executing the JInitiator Java plugin, you need to declare the SSL certificate to be
used by NeoLoad in order to be able to record Oracle Forms requests secured using the SSL protocol.
By default, the applet rejects server SSL certificates that are self-signed. NeoLoad's SSL recording proxy
simulates an SSL server by using a self-signed certificate.
Procedure 6.8. Declare the NeoLoad SSL certificate in JInitiator

1. Close any open browser instances (Internet Explorer, Firefox, ...).
2. Open the <NeoLoad Home>/conf/neoload.ssl.proxy.certificate.cer file in a

text editor.
3. Copy the entire content of the file by right-clicking in the text, then selecting Select All, then
right-clicking again and selecting Copy.
4. Open the <Jinitiator Home>/lib/security/certdb.txt file. <Jinitiator

Home> is the JInitiator installation directory. Several versions of JInitiator may be installed. In this
case, repeat points 4 and 5 for each version installed.
122
Design
5. Paste the previously-copied content at the end of the file. The content must be added; be sure not to
delete anything in this file.
6. Save the file.
This procedure must be carried out in order to record SSL-secure Oracle Forms requests. NeoLoad does
not need to be restarted for these changes to take effect.
User interface
Editing a request in text mode
An XML module's editing pane allows the user to edit, and define variables for, the request's XML content.
This XML content is displayed in an enhanced text field with syntax highlighting.
The text field provides a number of features and keyboard shortcuts:
• Right click on the mouse: displays the context-sensitive menu

• CTRL + Z: Undo last change
• CTRL + Y: Re-do last change
• CTRL + X: Cut selected ext
• CTRL + C: Copy selected text
• CTRL + V: Paste text copied to clipboard
• CTRL + F: Search text
• CTRL + R: Search and replace text
• CTRL + G: Go to line number...
If the request's XML content has been modified, the changes can be saved by clicking the "Apply" button.
If a problem is detected, an error message notifies you of the problem and the changes will not be applied.
If no problems are detected, the changes are applied.
The text field features an auto-complete function that makes entering variable names easier.
123
Design
Editing a request in advanced mode

To access the advanced XML editor, select a request, then click the "Advanced XML editor..."
button. This is the same editor as the one used for the SOAP module. For more information on how it
works, see Editing a SOAP Request.
You must click the "Apply" button to save any changes you make to the request.
Rules for using variables

You may use NeoLoad variables in a request's XML content. To do this, you need to use the expression
${VariableName}, which NeoLoad will replace with the value during the test. All the elements in the
XML request may be variabilized.
Warning
Using a variable other than in an element's content (for example, to replace an XML node) will
use up a large amount of system resources.
124
Design
Validating an XML response
Validating a response in XML format is almost identical to the standard procedure. For information on
how to validate an HTTP request, see the documentation on validating an HTTP request.
You may define validations on the XML response using XPath. To recap, XPath is a syntax that points
to a portion of an XML document.
For an XML request, response validators may be created:
• For the entire response: these are standard validators that validate the response's content.
• For a particular XML node: these are validators that are specific to the XML modules. An XML node
can then be specified by selecting it in the dialog box that is displayed by clicking on the magnifying
glass next to the field.
This will create an XPath expression based on the selected XML node. You may edit the expression
manually, but you must make sure the XPath expression remains valid. The XPath expression may be
variabilized.
You will then return to the normal procedure, except that instead of carrying out the validation on the
entire server response, it will be done only on the part specified by the XPath expression.
To create a response validator using XPath:
1. Create a validator.
2. Select the option "On a particular node".
3. Click on the magnifying glass next to the text field below and select the XML node to be validated.
125
Design
4. Click "OK". The XPath expression for the selected node is displayed in the text field.
5. Select the text to be validated by clicking on the magnifying glass next to the text field below.
Warning
Response validations on XML nodes are resource-hungry operations. Only use this type of
validation if absolutely necessary.
Extracting variables in an XML response
The procedure for extracting variables in XML-format response is almost identical to the standard
procedure. For details on extracting variables in a standard HTTP request, see the section of the
documentation on extracting variables.
Variable extractors may be defined on an XML node.
To create a variable extractor using XPath:
1. Create an extractor.
2. Check the "XPath expression" checkbox.
3. Click on the magnifying glass next to the text field, then select the XML node to be extracted.
4. Click "OK". The XPath expression for the selected node appears in the text field.
5. Define your extractor on the XML node's text.
The following screen shots show the normal and advanced variable extraction modes. The red frames
highlight the parts that change in the case of an XML request.
• In normal mode:
126
Design
• In advanced mode:
127
Design
Warning
Extracting variables on an XML node are resource-hungry operations. Only use this type of
extraction if absolutely necessary.
Adobe Flex/AMF requests

Overview
AMF is a binary, client-server data transfer protocol used by certain Adobe Flash applications. The optional
AMF (Action Message Format) module allows you to load test Adobe Flash applications developed using
Adobe Flex technology, and using the AMF application protocol.
There are several variants of the AMF binary protocol:
• AMF0: This version is used in Flex applications written in ActionScript 1.0 and 2.0.
• AMF3: Adobe introduced this protocol, very similar to AMF0, from ActionScript 3.0 onwards. The
protocol allows the exchange of objects created by the application's developer between the client and
server.
Note
Managing AMF requests requires the purchase of the optional Adobe FLEX/AMF XML module.
This module is included in the demo version of NeoLoad.
Dependent libraries
128
Design
When recording AMF3 requests, depending on the server-side implementation, the Java classes of the
objects exchanged have to be declared in NeoLoad. See the documentation relating to managing AMF
libraries for more information.
Recording
The diagram below shows how the Adobe Flex/AMF module functions during the recording:
The binary data exchanged between the client and server transit via the recording proxy. It's during this
transit that the Adobe Flex/AMF module analyzes and decodes the requests. Once they've been translated
into XML, the requests are inserted in the project.
Execution
The diagram below shows how the Adobe Flex/AMF module functions when a test is run:
The variables in the XML request are calculated and the module's engine translates the XML into binary
data, which is then sent to the server. The binary response received is translated into XML, after which
the validity checks and variable extractors in the played request are executed.
AMF streaming
In addition to the standard request/response exchange, the AMF protocol also can be used in streaming.
In this case, the server is responsible for sending AMF packets to the connected client in real time.
NeoLoad natively handles Push technologies, including AMF streaming. For more information on the
Push technologies supported by NeoLoad, see the section called “Push Frameworks” and the section called
“AMF Streaming”. For more information on streaming, see the section called “Streaming Requests”.
129
Design
Lastly, an example can be viewed in the Adobe Flex/AMF: Handling polling and streaming tutorial.
When the recording ends, the AMF libraries declaration panel is displayed if any Java classes are missing:
• Depending on the server-side implementation of the Adobe Flex/AMF application being tested, it may
be necessary to declare some AMF libraries to ensure the successful recording and playback of the AMF
requests. Please see the AMF libraries manager documentation for more information.
To declare the missing AMF Java libraries (XML and JAR files):
1. Click on the " + " button to open the file explorer.
2. Select the XML and/or JAR files to be loaded, then click "Select". Repeat the operation as many
times as required.
3. A message confirms whether the declaration has been successful or not. Whenever an error occurs,
make sure that all the necessary AMF Java libraries have been declared.
Once all the necessary libraries have been declared, the following screen is displayed:
130
Design
Declaring the AMF Java libraries at the end of the recording must be done to ensure successful playback
of all the recorded requests.
• The missing AMF Java libraries may be declared later.
• Declaring AMF Java libraries is done in the project's AMF library manager, which can be accessed
through the project preferences.
The AMF requests that are missing an AMF Java library are identified by a warning symbol:
Recording SSL-secure Adobe Flex/AMF requests

To record SSL-secure Adobe Flex/AMF requests, the NeoLoad SSL certificate must be imported into the
web browser. The Adobe Flash plug-in checks the browser's certificates and decides whether or not to
authorize the Flash application to communicate with the server.
Importing the SSL certificate tells the browser's Adobe Flash plug-in that the NeoLoad recording proxy
can be trusted.
The certificate is available:
• on recording: When the browser asks you to accept the certificate, it often gives you the option of
importing it.
131
Design
• on the hard disk, in <NeoLoad Home>/conf/neoload.ssl.proxy.certificate.cer: It's

sometimes possible to import a certificate in file form via the browser's options menu.
This simple procedure is unique to each browser. This is the procedure for importing the NeoLoad
certificate in Internet Explorer:
1. Open Internet Explorer > Tools > Internet Options > Content >
Certificates.
2. Click on the "Import" button.
3. Select the <NeoLoad Home>/conf/neoload.ssl.proxy.certificate.cer file.
4. Follow the Certificate Import Wizard through to the finish.
5. Internet Explorer should notify you that the certificate has been successfully imported.
For other browsers, see the relevant documentation for details on importing certificates.
Recording requests with an Adobe AIR application

Introduction
Adobe AIR (Adobe Integrated Runtime) is a technology developed by the Adobe Corporation. NeoLoad
supports Adobe AIR applications that communicate with the server using the HTTP protocol.
Prerequisites
The application must communicate with the remote server using the HTTP protocol.
Configuring the recording and proxy settings

The following procedures describes how to configure the machine with or without Internet Explorer and
how to record the HTTP requests sent by an Adobe AIR application.
Procedure 6.9. Configuring the proxy settings using Internet Explorer

1. Open Internet Explorer.
2. Click "Tools" > "Internet options".
3. Click on the "Connections" tab.
4. Click on the "LAN settings" button.
5. Check the "Use a proxy server for your LAN...". If proxy settings already exist, see
the section called “Proxy Settings”
6. Click on the "Advanced" button and set the proxy ("localhost" : "8090" by default). For more details,
see the section called “Manually configuring the recording proxy settings”
The following procedure describes how to configure the proxy settings on a Windows machine that does
not have Internet Explorer installed.
Procedure 6.10. Configuring the proxy settings without Internet Explorer

1. Click on the "Windows" icon in the taskbar.
132
Design
2. Click "Control panel" > "Network and Internet Connections" > "Internet
Options".
3. Then follow steps 3 through 6 in the Configuring the proxy settings using Internet Explorer procedure.
Once the proxy settings have been configured correctly, continue as follows:
Procedure 6.11. Recording the Adobe AIR application's HTTP requests once the
proxy is configured
1. Launch NeoLoad.
2. Make sure the previously-configured proxy setting match those in "Edit" > "Preferences" >
"Global Settings" > "HTTP Recorder".
3. Create a new project or open an existing one.
4. Un-check the "Launch browser..." check box, then click "OK" to start recording
5. Launch the Adobe AIR application and record the actions you require.
6. Stop the recording. The recorded virtual user contains the HTTP requests sent by the Adobe AIR
application.
Note
The original proxy settings must be restored manually.
Identifiers handled by NeoLoad

automatically handles the following Adobe Flex/AMF identifiers:
• clientId
• messageId
• DSId
• responseURI
Note
The clientId and DSId can be handled manually by replacing their values with a variable.
User interface

133
Design


134
Design
Warning
135
Design
variabilized.
Warning
136
Design

• In normal mode:
137
Design
Warning
Adobe RTMP Requests

Overview
RTMP is a binary client-server data transfer protocol used by certain Adobe Flash applications. The
optional Adobe RTMP (Real Time Messaging Protocol) module allows you to load test Adobe Flash
applications programmed using the Adobe RTMP technology.
There are several versions of the RTMP binary protocol:
• RTMP, the basic data transfer protocol that works on top of TCP/IP;
• RTMPT, RTMP protocol encapsulated within the HTTP protocol requests/responses;
• RTMPS, identical to RTMPT but using HTTPS.
• RTMPE, RTMP protocol encrypted using proprietary Adobe algorithms. This protocol is not supported
by NeoLoad.
Note
To be able to handle RTMP requests, you will need to purchase the optional Adobe RTMP and
Adobe AMF modules. These modules are included in the demo version of NeoLoad.
138
Design
Warning
Recording a RTMP application in NeoLoad is subject to certain limitations. See the recording
limitations for more information.
Dependent libraries
When recording RTMP-type requests, you will need to load the Java classes for the objects exchanged.
For more information, see the documentation on managing RTMP libraries.
Recording
The following diagram shows how the Adobe RTMP module works during recording:
The RTMP data exchanged between the client and server is captured by NeoLoad. The Adobe RTMP
module comes into play, analyzing and decoding the requests. Once translated into XML, the requests are
inserted in the project.
Runtime
The following diagram shows how the Adobe RTMP module works during a test run:
The XML request's variables are evaluated and the module's engine translates the XML to binary data.
This data is then sent to the server. The binary response received is translated into XML and the validity
checks and variable extractors of the played request are executed.
139
Design
RTMP channel
RTMP channels are requests with special characteristics:
• The client does not send any requests, the channel being created upon connecting to the server.
• The server sends multiple responses via the channel.
• It is identified by a specific icon in the virtual user actions.
The way these requests behave has an impact on the virtual user's design:
• the RTMP channel's activity is suspended pending the next server response, that is to say it prevents the
virtual user continuing its execution thread as long as the response has not been received.
• Each time a response is received, the variable extractors and assertions placed on the request are
executed.
At the end of recording, NeoLoad detects the presence of the RTMP channel and offers to create a new
version of the virtual user. This is an example of a virtual user created with an RTMP channel:
The RTMPChannel_1 logical action is used to execute the RTMP channel in a secondary execution
channel in the virtual user. For more information, see the documentation on the Fork logical action.
NeoLoad natively handles Push technologies, including RTMP. For more details on the Push technologies
supported by NeoLoad, refer to the section called “Push Frameworks” and the section called “RTMP”.
For more details on streaming, see the section called “Streaming Requests”.
At the end of recording, the JAR declaration panel is displayed if any externalizable objects have missing
Java classes:
140
Design
• Externalizable objects (which extend java.io.Externalizable in Java) are objects that are
responsible for saving and restoring the contents of their instances themselves.
• All the classes for the externalizable objects sent must be loaded.
• This panel only displays part of the missing classes; not all the missing classes can be resolved.
To declare the missing Java RTMP libraries (JAR files), follow this procedure:
1. Open the file explorer by clicking the "+" button.
2. Select the JAR files to be loaded, then click "Select". Repeat the operation as many times as is
necessary.
3. A message confirms the declaration. If the operation fails, make sure that all the required Java RTMP
libraries have been declared.
When the libraries have been successfully declared, the following screen appears:
141
Design
Declaring the Java RTMP libraries at the end of recording is a compulsory step if all the requests are to
be played back.
• You may declare missing Java RTMP libraries at a later stage.
• Declaring Java RTMP libraries is carried out in the project's RTMP libraries manager in the project
preferences.
RTMP requests with missing Java RTMP libraries are identified by a small "Warning" symbol:
NeoLoad then offers to create a modified virtual user. This step is necessary because the virtual user cannot
be simulated in its present state. For more details on the modifications NeoLoad automatically proposes,
see the section called “RTMP”
142
Design
Recording SSL-secure Adobe RTMPT requests

Note
This section only concerns the RTMPT protocol (RTMP encapsulated in the HTTP protocol).
The NeoLoad SSL certificate must be imported into the browser in order to record SSL-secure Adobe
RTMP requests. The Adobe Flash plug-in checks the browser's certificates and decides whether or not to
authorize the Flash application to communicate with the server.
Importing the SSL certificate instructs the browser's Adobe Flash plug-in to trust the NeoLoad recording
proxy (Trusted).
The certificate is available:
• on recording: when the browser asks you to accept the certificate, it also asks you if you want to import it;
• on the hard disk, in <NeoLoad Home>/conf/neoload.ssl.proxy.certificate.cer.

Often, a certificate may be imported in file form via the browser's options.
This procedure is specific to each browser. This is the procedure for importing the NeoLoad certificate
in Internet Explorer:
1. Open "Internet Explorer > Tools > Internet Options > Content >
Certificates".
2. Click on the "Import" button.
3. Select the <NeoLoad Home>/conf/neoload.ssl.proxy.certificate.cer file.
4. Follow the import wizard's instructions through to the finish.
5. Internet Explorer should confirm that the certificate has been successfully imported.
For other browsers, refer to the documentation provided with the browser to find out how to import a
certificate.
Identifiers handled by NeoLoad

automatically handles the following Adobe Flex/AMF identifiers:
• clientId
• messageId
• DSId
• responseURI
Note
The clientId and DSId can be handled manually by replacing their values with a variable.
User interface
143
Design

144
Design
Warning
145
Design
variabilized.
Warning
146
Design

• In normal mode:
147
Design
Warning
Google Web Toolkit requests

Overview
GWT (Google Web Toolkit) is the AJAX framework developed by Google. It allows asynchronous remote
procedure calls to be executed between the client and server, using GWT-RPC (Remote Procedure Call)
procedure: the resulting data exchange is binary, encapsulated within the HTTP protocol.
The GWT (Google Web Toolkit) module allows you to load test applications programmed with the GWT
framework and using the GWT-RPC protocol.
Note
To be able to handle GWT requests, you will need to purchase the optional Google Web Toolkit
module. This module is included in the demo version of NeoLoad.
Dependant libraries
When recording GWT-type requests, you need to load the Java classes for the objects being exchanged,
as well as the client interfaces for the called services. For more information, see the documentation on
managing GWT libraries.
Recording
148
Design
The following diagram shows how the Google Web Toolkit module works during the recording:
The binary data exchanged between the client and server pass through the recording proxy. The Google
Web Toolkit module comes into play as the data travels through the proxy, analyzing and decoding the
requests. Once translated into XML, the requests are inserted in the project.
Execution
The following diagram shows how the Google Web Toolkit module works during a test run:
This data is then sent to the server. The binary response received is translated into XML and the validations
and variable extractors of the played request are executed.
Post-recording wizard
When the recording is finished, and if there are Java classes missing, the JAR declaration pane is displayed:
149
Design
• You need to load the Java classes for the objects being exchanged, as well as the client interfaces for
the called services.
• This pane only displays part of the missing classes; not all the missing classes can be resolved.
To declare the missing GWT Java libraries (JAR files), follow this procedure:
necessary.
3. A message confirms the declaration. If the operation fails, make sure that all the required GWT Java
libraries have been declared.
If the declaration has been a success, the following screen appears:
Declaring the GWT Java libraries at the end of recording is a compulsory step if all the requests are to
be played back.
• You may declare missing GWT Java libraries at a later stage.
150
Design
• Declaring GWT libraries is carried out in the project's GWT libraries manager in the project preferences.
GWT requests with missing GWT Java libraries are identified by a small "Warning" symbol:
User interface

151
Design


Warning
152
Design
variabilized.
153
Design
Warning
• In normal mode:
154
Design
155
Design
Warning
Java Serialization Requests

Overview
Java Serialization on top of the HTTP protocol allows remote service calls to be executed between the
client and server using specific frameworks such as Spring Remoting (Spring's HTTP Invoker). The data
exchange is carried out in binary and encapsulated in the HTTP protocol.
The Java Serialization module allows you to load test web applications programmed in Java and using
specific frameworks such as Spring Remoting (Spring's HTTP Invoker).
Note
To be able to handle Java Serialization requests, you will need to purchase the optional Java
Serialization module. This module is included in the demo version of NeoLoad.
Warning
RMI over HTTP is not supported.
Dependent libraries
156
Design
When recording Java Serialization requests, you will need to load the Java classes for the objects
exchanged, as well as the client interfaces for the called services. For more information, see the
documentation on managing Java Serialization libraries.
Recording
The following diagram shows how the Java Serialization module works during recording:
The binary data exchanged between the client and server passes through the recording proxy. The Java
Serialization module comes into play as the data travels through the proxy, analyzing and decoding the
requests. Once translated into XML, the requests are inserted in the project.
Important
Only requests with the "Content-Type: application/x-java-serialized-
object" header are recorded.
Runtime
The following diagram shows how the Java Serialization module works during a test run:
This data is then sent to the server. The binary response received is translated into XML, after which the
validity checks and variable extractors in the played request are executed.
Recording a Java Serialization request

This section describes how to record the interaction between an existing Java client and the server.
157
Design
Procedure 6.12. To record a Java Serialization request:
1. Change the Java client settings so that it uses NeoLoad as a proxy:
• hostname: host name or IP address of the machine with the running NeoLoad controller.
• port: the HTTP recording port used by NeoLoad, default is 8090. This setting may be changed
in NeoLoad's preferences.
a. For a Java applet application: No modifications are required to record Java Serialization
requests.
b. For a Java application using JNLP: Configure the Java settings:
i. Open the Java settings in the Windows control panel.
ii. Select the General tab, then click on the Network settings button.
iii. Select Use proxy server and set the machine name as localhost and the NeoLoad
proxy port (default is 8090)
iv. Validate these settings and re-start your Java application before making a new recording.
c. For a standalone Java application: Configure the http.proxyHost and

http.proxyPort system properties.
For example, place the following code in your code:
System.setProperty("http.proxyHost", "localhost");
System.setProperty("http.proxyPort", "8090");
or modify the command line:
java -Dhttp.proxyHost=localhost -Dhttp.proxyPort=8090 ...
2. Launch NeoLoad
3. Begin a recording (see the section called “Recording a Test Scenario”). Since a standalone Java
application doesn't require a browser, we recommend you clear the "Launch browser" check box.
4. Launch the Java client. If everything is working correctly, the HTTP requests sent by the Java
application should be visible in NeoLoad.
5. Stop recording.
At the end of recording, the JAR declaration panel is displayed if any Java classes or JAR files are missing:
158
Design
• All the classes for the Java objects exchanged between the client and server, as well as the JARs for the
framework used to transport the customized Java objects must be loaded.
• This panel only displays part of the missing classes; not all the missing classes can be resolved.
To declare the missing Java Serialization libraries (JAR files), follow this procedure:
necessary.
3. A message confirms the declaration. If the operation fails, make sure that all the required Java
Serialization libraries have been declared.
When the libraries have been successfully declared, the following screen appears:
159
Design
Declaring the Java Serialization libraries at the end of recording is a compulsory step if all the requests
are to be played back.
• You may declare missing Java Serialization libraries at a later stage.
• Declaring Java Serialization libraries is carried out in the project's Java Serialization libraries manager
in the project preferences.
Java Serialization requests with missing Java Serialization libraries are identified by a small "Warning"
symbol:
User interface
160
Design


161
Design
Warning
162
Design
variabilized.
Warning
163
Design

• In normal mode:
164
Design
Warning
Polling Requests
Overview
Polling is a mechanism used by the Push technology whereby a request is sent by the client to the server
at regular intervals. In return, the server updates the status of each connected client. Between two polling
requests, the server stores the updates sent to the client in its memory until the next polling request is
received.
NeoLoad uses a special request to represent a polling request in virtual user profiles.
NeoLoad handles "long polling" in the same way as polling.
Note
Using polling requires the "Push" module, which is licensed.
Polling request specificities

In NeoLoad, all the polling requests in a recording are represented by a single polling request. In addition
to the normal parameters for a standard request, a polling request:
165
Design
• is a multi-response request
• is a Push message container
• contains a rule to calculate the response time
Multi-response request
At the end of recording using a Push framework, NeoLoad creates a copy of the recorded virtual user.
This copy is modified so that the polling requests can be handled correctly (see the section called
“Push Frameworks”). A single, special request replaces all the polling requests captured in the recording
containing all the responses received for each polling request. In a polling request's "Advanced" section,
the "Recorded response" tab shows a list of all the responses received.
This list allows you to view all the responses received. When a response is selected, its content is displayed
on the right. The search field allows you to search for text contained in the responses. When the search
text is entered, the response list is filtered to leave only those responses containing the searched-for text.
Furthermore, each occurrence of the text is underlined; the next / previous buttons allow you to browse
the occurrences.
Push message container

When a polling request is used in a profile, numerous updates are received from the server in the responses
to the request. NeoLoad provides an easy way to carry out actions according to the server's responses.
For more details on Push message handling, see the section called “Push Messages”.
166
Design
Response time calculation

The request defines the way the response time to each of the request's Push messages is calculated.
For more details on calculating Push message response times, see the section called “Push message
response times”.
Creating a polling request

Normally, polling requests are created automatically by NeoLoad. At the end of the recording, NeoLoad
automatically detects the polling requests and groups them into a single request (see polling in Push
frameworks).
You may create a polling request manually in the interface by right-clicking on a request container and
selecting Insert as child / Push Action / <Framework> request .
167
Design
Streaming Requests
Overview
Streaming is a mechanism used by the Push technology whereby a blocking request is sent by the client to
the server. In other words, the client never completely finishes reading the server's response to the request,
the server sending back several separate response messages in the same response flow.
NeoLoad uses a special request to represent a streaming request in virtual user profiles.
Note
Using streaming requires the "Push" module, which is licensed.
Streaming request specificities

In NeoLoad, all the responses to a streaming request in a recording are represented by a single streaming
request. In addition to the normal parameters for a standard request, a streaming request:
• is a blocking request
• is a multi-response request
• is a Push message container
• contains a rule to calculate the response time
Holding request
By default, a streaming request blocks the connection until the server closes the socket. You may
also define the stop conditions for streaming. When the stop conditions are fulfilled, NeoLoad closes the
streaming connection and moves on to the next action.
168
Design
Multi-response request
By definition, a streaming request contains a number of server responses. The browser issues a single
request and, in return, receives several updates. In the streaming request's Advanced section, the
Recorded response tab shows a list of all the responses received.
169
Design
This list allows you to view all the responses received. When a response is selected, its content is displayed
on the right. The search field allows you to search for text contained in the responses. When the search
text is entered, the response list is filtered to leave only those responses containing the searched-for text.
Furthermore, each occurrence of the text is underlined; the next / previous buttons allow you to browse
the occurrences.
During playback, the variable extractors and assertions placed on this request are executed for each
response received.
Push message container

For each framework that supports streaming, NeoLoad is able to separate the response messages sent by
the server, thus allowing it to handle the actions to be carried out upon the arrival of each message.
For more details on handling Push messages, see the section called “Push Messages”.
Response time calculation

The request defines the way the response time to each of the request's Push messages is calculated.
For more details on calculating Push message response times, see the section called “Push message
response times”.
170
Design
Creating a streaming request

Streaming requests are created automatically on recording for those frameworks that are supported.
You may create a streaming request manually in the interface by right-clicking on a request container and
selecting Insert as child / Push Action / <Framework> request .
171
Design
Push Messages
Overview
Using Push technologies (polling and streaming) with NeoLoad requires an optional module (Push
module).
When using a Push framework (see the section called “Push Frameworks”), all the application's updates
are carried out via the Push channel, whether by polling or streaming. NeoLoad provides a mechanism to
simplify the creation of user profiles so that certain actions are carried out according to the type of response
received via the Push channel. Each type of response configured in NeoLoad is called a Push message.
You may only define Push Messages in polling or streaming requests.
172
Design
Defining a Push message
A Push message is a container of actions that defines actions or transactions to be executed when the
message is received.
A message is defined by the list of conditions that must be fulfilled for it to be executed. When a server
response is received via the Push channel, NeoLoad applies the message rules that have been defined and
executes the messages for which the conditions are fulfilled.
There are three types of execution conditions:
• Classname
This option is only available for XML (AMF, RTMP, RTMPT) -type Push frameworks. The message
executes if a response object is of the specified class's type. Where the response object is a table or
collection, NeoLoad checks each of the top-level children.
Where the object is a container recognized by the framework, the algorithm is applied on the contained
object and not on the envelope.
• Default
173
Design
The message executes if no other message has been executed for the response. A default message is not
compulsory in a Push request definition. If several default messages are defined for a same request, they
will all be executed if no other message fulfills the conditions.
• Conditions
The message is executed if the conditions are fulfilled.
The ${NL-MessageContent} variable is created automatically when a server response is received

and contains the character string representing the response. In the case of a polling request, a response
may contain several sub-responses (for example, if the server has accumulated several updates between
two polling requests). In this case, NeoLoad separates out each of the sub-responses. Each sub-response
is then processed as a separate response and the ${NL-MessageContent} variable contains a sub-
response to each successive call.
A condition comprises two operands and an operator. The operators are as follows:
# is equal to - true if the two operands have the same value
# is not equal to - true if the 2 operands do not have the same value
# contains - true if operand1 contains operand2
# does not contain - true if operand1 does not contain operand2
# starts with - true if operand1 starts with operand2, including where the 2 operands are equal.
# does not start with - true if operand1 does not start with operand2.
# ends with - true if operand1 ends with operand2, including where the 2 operands are equal.
# does not end with - true if operand1 does not end with operand2.
# matches the regular expression - true if operand1 matches the regular expression for
operand2.
# does not match the regular expression - true if operand1 does not match the regular
expression for operand2.
# is greater than - true if operand1 is greater than operand2.
# is greater than or equal to - true if operand1 is greater than, or equal to, operand2.
# is lesser than - true if operand1 is lesser than operand2.
# is lesser than or equal to - true if operand1 is lesser than, or equal to, operand2.
# exists - true if operand one is the name of a variable that does not have a nil value. Operand2
cannot be defined.
Each operand may be either a ${variableName} variable or a static string. In the case of the
exists operator, operand1 can only be a variableName variable name.
Several conditions may be used in a Push message. To add a condition, click on the "+" button under
the conditions table. You then need to configure whether the action is executed if all the conditions are
174
Design
true ("Match any of the following"), or if at least one of the conditions is true ("Match
all of the following").
Using messages in profiles

Each Push message is a container of actions that defines actions or transactions to be executed when the
message is received.
In the following case for example, the profile carries out a new subscription upon receiving a message of
the type flex.samples.marketdata.Stock.
Note
Since the Push message is executed in the same execution thread as the Push request, we
recommend placing all the actions for a message in a fork action to avoid interfering with the
polling or streaming request's execution.
Push message response times

NeoLoad calculates response times for Push messages. A message's response time is the time delay
between the moment the server decides to update the client and the moment the client receives the update.
Indeed, when using a Push framework, the request response time (delay between sending the request and
receiving the response) is fairly meaningless.
NeoLoad calculates the response time using a timestamp embedded in the server response. Depending on
the framework being used, the timestamp extraction needs to be configured manually.
Important
For the response times for Push message to be coherent, the load generators' and application
server's system clocks need to be synchronized.
AMF, RTMP and RTMPT frameworks

With AMF, RTMP or RTMPT, the timestamp in the server responses is in a standardized format. NeoLoad
automatically extracts the timestamp attribute from the received message. No special configuration is
required.
ICEfaces and Lightstreamer frameworks

With ICEfaces and Lightstreamer, the timestamp in the server responses is not supplied in a standardized
format. In these cases, the application's developer must integrate a mechanism in the application's code
175
Design
in order to retrieve this information. Once the timestamp has been embedded in the server responses, you
need to configure its extraction method in the Push request definition's advanced parameters. To extract
the timestamp, NeoLoad offers to define a regular expression for extraction and a value template to be
able to isolate the timestamp.
Regular expression used to extract the value: The regular expression must contain parentheses around
the parts to be extracted (valid example: timestamp="(\d+?)", invalid example: timestamp="\d
+?"). Refer to the Regular Expressions Guide for help on this subject.
Template used to construct the value: This is an arbitrary string with specific elements that refer to the
groups within the regular expression (a group is a dynamic portion of the regular expression, set between
parentheses): $0$ refers to the entire text matching the expression, $1$ refers to group 1, $2$ refers to
group 2, etc. Using an illegal group identifier will prevent extraction; this can happen, for example, when
parentheses are missing in the regular expression to be matched.
Advanced parameters
Variable extractors
A variable extractor set on a message works in exactly the same way as a variable extractor set on a response
to a request (see the section called “Variable Extractors”). The only difference is that you may select
176
Design
the response on which the extraction attempt will be carried out. Clicking on the response name opens
the response picker. In the picker, only those responses that fulfill the message condition are available.
Selecting a new response will cause the test value to be calculated using that response.
Validation
As with a request, an assertion can be set to validate a message. (see the section called “Validation”).
When configuring a content validation, the picker allows you to choose the message to work on to define
the assertion. In the picker, only those responses that fulfill the message condition are available.
177
Design
Validation
Allows you to add assertions to the server responses to check their validity. The validity of the content
returned by the server may be checked using the following criteria: delay, page size or page content.
Note
Validation cannot be applied to failed requests ( HTTP error, network error...).
178
Design
Duration
Specifies the maximum delay tolerated in ms.
Content length
Defines the exact, minimum and maximum sizes of the server response's body. HTTP header lengths are
disregarded. The default length is the length of the server response's content at the time of recording.
"Greater than" denotes greater than or equal to; "Lower than" denotes smaller than or equal to.
Reply content
Checks whether or not the server response contains a certain content. The server response is considered
valid if all the content conditions are satisfied.
Depending on the type of HTTP response, the validation can be based on:
• the response as a whole: the validation check will be carried out on the HTTP responses headers and
body. This is the default option.
• a particular node: the validation check will be carried out on one of the nodes in the response body.
This node is defined using an XPath expression. This option is only used for XML and HTML responses,
as well as for SOAP, GWT, Adobe Flex/AMF, Oracle Forms, Java Serialization and RTMP responses.
The conditions available are:
• contains: checks if the body of the server response contains the specified text (example: "<span
class="welcome">Welcome</span>").
• contains regular expression: checks if the body of the server response contains the specified regular
expression (example: "<span class="welcome">Welcome \w+ \w+ </span>").
Note that the content assertion may contain variables.
Please refer to the Regular Expressions Guide for help on regular expressions.
Variable Extractors
A variable extractor extracts a string from the server's response to the request and assigns the string to a
variable. The variable extractor features two operating modes, simple and advanced. In simple mode, the
user defines the string to be extracted; in advanced mode, the user can define more complex extractions
using regular expressions.
• Definition (Simple mode). Used to define the extractor.
179
Design
# Variable name. The name of the variable automatically created to contain the value extracted.
# Extract the value from. Extract the value from either the body, the headers of the server response
or the content of a NeoLoad variable. Extracting a variable from the content of another variable,
allows you to extract a content in several steps. First extract a part of the response based on a regular
expression, then use another regular expression to extract a part of that.
Note
The extractors are ordered and executed in the order they are defined. You can re-order the
extractors using the arrow buttons.
Extracting using an XPath expression is only available for HTML and XML responses, as
well as for SOAP, GWT, Adobe Flex/AMF, Oracle Forms, Java Serialization and RTMP
responses.
# Starts with. The phrase in the server response appearing immediately before the value to be
extracted.
# Followed by. The definition of the string's main body. The extracted string is the concatenation
of all the parts selected for extraction.
# Ends with. The phrase in the server response appearing immediately after the value to be extracted.
180
Design
# Occurrence to extract in the page. If the definition is matched more than once, select the
occurrence to be used. The default value is 1 (use the first occurrence) but you can choose to use a
random occurrence or all occurrences (useful with loops).
If you choose to process all the matched occurrences, the following variables are automatically
created:
# <VariableName>_matchNr - the number of occurrences found; can be 0.
# <VariableName>_n, where n = 1,2,3 etc - the strings as generated by the value template.
# <VariableName>_n_gm, where m=0,1,2 - the groups matching n
# <VariableName> - always attached to the default value
# <VariableName>_rand, random string from generated strings
# <VariableName>_rand_gm, where m=0,1,2 - the groups matching rand
# Value is HTML encoded. When this option is checked, the value will be decoded before being
placed in the variable. If the string extracted from the server response is start&end, the value
in the NeoLoad variable will be start&end if the option is checked, and start&end if the
option is checked.
Note
When switching to advanced mode, the definition is automatically converted from simple
to advanced.
# Stop extraction at first successful extraction. When this option is checked, the variable extractor
will stop its execution once the first extraction has been completed. This behavior is local to each
virtual user.
• Definition (Advanced mode). Extraction is carried out on the server response using a regular
expression.
# Variable name. The name of the variable automatically created to contain the value extracted.
181
Design
# Extract the value from. Extract the value from either the body of the server response, XML nodes
using XPath expression, the headers of the server response or the content of a NeoLoad variable.
Extracting a variable from the content of another variable, allows you to extract a content in several
steps. First extract a part of the response based on a regular expression, then use another regular
expression to extract a part of it.
Note
The extractors are ordered and executed in the order they are defined. You can re-order the
extractors using the arrow buttons.
Extracting using an XPath expression is only available for HTML and XML responses, as
well as for SOAP, GWT, Adobe Flex/AMF, Oracle Forms, Java Serialization and RTMP
responses.
# Regular expression to match. The regular expression used to extract the value. Within the
expression, the parts to be extracted must be enclosed in brackets (valid: value="(.+?)", invalid:
value=".+?"). Please refer to the Regular Expressions Guide for help on regular expressions.
# Occurrence to extract in the page. If the definition is matched more than once, select the
occurrence to be used. The default value is 1 (use the first occurrence) but you can choose to use a
random occurrence or all occurrences (useful with loops).
If you choose to process all the matched occurrences, the following variables are automatically
created:
# <VariableName>_matchNr - the number of occurrences found; can be 0.
# <VariableName>_n, where n = 1,2,3 etc - the strings as generated by the value template.
# <VariableName>_n_gm, where m=0,1,2 - the groups matching n
# <VariableName> - always attached to the default value
# <VariableName>_rand, random string from generated strings
# <VariableName>_rand_gm, where m=0,1,2 - the groups matching rand
# Value template. The template used to construct the value. This is an arbitrary string containing
special elements that refer to groups within the regular expression (a group is a dynamic portion of
the regular expression set within brackets): $0$ refers to the entire text matching the expression, $1$
refers to group 1, $2$ refers to group 2, and so on. Using an illegal group will cause the extraction to
fail and the value <NL-Illegal-groupIndex> will be set in the variable during the test. This
typically arises when no brackets are specified in the regular expression to be matched.
# Value is HTML encoded. When this option is checked, the value will be decoded before being
placed in the variable. If the string extracted from the server response is start&end, the value
in the NeoLoad variable will be start&end if the option is checked, and start&end if the
option is checked.
Note
When switching to simple mode, the last simple definition is used, since advanced-simple
conversion is impossible.
Examples
# Extracting from the server response body. Given the following content: Your order number
Mr Smith is:12345; and that the string to be extracted is '12345', to be used in a subsequent
request.
The variable extractor is defined thus:
# Variable name: 'MyVariable'

182
Design
# Extract from: 'Message body'
# Regular expression to be matched: 'Your order number(.+)? is:([0-9]+);'
# Value template: '$2$' as it's the order number that must be extracted and not the name of the person.
# Occurrence within the page: '1'
# Use $1$ to obtain the name. ($0$ would return the complete matched text: 'Your order number
Mr Smith is:12345;')
# Default value: '-1' for example.
# Extracting from the server response header: The variable extractor is defined thus:
# Extract from: 'Header'
# Regular expression to be matched: 'MyHeader: (.*)'
# Occurrence within page: '1'
# Value template:'$1$'
• Test. This tab allows you to test the variable extractor. Enter the text corresponding to the server
response in the text box. The "value extracted from page" field value contains the value
extracted from the page.
183
Design
• Errors. This panel allows you to specify the action to take if the definition is not matched in the
server response. Two choices are available:
# Set a default value for the variable
# Treat as an assertion failure, thus causing the request to be error-flagged in the test results.
• Response content. The server response's content. Only the text content (text/html, text/xml, ...) is
available.
184
Design
Advanced Parameters
The advanced parameters panel includes:
• Request headers. HTTP request headers. Existing headers may be edited or deleted or new headers
added. A variable may be used as a header value.
• Advanced settings.
# Request parameters. Specifies whether or not a sent request should include an equals character
after the parameter name if its value is empty (e.g.: a request may be sent as /page.jsp?
myparam= rather than /page.jsp?myparam).
# Advanced definition. Allows you to configure the referrer of the current request. The referrer is
the request containing the link to the current request. By default, the referrer is set during the recording
phase. You may alter the referrer by clicking on the "Change referrer" button. When altering
the referrer, make sure that the new referrer's request call precedes the current request's call in the
virtual user definition.
The referrer is used when a request is:
# a link or form extractor
In this case, NeoLoad fetches the link or form definition in the server's response to the referrer.
# a redirect
In this case, NeoLoad fetches the value of the Location header in the server's response to the
referrer.
185
Design
# Form charset. Denotes the charset used to encode the form parameters (UTF-8, ISO-8859-1, ...).
By default, NeoLoad uses an algorithm similar to the one used by web browsers to determine which
charset to use: NeoLoad uses the charset of the HTML page containing the form. If the charset is not
found, "ISO-8859-1" is used.
Do not confuse this charset, used to convert characters into bytes, with plain URL Character
Encoding, which converts, for example, the space character into %20. Specifically, URL Character
Encoding differs according to the charset used.
# Timestamp extractor. Used for certain Push requests (polling or streaming). For more details, see
the section called “Push message response times”
# Streaming stop conditions. Used for certain Push requests (streaming only). For more details, see
the section called “Streaming Requests”
• Variable extractors. Extracts a string from the server's response to this request and assigns the string
to a variable. See the section called “Variable Extractors”
• Recorded request. The request content that was recorded when recording the scenario.
• Recorded response. The response content that was returned by the server when recording the
scenario.
Shortcuts
You can use shortcuts from the Virtual User Profiles tree to quickly and easily access the requests and
pages in the current test results or in the Virtual User validation pane.
Note that the shortcut will only work if the Check Virtual User feature has been used or if the scenario
containing the request or page has been previously played in the project.
Procedure 6.13. Using a shortcut from the virtual user
1. In the tree, right-click on the node for the selected request or page.
2. The context-menu is displayed.
3. Two shortcuts are available:
• Select in validation window: selects the virtual user and the request in the validation
window. If the user hasn't yet been validated, its scenario is greyed out.
• Select in results pane: selects the request, page or container in the "Values" tab in the
"Results" section. If the current request does not appear in the results, a pop-up window warns
that the request could not be found.
186
Design
Logical Actions
NeoLoad provides a number of logical actions that can be used to add, for example, delays, loops and
containers to virtual users, to create more complex scenarios.
Delay
This action pauses the virtual user for a specified duration. The delay is expressed in milliseconds and may
be set as a NeoLoad variable (useful for random delays).
Loop
Used to iterate various items such as pages, the number of iterations being defined by the user. This number
may be a variable, in which case the variable will be evaluated once only, before the first iteration.
A variable named <MyLoopName>_counter is created within the loop containing the current iteration
number. This value starts at 1, for the first iteration, and is incremented by 1 at each next iteration.
187
Design
Note
Loop -type logical actions may be shared among several virtual users. See the documentation
on shared elements for more details.
While
The while action allows various items, such as web pages, to be iterated while a condition remains false.
A condition is composed of two operands and an operator. The operators are:
• Equals - true if the 2 operands have the same value
• Doesn't equal - true if the 2 operands do not have the same value
• Contains - true if operand1 contains operand2
• Doesn't contain - true if operand1 does not contain operand2
• Starts with - true if operand1 begins with operand2, including if the 2 operands are equal.
• Doesn't start with - true if operand1 does not begin with operand2.
• Ends with - true if operand1 ends with operand2, including if the 2 operands are equal.
• Doesn't end with - true if operand1 does not end with operand2.
• Matches regexp - true if operand1 verifies the regular expression of operand2.
• Doesn't match regexp - true if operand1 does not verify the regular expression of operand2.
• Greater than -true if operand1 is greater than operand2.
• Greater than or equal to - true if operand1 is greater than or equal to operand2.
• Lesser than - true if operand1 is lesser than operand2.
• Lesser than or equal to - true if operand1 is lesser than or equal to operand2.
• Exists - true if operand1 corresponds to a name of a variable whose value is not nil. Operand2 cannot
be defined.
Each operand may be a variable ${VariableName} or a static string. In the case of the Exists
operator, operand1 can only be a VariableName variable name.
Several conditions may be used within a while action. To add a condition, simply click on the "+" button
below the table of conditions. You must then specify whether the action is executed if all the conditions
are true (Resolve all the following items), or if at least one of them is true (Resolve one
of the following items).
188
Design
Note
While -type logical actions may be shared among several virtual users. See the documentation
on shared elements for more details.
If ... Then ... Else

The If ... Then ... Else action is used to execute conditional actions. When creating a conditional
action, two containers are created, Then and Else. If the condition is true, the actions in the Then
container are executed; if false, the actions in the Else container are executed. A condition is composed
of two operands and an operator. The operators are:
be defined.
189
Design
Several conditions may be used within an If ... Then ... Else action. To add a condition,
simply click on the "+" button below the table of conditions. You must then specify whether the action
is executed if all the conditions are true (Resolve all the following items), or if at least one
of them is true (Resolve one of the following items).
Variable Modifier
Using a Modify variable action, you can change the value of a variable defined in the configuration.
A variable's value can be changed (take next value) or the variable can be reset (reset to first value). This
action allows the variable's value to be changed without affecting its value change policy. For example,
you may change the value of the variable within a virtual user loop.
Specify the variable name on which the action will be performed. Use a name, such as "myVar", but not an
expression such as "${myVar}". Nevertheless, the name can be composed, for example "data_for_
${login}" if the variable "data_for_jsmith" is defined.
Containers
A container allows you to group certain actions, relating to a business action for example, for statistical
purposes. The container is viewed in the same way as other result actions such as web pages. Thus, the
user can obtain statistics including average time, hits/sec., etc..
190
Design
A pacing delay may be set on a container. The pacing delay is the minimum time a container must take
to execute. If the container's execution takes less time than the pacing time set, the virtual user will wait
until the end of the pacing time before continuing the scenario.
For example, if a container has a pacing of 30 seconds and the actual time to execute the actions in the
container is only 20 seconds, the virtual user will pause for 10 seconds before resuming. On the other hand,
if the actual time is 45 seconds, the virtual user will continue immediately.
Note
Container -type logical actions may be shared among several virtual users. See the
documentation on shared elements for more details.
Random Containers
A Random Container is used to specify pages to be played in a random sequence. All the requests
in a container may be played, or only some.
• Play all pages in random sequence. All the pages in the container will be played once, in random
sequence.
• Play a number of pages in random sequence. In this mode, the number of random pages to be
played may be selected. At each iteration, one of the pages within the container is chosen at random and
played. It is possible therefore that a page might be played more than once.
Note
Only the top-level actions are randomly executed. If a random container contains a container,
and this second container is played, all the actions within that container will be executed in their
correct sequence.
A pacing delay may be set on a random container. The pacing delay is the minimum time a container must
take to execute. If the container's execution takes less time than the pacing time set, then the virtual user
will wait until the end of the pacing time before continuing the scenario.
For example, if a random container has a pacing of 30 seconds and the actual time to execute the actions in
the container is only 20 seconds, the virtual user will pause for 10 seconds before resuming. On the other
hand, if the actual time is 45 seconds, the virtual user will continue immediately.
191
Design
Note
Random container -type logical actions may be shared among several virtual users. See the
documentation on shared elements for more details.
Try ... Catch

The Try ... Catch action is used to execute specific actions in the case of an error or validation
failure. A Try...Catch action can capture errors or assertions (validation errors) or both.
When creating a Try...Catch action, two containers are created: Try and Catch. All the actions in
the Try container are executed until an error or assertion occurs (depending on the action's configuration).
When an error or assertion occurs, the actions in the Catch container are executed.
Note
Within a Try container, the virtual user will not be halted upon the error or assertion's occurrence,
even if it is configured so to do.
Stop Virtual User

This action allows the virtual user to be stopped at a given point in the scenario. This can be especially
useful when combined with an If ... Then ... Else action, or Try ... Catch action. To
maintain a constant load on the application, NeoLoad immediately runs a new virtual user.
Fork
How it works
The Fork action is used to play actions in a different execution thread to the current one. This execution
thread is parallel to the main chain used by the virtual user. When the virtual user's main execution thread
stops, all the threads created using fork actions are immediately halted.
192
Design
In particular, this action can be used to modelize automatic actions played by the browser while the user
is using the web application normally. Let's take the example of an action played every x seconds on the
server to refresh a web component (Ajax, Flash plug-in...). This request must be made in parallel to the
standard scenario for the virtual user.
Fork -type logical actions may be shared among several virtual users. See the documentation on shared
elements for more details.
The case of variables

When NeoLoad variables are used inside a fork, they are shared for reading in all the execution threads.
This ensures communication of variables between the main execution thread and multiple secondary
execution threads.
If, in due course, two execution threads modify the same variable, each of the threads obtains its own
variable. This allows the use of the same variable extractors derived from the framework parameters in
several execution threads without having to worry about clashing values.
Lastly, in the case of same variables used in different execution threads, variables' visibility is based on
hierarchy: a fork can access variables that have been modified locally by its parent until such time as
it modifies them itself.
Limitations
When checking a virtual user, the actions played as part of a fork action appear in the list at the moment
they are executed. This can make reading the validation results more complicated, as the list will contain
several overlapping execution threads.
Wait Until
The Wait Until action pauses the current execution thread until certain conditions have been verified.
A condition is composed of two operands and an operator. The operators are:
193
Design
be defined.
You may also set a maximum timeout delay in milliseconds. Once this delay is timed out, the thread is
restarted. The following action is then executed, even if the conditions have not been verified.
JavaScript
How it works
NeoLoad allows the execution of JavaScript within virtual users, which means you may insert a JavaScript
action when designing a virtual user. The code used may invoke common JavaScript functions declared
in the NeoLoad JavaScript libraries.
194
Design
What you can do
The NeoLoad API is mainly used to manipulate NeoLoad variables and set up cookies for the current
virtual user. Basic JavaScript functions allow the handling of strings and dates, calculation etc...
the section called “API overview” describes the NeoLoad API's features.
What you cannot do
The script does not run within the context of the HTML request, so manipulating a request response's
DOM tree is impossible. Consequently, functions built into browsers for extracting or manipulating the
HTML document are not included.
The following is a non-exhaustive list of functions or objects that are not supported:
• window
• document (of which document.cookie, document.forms[0],
document.getElementById(), ...)
• navigator
• alert()
• confirm()
• ...
Note that scripts using these objects compile correctly but their running will halt when it reaches the non-
supported object.
JavaScript actions
A JavaScript action may be added to a virtual user's definition. A JavaScript action is identified by a name
and a description and contains the script to be executed.
Creating a JavaScript action
The procedure is as follows:
Procedure 6.14. Create a JavaScript action
1. In the "Design" section, click on the "Virtual User" tab.
2. Select the JavaScript logical action.
3. Drag and drop the action at the desired point in the virtual users tree.
195
Design
NeoLoad creates the action using an outline script, which you can either adapt to your requirements or
delete to begin a new script.
Editing a JavaScript action

Any changes made to a script during the editing process must be validated for them to be applied.
Alternatively, changes may be canceled prior to validation, in which case the last script version saved will
be reloaded. Scripts may be edited directly in the project files ('scripts' directory). The content of the edited
file can then be reloaded into NeoLoad by clicking on the "Reload" button.
You may compile your JavaScript scripts prior to running. Compiling will check the script syntax (missing
parentheses...) but not its validity (method names ...).
Errors
During a test, a JavaScript action will be flagged as an error in the following cases:
196
Design
• The script doesn't compile (syntax error)

• The script is invalid (a method does not exist)
• The script calls the API's context.fail(message) method.
JavaScript actions are systematically displayed during the virtual user checking process and will appear
in the error table if the script has been error-flagged.
JavaScript libraries
JavaScript libraries allow you to create functions that can be used in all the virtual user scripts. Libraries
not only allow code sharing between several scripts, they also help reduce memory usage on the load
generators, since the code stored in the libraries is shared by the users, whereas code contained in scripts is
loaded into memory for each virtual user. It is therefore recommended, wherever possible, to use functions
whose code is stored in a library.
Creating a JavaScript library
A JavaScript library is identified by its name and library file. You may use an existing file or create a new,
empty file. Each library may contain one or several JavaScript functions.
Procedure 6.15. Create a JavaScript library
1. Select the Edit / JS Libraries menu item.
2. Click on "New library"
197
Design
3. In the following wizard, enter the name of the library.
4. Choose either to create a new library or use an existing file, whichever is appropriate.
5. Confirm the choice to exit the wizard.
6. Select the created library in the library list.
Editing a JavaScript library

Access the libraries via the "Edit / JS Libraries" menu item.
If you edit the file using an external text editor, use the 'Reload' button to reload the file into the NeoLoad
interface.
Use the "Compile" button to compile your JavaScript libraries prior to execution. Compiling will check
the script syntax (missing parentheses...) but not its validity (call method names ...).
API overview
This section gives an overview of the NeoLoad API. Please refer to the API documentation for more
detailed information.
Execution context
NeoLoad provides an execution context for each script in order to manipulate variables, errors and cookies:
the predefined context variable which allows procedures to be carried out on the virtual user being run.
Please see the documentation for the API RuntimeContext object.
Managing Variables
NeoLoad features a Variable Manager, which allows the user to retrieve the value of a variable, create a
new variable, or increment the value of a variable defined in NeoLoad. The Variable Manager is accessed
via the context.variableManager context.
For example, the script below retrieves the value of a NeoLoad variable, changes the value, and uses the
new value to create a new variable. This new variable may now be integrated into the virtual user's actions,
for example inserted in a form.
var varMng = context.variableManager;

var searchID = varMng.getValue("searchID");
varMng.setValue("newSearchID",parseInt(searchID)+1);
Please see the documentation for the API VariableManager object.
Logger
You may use the logger to record events linked to a script's execution. It will write both to the load
generator's log file ("loadGenerator.log.00x" in the logs folder, accessed via the "Help / Open logs
folder" menu item) and to the NeoLoad interface in the case of an error. There are 5 logging levels:
• FATAL
• ERROR
198
Design
• WARN
• INFO
• DEBUG
You may set the maximum level to be used in the project's preferences:
When checking a virtual user, the DEBUG level is selected automatically.
The example below is a script writing an error message to the logs.
logger.error("Invalid value: "+myvar);
Please see the documentation for the API Logger object.
Error management
When executing a JavaScript script, it is possible both to error-flag the action and stop its execution. The
error is then displayed in the test results. The error contains the error message and the appropriate-level
logs.
The example below is a script flagging an action as an error.
context.currentVU.fail("Invalid value: "+myvar);
Please see the documentation for the API VirtualUser object.
Adding a cookie
The API also allows the user to add a cookie for a given server while a virtual user is running.
Please see the documentation for the API VirtualUser object.
199
Design
Script example
var varMng = context.variableManager;

// Retrieves the searchID variable extracted from a request preceding this JavaScri
var searchID = varMng.getValue("searchID");
// Log the searchID value in debug mode
logger.debug("searchID="+searchID);
// Error management if searchID variable is missing

if(!searchID) {
// Stop script execution and prompt the NeoLoad error
context.fail("variable SearchID not found");
}
// Create a new cookie for server 'myServer_80'

context.currentVU.setCookieForServer(
"myServer_80",
"cookieName="+searchID+"; Expires=Sat, 30-Sep-2006 21:03:07 GMT; path=/"
);
// Create a new runtime variable named 'newSearchID'

// Note: all NeoLoad variables are character strings,
// they may need to be converted using the following
// methods parseInt(), parseFloat(),...
var newSearchID = parseInt(searchID)+1;
varMng.setValue("newSearchID",newSearchID);
Java Libraries
NeoLoad allows you to use Java classes and methods in JavaScript actions. To use a Java library, simply
copy the .JAR files into the <neoload-project>/lib/jslib directory. The added files will be
automatically taken into account.
The class names must be fully qualified within the JavaScript, (even for the Java classes like
java.util.List) and preceded by "Packages.".
For example:
var myObj = new Packages.com.company.MyClass();

var result = myObj.compute(myArg);
var result2 = Packages.com.company.MyClass.someStaticMethod(result);
Rendezvous
Using rendezvous points
NeoLoad allows you to test your web application's response times under specific loads.
Rendezvous points are used to synchronize a number of virtual users to carry out the same task at precisely
the same moment, in order to create an intense load on the server at a specific point in the application
being tested.
200
Design
About rendezvous
When running a test scenario, it can be useful to ensure that a certain number of virtual users carry out
certain tasks simultaneously. This can be done using rendezvous points. A rendezvous point allows you
to create a specific load spike at a given point in the virtual user's execution.
For example, in a web application for managing bank accounts, you might want to assess its performance
when ten users simultaneously check their account balance. To simulate this functional case, you must
force the virtual users to carry out the task at exactly the same time.
A rendezvous works a little like the line at a fairground ride:
• Users enter the line and wait their turn. While they're in the line, they're not using the other rides.
• When a car arrives, it relieves the line of a number of users equal to the car's capacity. It's what is known
as the release policy.
• If the car takes too long to arrive, users will leave the line. This is a timeout.
Creating a rendezvous
To create a rendezvous, you need to have read and understood the following:
• Creating a virtual user
• Logical actions
To create a rendezvous point:
1. Go the "Virtual Users" tab in the "Design" section.
2. Right-click on the virtual user or container into which you want to insert the rendezvous.
3. Select "Insert in", then "Rendezvous".
Defining the attributes of a rendezvous action
A rendezvous action has the following attributes:
• Name: identifies the rendezvous specified by the action.
• Description: completes the rendezvous definition, for information purposes.
A rendezvous point is identified by its name. Several RendezVous logical actions may use the same
rendezvous point and for that, they must use the same name.
Once the rendezvous points have been configured, you must configure the rendezvous's behavior when
the scenario is run.
201
Design
Configuring a scenario's rendezvous
Overview
A rendezvous' behavior is configured for each scenario. Its attributes are:
• A state: enabled or disabled. A rendezvous may be enabled/disabled.
• A release policy: defines the condition to be met before the users lined up at the rendezvous
are released
There is a one-to-one relationship between a rendezvous point's name and a rendezvous. Each unique
rendezvous action name corresponds to one specific rendezvous.
Enabling/disabling a rendezvous
To enable or disable a rendezvous:
1. Go to the "Scenarios" tab in the project's "Runtime" section.
2. Select the scenario to be changed.
3. Click "Advanced...".
4. In the displayed window, select "Rendezvous policy".
5. In the list of rendezvous, check or un-check the rendezvous to enable or disable it.
Alternatively:
1. Go to the "Virtual Users" tab in the project's "Design" section.
2. Select the rendezvous action you want to use.
3. Click on the "Edit the scenario's rendezvous policy" blue link.
4. If the project contains several scenarios, select the scenario you want to change and click "OK".
5. In the list of rendezvous, check or un-check the rendezvous to enable or disable it.
202
Design
Note
If NeoLoad displays a warning that the rendezvous is not associated with the selected scenario,
it means that the virtual user containing the rendezvous is not in one of the populations linked
to the scenario.
A scenario contains populations; populations contain virtual users; a virtual user contains
rendezvous points.
Defining a rendezvous' release policy

A release policy is defined according to the following attributes:
• A Release Condition: the condition that must be met before the users lined up at a rendezvous
are released.
• A Timeout: the maximum wait time between two consecutive users arriving at the rendezvous. If
no user arrives at the rendezvous within that time period, all the users lined up at the rendezvous are
released. The timeout is expressed in seconds.
Note
The timeout is local to the load generator. When a rendezvous on a load generator times out,
only the users lined up at the rendezvous on that load generator will be released. Other load
generators with users lined up at the same rendezvous are not affected.
The following release conditions can be set:
• Release when XX% of the users have arrived at the rendezvous: XX is the ratio
of the number of users lined up at the rendezvous against the number of users currently being executed
and eligible for the rendezvous. A user is eligible for the rendezvous if its execution chain contains a
rendezvous point with the same name as the rendezvous.
• Release when XX users have arrived at the rendezvous: XX is a fixed number

of users.
• Release manually: When this option is selected, you will need to release the virtual users using
JavaScript actions. For more information, see the documentation on the rendezvous JavaScript API.
Note
Fulfillment of the release condition is based on the overall state of the test's rendezvous
including when several load generators are used.
For example, a test includes a rendezvous that releases when 100 users have arrived, and the
scenario is being run using two load generators, LG1 and LG2. LG1 and LG2 have 30 and 70
lined-up users respectively. The condition is fulfilled, since 30 + 70 = 100. The controller will
send a release order to each of the load generators, thus releasing a total of 100 users spread
between the two load generators.
Frequently-asked questions
How are the released users allocated?
When the controller decides to release users from a rendezvous, it dispatches the number of users to be
released equally between load generators, based on their current load.
203
Design
Several users have the same rendezvous (rendezvous points with the same name). How are the
lined-up users released?
Each load generator maintains an arrivals list of virtual users for each rendezvous. Several rendezvous
points with the same name are considered as being the one and same rendezvous. Therefore, the users are
released in the same order as they arrived at the rendezvous.
Frameworks
Concept
In NeoLoad, "dynamic parameters" refers to parameters that are dynamically generated by the server and
used in several requests within a scenario. For example, this type of parameter may be used to manage user
sessions or preserve the browsing status at any given time. These parameters, calculated by the server, can
be inserted into a hidden form field, or into a URL parameter, without any input from the user.
During a load test on the application, NeoLoad simulates the traffic of hundreds of users and each of these
users must be able to use the value of the parameter generated by the server as opposed to the value of
the parameter recorded during the scenario's creation. Normally, to manage these dynamic parameters,
we need to extract the value generated by the server using a variable extractor, and re-inject it into the
subsequent requests in place of the recorded value. This is not a problem when dealing with a single,
isolated dynamic parameter, but it can become tedious when the dynamic parameter occurs in many
requests (numerous replacements in the request definitions), or when its value changes regularly (numerous
variable extractors need to be created).
To make handling these parameters easier, NeoLoad includes two processes that make configuring the
application's dynamic parameters easier:
• framework dynamic parameter handling, based on predefined rules
• generic dynamic parameter handling, based on detection and automatic configuration.
Framework Dynamic Parameter Handling

Within an application-specific development framework, the dynamic parameters generated by the server
are often the same and are used in numerous requests. To avoid having to define variable extractors for a
large number of requests, NeoLoad can search for these parameters and configure the variable extractors/
replacements within the scenario.
A framework dynamic parameter allows you to define rules to automate the extraction and injection of
a dynamic value.
Settings
Before NeoLoad can carry out a search for framework dynamic parameters, you must define the dynamic
parameters generated by your framework. You can do this via the "Edit / Preferences /
Frameworks" menu item.
204
Design
Configuring a dynamic parameter

A framework dynamic parameter is made up of the following:
• General information:
# Name: Parameter name. This is for information purposes and must be unique.
# Framework: Name of the framework with which the parameter is associated.
• Extraction: Defines how the dynamic value is extracted from the server response.
# Extract from the "Body" or "Headers" in the server's HTTP response. Selects from which part of
the response the parameter's dynamic value is extracted.
# XPath expression (optional): The XPath expression option allows you to restrict the content
extraction to one subsection within the response. XPath can only be used for HTML or XML (HTML,
XML, SOAP, GWT, AMF, RTMP, Oracle Forms and Java Serialization) -type responses.
# Regular expression: Where the response contains text that corresponds to the regular
expression's definition, that text is extracted. The regular expression is applied to the response's header
or body or to the result of the XPath expression where specified.
# Value template: The template used to assemble the value. This is an arbitrary string with specific
elements that refer to the groups within the regular expression (a group is a dynamic part of the regular
expression contained within parentheses): $0$ refers to the entire text matching the expression, $1$
refers to group n°1, $2$ refers to group n°2, etc.
• Replacement: Specifies where and how the dynamic value is injected into the request sent to the
server.
205
Design
# Parameter name: Check the box if the parameter's name is dynamic and contains all or part of
the extracted dynamic value.
# Parameter value: Check the box if the parameter's value is dynamic and contains all or part of
the extracted dynamic value. Where the parameter name is specified, only the parameters with that
name are examined and, if necessary, modified.
# Path: Use this option if the path contains the dynamic value.
# Text content: Use this option if the request's text content contains all or part of the dynamic value.
# "Part of the text": All occurrences of the dynamic value are replaced in the text request.
# "Regular expression": Only replace the values that match the specified regular expression.
The "Regular expression" and "Groups" fields must be filled in. "XPath" is optional.
• Regular expression: The expression corresponding to the string that contains or equals
the extracted dynamic value.
• Groups: The groups in the regular expression applied to the text content that equal the extracted
dynamic value, separated by commas.
Example:
We'll call the dynamic parameter "id" and assume the dynamic value extracted is "12345". The
text request will be "<p>The dynamic value is 12345, and not 12345.</p>".
The regular expression used for replacement will be "(The dynamic value is) (\d+),
(and not) (\d+)".
If Groups equals "2, 4", then the request will be changed to "<p>The dynamic value
is ${id}, and not ${id}.</p>".
If Groups equals "2", then the request will be changed to "<p>The dynamic value is
${id}, and not 12345.</p>".
206
Design
Managing frameworks
Framework dynamic parameters are organized by framework. A framework is a set of dynamic parameters
that are specific to a web application or family of web applications (for example, .NET).
Certain predefined frameworks also contain rules for handling Push-type requests. When a framework
is selected in the interface, NeoLoad displays the support of the different Push technologies, polling or
streaming. These handling rules are neither visible nor editable. See the section called “Push Frameworks”
for more details.
Refer to the following procedures to add, edit or delete frameworks:
Procedure 6.16. Adding a framework
1. Click on the "+" button to the right of the frameworks table.
2. Enter the framework name in the "Framework" field.
3. Click "OK".
Note
A framework name is unique.
Procedure 6.17. Editing a framework name
1. In the frameworks table, double-click on the framework name to be edited.
2. Edit the framework name using the keyboard.
3. Hit "Enter" to confirm the change.
207
Design
Note
If the entered name is the same as an existing framework in the list, the change will not be
accepted.
Procedure 6.18. Deleting a framework

1. Select the framework in the frameworks table.
2. Click on the "-" button to the right of the frameworks table.
Note
Deleting a framework also deletes all its associated dynamic parameters.
Managing framework dynamic parameters

As with frameworks, you can add, edit and delete framework dynamic parameters using the procedures
described below.
The simplest way to define a framework dynamic parameter is to set a variable extractor on one of the
requests whose server response contains the dynamic parameter and then convert the extractor into a
framework dynamic parameter:
Procedure 6.19. Creating a framework dynamic parameter using a variable

extractor
1. In the virtual user, select the request whose response contains the dynamic parameter.
2. Click on the "Advanced..." button.
3. Select the "Variable extractors" tab.
4. Click on the "+" button to add a variable extractor.
5. Define a variable extractor to enable the dynamic value's extraction (give the variable the name of
the dynamic parameter).
6. Select the extractor in the list of variable extractors.
7. Click on the "Add to framework parameters" button.
8. Enter the parameter name and the framework name (you may use an existing framework or enter the
name of a new framework), then click "Next".
9. Configure the replacement settings for the dynamic parameter, then click "Next".
10. Launch a dynamic parameter search for NeoLoad to set the remaining extractors required and to
replace the parameter value with the extracted value
This extractor is now added to the list of framework parameters. When future dynamic parameter searches
are carried out (after the next recording for example), NeoLoad will be able to configure the extractors
automatically and replace the static value in the requests with the extracted variable.
Using a variable extractor to add a dynamic parameter provides an easy way to configure the regular
expression and the template to apply to find the parameter.
208
Design
Procedure 6.20. Creating a framework parameter from the preferences

1. Go to the "Frameworks" section in the Global Preferences.
2. Select the framework in which you want to create the parameter.
3. Click on the "+" button to the right of the framework parameters table.
4. Enter the required information, then click "OK".
Procedure 6.21. Editing a framework parameter from the preferences

1. Go to the "Frameworks" section in the Global Preferences.
2. Select the framework containing the parameter.
3. Select the framework parameter to be edited.
4. Click on the framework parameter's editing button.
5. When you have finished editing the parameter, click "OK" to confirm.
Importing/Exporting
The "Export..." button can be used to export the required parameters to the selected directory with
an XML file for each framework.
The "Import..." button can be used to import a previously-exported XML file or to import the NeoLoad
3.0 parameters contained in the controller_user.properties file in the user directory.
Generic Dynamic Parameter Handling

In NeoLoad, the search process for generic dynamic parameters is entirely automated. It allows NeoLoad
to search for the dynamic parameters in an application and to modify the scenario accordingly, without
using predefined rules.
How it works
When the test scenario is recorded, NeoLoad records all the HTTP/S requests sent by the browser to the
server. During this recording, NeoLoad also records the current value of all the parameters sent by the
browser to the server.
When searching for dynamic parameters, NeoLoad plays back the scenario to find the dynamic parameters
present. In each request played back, NeoLoad looks for the corresponding link or form in the previous
server response. If the link or form exists, it indicates that all the parameters have remained unchanged
between the recording and the moment NeoLoad replayed the scenario, so there are no dynamic parameters
for the request. If the link does not exist, it indicates that a parameter's value probably has changed between
the recording and the time NeoLoad played back the scenario. NeoLoad therefore analyzes the server
response to find which parameter's value has changed and configures the scenario to handle that parameter.
Depending on the case, NeoLoad uses either variable extractors on the dynamic parameters or link/form
extractors to handle dynamic parameters.
Example
Let's take the example of an application containing the dynamic parameter id computed by the server and
added as a parameter to a page's links. The links in the server response look like this:
209
Design
<a href="viewCategory.shtml?categoryId=BIRDS&id=1181639214472">BIRDS</a>
<a href="viewCategory.shtml?categoryId=FISH&id=1181639214472">FISH</a>
<a href="viewCategory.shtml?categoryId=DOGS&id=1181639214472">DOGS</a>
<a href="viewCategory.shtml?categoryId=REPTILES&id=1181639214472">REPTILES</a>
<a href="viewCategory.shtml?categoryId=CATS&id=1181639214472">CATS</a>
As parameter id is dynamic, it has a different value when run by each virtual user. After recording this
page, NeoLoad creates a request that includes the parameter's value at the time of recording:
During a dynamic parameter search, NeoLoad fails to find this exact link in the server response. However,
it will find an identical link with a new value for parameter id. Consequently, NeoLoad offers to manage
this dynamic parameter in your scenario:
Once the suggested changes have been applied to the scenario, the amended definition of the request
concerned by this dynamic parameter will be:
210
Design
In this amended definition, NeoLoad has changed the request's manual definition into a link extractor by
setting the parameter id as a dynamic parameter (value <MUST BE PRESENT>). Furthermore, NeoLoad
will place the value of this dynamic parameter into the variable id when the scenario is run so the variable
can be used later on in the scenario.
Searching for Dynamic Parameters in NeoLoad

The dynamic parameter search is a process that may be launched either after recording (Post-Recording
Wizard), or for each virtual user.
Procedure 6.22. Starting a dynamic parameter search on a virtual user
1. Select "Design" mode.
2. Select the "Virtual Users" tab.
3. Select a virtual user in the virtual user profiles tree.
4. Click on the "Search" button.
This brings up the Dynamic Parameter Search Wizard, which gives you the two dynamic parameter search
type options available in NeoLoad:
• Framework dynamic parameter search
• Generic dynamic parameter search
211
Design
Push Frameworks
Context
Push frameworks are used when testing applications that use Push technology. This is a type of
communication in which information is "pushed" by the server towards the browser, contrary to the normal
Pull principle whereby the browser initiates the request for information.
Note
The use of Push frameworks requires the Push module, which is licensed.
Definition
Push frameworks can be used to create automatically a virtual user definition that is compatible for use
in a Push environment.
For an application to operate in Push mode, a Push channel is required through which the data is fed from
the server to the client. Handling the Push channel requires special tools and concepts specific to this
particular type of application. Each framework allows you to create virtual user profiles, after recording,
that take into account the Push channel.
Note
As with a normal framework, a Push framework enables the automation of parameter extraction
and replacement. See the section called “Frameworks” for more details.
How it works:
1. During the recording, NeoLoad detects that the recorded application is using a Push framework.
2. At the end of the recording, NeoLoad offers to create a modified copy of the virtual user that has just
been recorded.
212
Design
This user is named "<original name>_<framework name>".
This copy contains all the changes specific to the detected Push framework and that will serve to make
designing the virtual user more simple and enable a playback that is as realistic as possible.
3. The virtual user profiles tree will now contain two user profiles:
• the original user containing the raw recording data. This is a potential source of data for developing
the user actually used. It may be deleted at any time.
• the NeoLoad-modified user. We strongly recommend using this virtual user as a basis for ongoing
design.
Modified Virtual Users

This section describes how modified virtual users are created.
There are two main categories of Push application, those that use polling and those that use streaming. The
modifications NeoLoad makes to a virtual user depend entirely on the type of Push application concerned.
Polling
Description
Polling is a mechanism whereby a request is sent by the client to the server at regular intervals. In return,
the server updates the status of each connected client. Between two polling requests, the server stores the
updates sent to the client in its memory until the next polling request is received.
How NeoLoad handles polling
NeoLoad groups all the polling requests into a single polling request, which is executed several
times. The request is then included in a loop.
NeoLoad inserts a delay between two executions of this same request representing the interval between
two polling requests. This delay is based on the average time interval between two polling requests in the
original virtual user.
Since handling a polling request is a blocking process (loop on the request), NeoLoad inserts a fork action
in order to create a parallel execution thread, which allows the user actions to continue their execution
in parallel.
Lastly, NeoLoad determines the interval between the last non-polling request and the last polling request
and inserts the end of polling delay. It also adds a variable modifier that triggers the exiting of the loop
created earlier, once polling is finished.
For more details on handling polling requests in NeoLoad, see the section called “Polling Requests”.
Streaming
Description
Streaming is a mechanism whereby a holding request is sent by the client to the server. In other words,
the client never completely finishes reading the server's response to the request, the server sending back
several separate response messages. The client is able to read these messages and interpret the instructions
received. Once they have been executed, it waits for new instructions by returning to read the next part
of the response.
213
Design
How NeoLoad handles streaming
NeoLoad uses a specific streaming request, which blocks the connection until the server closes the
socket. For each framework that supports streaming, NeoLoad is able to separate the response messages
sent by the server, thus allowing it to handle the actions to be carried out upon the arrival of each message.
Since a call to a streaming request is a blocking process, NeoLoad inserts a fork action in order to create
a parallel execution thread, which allows the user actions to continue their execution in parallel.
For more details on handling streaming requests in NeoLoad, see the section called “Streaming Requests”.
Push messages
Push requests ( polling request -type or streaming request -type) both work on the same
principle: each message sent by the server is processed by the Push Message design element, which
allows you to define the actions to be carried out when a certain type of message is received.
Thus, during recording, NeoLoad detects the different types of message received from the server and
creates the corresponding Push Message elements and places them in a special-purpose Push request.
Frameworks
By default, NeoLoad provides you with a simplified virtual user, based partly on the detected framework
and partly on the type of Push application. Here is a description of the default user provided by NeoLoad
for each of the supported frameworks and for each type of Push application.
AMF Polling
Original user
This is an example of an original user using AMF polling.
214
Design
Note
The AMF polling requests are identified as having a name with the POLL_XXX format.
Modified user
The NeoLoad-modified user looks like this:
NeoLoad has made the following noticeable changes:
• All the AMF polling requests have been grouped into a single polling request (POLL_5 in this example).
This request has been placed in a loop (polling_while in this example), which continues to loop
until the NL-stopPolling variable generated by NeoLoad becomes true. Lastly, the loop itself
has been placed in a secondary execution thread using a fork action (push_fork in this example).
• NeoLoad identifies the different types of message returned through the

Push channel during recording. These different types of message are
modelized by the Push messages (flex.samples.marketdata.Stock or
flex.messaging.messages.AcknowledgeMessageExt for example here).
• The polling_delay is the average of the time intervals between two polling requests in the original
virtual user.
• The stop_polling variable modifier triggers the exit from the polling loop by modifying the value
of the NL-stopPolling variable.
AMF Streaming
Original user
This is an example of an original user using AMF streaming.
215
Design
The AMF streaming requests are identified as having a name with the "<path> open" and "<path>
close" formats.
Modified user
• The "open Push" request (/samples/messagebroker/streamingamf open_1 in this

example) has been placed in a secondary execution thread, push_fork_1.
216
Design
• NeoLoad identifies the different types of message returned through the Push channel
during recording. These different objects are modelized by the Push messages
(flex.samples.marketdata.Stock_1 or String for example here).
• The "close Push" request (/samples/messagebroker/streamingamf close_1 in this

example) tells the server to stop Push. Upon receiving the request, the server closes the streaming request
/samples/messagebroker/streamingamf open_1, allowing NeoLoad to move on to the
next action. In our example, there are no other actions in the push_fork_1 object so the secondary
thread ends.
RTMP
Warning
To be able to record RTMP requests, the Adobe RTMP option must be checked in the recording
window.
Original user
This is an example of a virtual user using the RTMP protocol.
The RTMP Push channel is represented by the RTMPChannel object. Its recorded response contains all
the messages sent by the server through the Push channel.
217
Design
Modified user
The NeoLoad-modified user looks like this.
• The request representing the Push channel (RTMP_Channel_1 in this example) has been placed in a
secondary execution thread (rtmp_channel_fork).
during recording. These different types of message are modelized by the Push messages (
receive_flex.samples.marketdata.Stock for example here).
RTMPT
Warning
At the end of recording, a dynamic parameter search must be launched for NeoLoad to be able
to handle the RTMP dynamic session id's.
Original user
This is an example of a virtual user using the RTMPT protocol.
218
Design
The following points should be noted:
• A large number of HTTP requests with the /idle/ prefix have been recorded. These requests are
polling requests.
• When a container is added during entering, polling requests also are added. This explains the "rem_06",
"remov_06" containers.
Modified user
219
Design
• The request representing the opening of the RTMPT session (/open/1 in this example) has been placed
in a secondary execution thread (push_fork_3) since it's a blocked process. A variable extractor
(RTMPTID in this example) has been configured to extract and re-inject the RTMPT session variable in
each of the following requests: /idle/XXX, /send/XXX or /close/XXX. Execution of the main
thread is put on hold until the RTMPTID session variable is retrieved, using the wait_RTMPTID object.
• All the RTMPT polling requests have been grouped into a single polling request (/idle/
${RTMPTID}/0 in this example), reducing the number of requests considerably. If a container
becomes empty (as is the case with "rem_06" and "remo_06" for example), it is automatically deleted.
• The request representing the RTMPT Push channel (/idle/${RTMPTID}/0 in this example) has
been placed in a loop (polling_while_2), which continues to loop until the NL-stopPolling
variable generated by NeoLoad becomes true. Lastly, the loop itself has been placed in a secondary
execution thread using a fork action (push_fork_4 in this example).
during recording. These different types of message are modelized by the Push messages
(receive_flex.samples.marketdata.Stock for example here).
• Once negotiation is completed (represented here by the RTMPHandshake_1 request) ,

the NL-RTMPHandshakeDone variable generated by NeoLoad is modified (by the
handshake_done_modifier variable modifier in this example), which then unblocks the
wait_handshake_done wait.
220
Design
• The polling_delay_2 polling delay is the average of the time intervals between two polling
requests in the original virtual user.
• The stop_polling_2 variable modifier stops the polling loop by modifying the value of the NL-
stopPolling variable.
ICEfaces
NeoLoad supports the open-source ICEfaces server and its commercial version, ICEfaces EE.
Versions 1.8.2a onwards of the ICEfaces server also feature an API that allows you to make use of the
Push messages generated by the server itself as well as their associated timestamps. To be able to use the
NeoLoad Push messages, the names of the ICEfaces beans and the beans' associated timestamps must be
published in the ICEfaces application.
Modifying the tested ICEfaces application
• Modifying the ICEfaces bean:
The Java file containing the ICEfaces bean must contain a method publishing the additional information.
For example, the MyBean.java file might contain the following code:
public class MyBean implements Renderable {

...
private GroupAsyncRenderer mybean;
private String renderInfo;
...
public String getRenderInfo()
{
String currentRenderInfo = mybean.getLastRenderInfo();
if(!currentRenderInfo.equals(renderInfo))
{
renderInfo = currentRenderInfo;
return currentRenderInfo;
} else {
return "";
}
}
...
• Modifying the .jspx file:
The .jspx file containing the visual part of the content rendered in the browser must send back this
information in the page. One idea is to send back the information in a hidden layer.
The code might take the following form:
...
<div id="hiddenDiv">
...
<ice:outputText value="MyBean #{MyBean.renderInfo}"/>
...
</div>
...
Original user
221
Design
Warning
to handle the ICEfaces dynamic session id's and the JSF ViewState.
This is an example of a virtual user using the ICEfaces Push framework.
• The ICEfaces polling is divided into two request categories: requests to the /receive-updated-
views servlet and those to the /receive-updates servlet. This explains the large number of this
type of requests.
• User clicks are represented by requests to the /send-receive-updates servlet.
• When a container is added during entering, polling requests also are added. This explains the "bi",
"connec"... containers.
Modified user
222
Design
• The two categories of polling request have been grouped together: requests with the form XXX/
receive-updated-views on the one hand and those with the form XXX/receive-updates
on the other hand. This reduces the number of requests considerably. If a container becomes empty (as
is the case with "bi" and "connec" here for example), it is automatically deleted.
• The variable extractor viewsToUpdate has been placed on the first polling request (/
auctionMonitor3/block/receive-updated-views in this example), which retrieves the
id's for the ICEfaces views to be updated. This is why the second polling request has been placed in a
loop (loop_update_view in this example), in order to issue an update request for each previously-
extracted view.
• The request representing the ICEfaces Push channel (/auctionMonitor3/block/receive-

updates in this example) has been placed in a loop (polling_while_1), which continues to loop
until the NL-stopPolling variable generated by NeoLoad becomes true. Lastly, the loop itself
has been placed in a secondary execution thread using a fork action (push_fork_2 in this example).
• NeoLoad identifies the different types of message returned through the Push channel during recording,
provided that the server being tested is version 1.8.2a or upwards and that the developers have published
the required additional information. These different types of message are modelized by the Push
messages (ClockBean for example here).
• The polling_delay_1 polling delay is the average of the time intervals between two polling
requests in the original virtual user.
• The stop_polling_1 variable modifier stops the polling loop by modifying the value of the NL-
Lightstreamer Polling
Warning
to handle the Lightstreamer dynamic session id's.
223
Design
Original user
This is an example of a virtual user using polling with the Lightstreamer framework.
• A large number of HTTP requests with the format XXX/bind_session.js have been recorded.
These requests are polling requests.
Modified user
224
Design
• All the Lightstreamer polling requests have been grouped into a single polling request (/
lightstreamer/bind_session.js in this example). This request has been placed in a loop
(polling_while in this example), which continues to loop until the NL-stopPolling variable
generated by NeoLoad becomes true. Lastly, the loop itself has been placed in a secondary execution
thread using a fork action (push_fork in this example).
• NeoLoad identifies the different types of message returned through the Push channel during recording.
These different types of message are modelized by the Push messages (initialSnapshot-1_2 or
update-1_2 for example here).
• For each response returned by the Push channel, NeoLoad cuts up the JavaScript call into messages.
Thus, NeoLoad recognizes three types of Lightstreamer call by default: initialSnapshot-X,
update-X and heartbeat, where X represents the updated HTML component.
• The Lightstreamer LS_phase parameter is handled using the LS_phase variable extractor set
both on the session creation request (creation_session.js in this example) and on the
Push request (/lightstreamer/bind_session.js in this example). A JavaScript action
(LS_phase_update1_1 in this example) increments the value of the LS_phase variable at each
loop iteration to reproduce the browser's behavior.
• The polling_delay polling delay is the average of the time intervals between two polling requests
in the original virtual user.
• The stop_polling variable modifier stops the polling loop by modifying the value of the NL-
Lightstreamer Streaming
Warning
to handle the Lightstreamer dynamic session id's.
Original user
This is an example of a virtual user using streaming with the Lightstreamer framework.
225
Design
The Lightstreamer streaming request is easily identified, since it ends with the path /
STREAMING_IN_PROGRESS.
Modified user
• The request representing the Lightstreamer Push channel (/lightstreamer/

STREAMING_IN_PROGRESS in this example) has been placed in a secondary execution thread using
a fork action ( push_fork_4 in this example).
• NeoLoad identifies the different types of message returned through the Push channel during recording.
These different types of message are modelized by the Push messages (initialSnapshot-2 or
update-2 for example here).
• For each response returned by the Push channel, NeoLoad cuts up the JavaScript call into messages.
Thus, NeoLoad recognizes three types of Lightstreamer call by default: initialSnapshot-X,
update-X and heartbeat, where X represents the updated HTML component.
• The Lightstreamer LS_phase parameter is handled using the LS_phase variable extractor set
on the session creation request (creation_session.js in this example). A JavaScript action
(LS_phase_update_1_1 in this example) increments the value of the LS_phase variable to
reproduce the browser's behavior. Lastly, this variable is used in the "open streaming" request (/
lightstreamer/STREAMING_IN_PROGRESS in this example).
Shared Containers
NeoLoad allows you to share container elements so that they can be re-used in several virtual users. This
allows you to re-use the same business transaction, such as "login" or "logout".
226
Design
Using shared containers also allows usable results to be obtained across several virtual user profiles.
For example, when the same "login" business transaction is shared between the "Viewer", "Buyer" and
"Account Manager" profiles, it allows you to plot the average transaction time whatever the virtual user
profile. This gives a rapid view of the average time for the "login" business transaction whatever the type
of user connected to the application.
The shareable elements are: Container, Random Container, Loop, While and Fork.
When modifying a shared container or one of its child elements, the modifications apply for all the virtual
users containing that element. Note that you may re-use a shared container at several positions within a
same virtual user.
Sharing a Container
There are several ways to share a design element:
• Select the element to be shared, then right-click and check the "Shared" option in the pop-up menu.
• By dragging and dropping the element onto the "Shared containers" node in the virtual users tree.
• By creating the element in the "Shared containers" node: in the pop-up menu, select "Insert",
then the type of element to insert.
When creating from an existing element, this element is added to the "Shared containers" node and
a reference to the shared element is inserted in place of the original element.
Using a Shared Container

There are several ways to use a shared container:
• Drag the element from the "Shared containers" node and drop it in place.
• Copy the element from the "Shared containers" node or copy a reference to it in a virtual user
and paste it at the required location.
227
Design
Actions on Shared Containers

Procedure 6.23. Replace a reference to a shared container by a copy.
1. Select the element in the virtual user.
2. Right-click and un-check the "Shared" option in the pop-up menu.
Note
The container remains shared an all other references to it remain unchanged.
Procedure 6.24. Stop sharing the container and replace by copies

1. Select the element in the "Shared containers" node.
2. Delete the element by right-clicking and selecting, or using the "Delete" button.
3. In the displayed dialog box, select the "Stop sharing" option.
Procedure 6.25. Delete the shared container and all references to it.
1. Select the element in the "Shared containers" node.
2. Delete the element by right-clicking and selecting "Delete", or by clicking the "Delete" button.
3. In the displayed dialog box, select the "Delete" option
Populations
A Population is a group of Virtual User types. Populations allow the application to be tested using different
business behaviors. For example, the user can test an e-business website with 90% of the users consulting
the catalog and 10% completing a purchase.
228
Design
Percentage
Percentage of the selected Virtual User type within the Population. When running a scenario with a given
number of Virtual Users, this percentage defines the number of Virtual Users of each type to be used. The
percentage total for the four lines must equal 100%.
Bandwidth
NeoLoad can emulate user connections with different bandwidth capacities, such as dial-up modem, DSL
or local network. This parameter is important because different network access methods impact the server
in different ways. For example, dial-up modem users have a greater impact on I/O buffering and thread
pools, whereas local network users have a greater impact on the server's CPU usage.
You may specify different bandwidth for download and upload.
Browser
Allows centralized modification of the HTTP User-Agent ID. This header is not normally important
in a load test, but it may be useful in cases where the content of the server response changes according
to the browser used.
Choose one of the preset values, or enter a custom setting. For historical reasons, Microsoft's IE browser
ID's all begin with "Mozilla/4.0".
Use cookies
Enables or disables the Virtual Users' cookie management capabilities. Disabling cookies allows the user
to test whether the application supports browsing with cookies disabled, and can force the server to use
URL rewriting to track the session.
Connection
Sets the number of connections a Virtual User can open simultaneously on the remote server. Most
browsers set a maximum of 2 connections per server.
Cache management
The user cache behavior may be simulated in three ways:
• "As recorded": the Virtual User cache behavior is the same as in the scenario recording.
• "New user": simulates a Virtual User who has never visited the application and whose user cache
is empty.
• "Returning user": the Virtual User's cache is up to date, therefore the application will not return
any response which contains information that is already cached. More exactly, the server will respond
a 304 Not Modified code.
Variables
Variables are used to add dynamic content to a scenario. They may be combined with other variables or
with static content (e.g. ${product_${productID}}) and used in a number of places, such as in
form parameter values.
229
Design
Creating a Variable
Open the Variable Editor window by clicking on the "Edit / Variables" menu item, then on the
"New variable" button.
Select the type of variable to create:
• Counter - A numerical variable having an initial value, a maximum value and an incremental value.
• List - A list or table of values. Use ${<variable Name>.<columnName>}. (e.g.:
${ListVariable_0.col_0})
Tip
Click on the column header to rename the column. This will let you use, for example,
${accounts.login} instead of the default name ${accounts.col_0}.
• File - A list or table of values loaded from a text file. Use ${<variable Name>.<columnName>}.
(e.g.: ${ListVariable_0.col_0}). The first lines only are displayed in the preview pane. You
can use the first line of the file as columns headers name.
Tip
Click on the column header to rename the column. This will let you use, for example,
${accounts.login} instead of the default name ${accounts.col_0}.
• SQL - A list of values loaded from a database request. The SQL variable executes a request to the
database and stores the values in a temporary csv file. The temporary csv file is placed in the project
directory's SqlTemp subdirectory. The contents of the file is updated each time the scenario is launched.
Two configurations are possible depending on the database driver selected:
1. Guided mode:
Select the MySQL, Oracle, DB2, PostgreSQL or Microsoft SQL driver. In this mode, the following
fields must be filled in: host, port, name, user name and password for the database. The MySQL,
Oracle and PostgreSQL drivers are available by default.
2. Manual mode:
230
Design
Select the "Other" driver. In this instance, the JDBC driver (Java DataBase Connectivity) usually
takes the form of a file bearing the .jar extension. This file must be installed in the /lib/
jdbcDrivers under the root NeoLoad installation directory.
Example: mysql-connector-java-5.0.4-bin.jar.
The driver name is unique to the driver used.
Example: com.jdbc.mysql.Driver for mysql.
The complete URL is used to specify the access path to the database. This URL must include at
least the following information: host name, port, name, user name and password for the database.
Example: jdbc:mysql://localhost:3306/test?
user=neotys&password=neoload
Only "SELECT" type requests are authorized within the SQL request.
Example: SELECT * FROM users
A test button allows you to check the validity of the database connection information and SQL request.
The test window shows the following items:
# Request: contains the SQL request.
# Results: request results preview pane.
# Error details: this field shows the errors returned by the database driver.
• Random Integer - A random numerical value within a value range.
• Random String - A random alphanumerical string defined within a value range.
• Constant String - A string which value can't be modified.
• Date - A date in the desired format. May be incremented.
• CurrentDate - The current date in the desired format.
Value change policy

All variables (except CurrentDate) may define a value change policy. This is sometimes referred to as a
variable's "lifetime".
• Each use - The value is systematically changed upon each use.

• Each request - The value is changed each time a new request is played, the variable retaining the same
value in both the request and the response to the frame.
• Each page - The value is changed each time a new page is played, the variable retaining the same value
for all the requests defined in the page.
• Each Virtual User - The variable retains the same value for all pages and requests of a given Virtual
User.
Variable scope
In NeoLoad, a variable's scope may be either global -across the whole test- or local -restricted to one
Virtual User. The scope depends on the particular variable's use.
• Global variable - The values in a global variable are shared by all Virtual Users. The first Virtual
User uses the first value in the variable, the second user the second, and so on. This type of scope is
particularly useful for a variable that manages, for example, the application's login accounts.
231
Design
• Local variable - The values in a local variable are used within a same Virtual User. Each user starts by
using the first value, then the second, and so on. This type of scope is particularly useful in a Virtual
User loop, where each user is required to use all values in the variable.
# Centralize allocation for optimized distribution of values (Advanced): use this option to influence
the behavior of a global variable.
1. Disabled: Each load generator manages a part of the variable's values. The advantage of this
mode is that it is more efficient. The downside is that the values are not always used uniformly
when using several load generators. Therefore, it is best suited to tests using a single load generator.
2. Enabled: The controller manages all the variable's values. This provides a more uniform
distribution of the variable's values. The downside of this mode is that it increases the controller's
memory and processor usage, as well as network traffic between the controller and each of its load
generators. This mode is best suited to tests using several load generators.
The Variable Extractor

The values of variables may be extracted from the contents (header or body) of server responses. The
extraction is carried out on the server response using a regular expression.
Use the Variable Extractor (accessed from the "Advanced Parameters" window of the request) to
extract the value from a page's content. It can then be used, for example, as a parameter for a subsequent
request or for a content assertion.
Testing a Variable
The variable testing tool may be used to verify a variable's syntax and value change policy:
Click on the "Apply Action and Evaluate" button to simulate and validate the variable's value
change policy.
Using Variables
Variables may be used wherever the Variable Picker is available:
The syntax to use is ${nomDeVariable}. To insert a variable use:
• the picker, using "..." button, or
232
Design
• the auto-fill suggestion starting to type "${".
Variable names themselves also may be dynamic. For example, if the counter variable's value is 1, then
${product_${counter}} is equivalent to ${product_1}.
Search and Replace

Overview
The "Search and Replace" function allows you to search for, and replace, character strings or servers
in all the virtual user profiles.
Procedure 6.26. Opening the search wizard from the menu
1. Click on the "Edit" menu.
2. Select the "Search and Replace" menu item.
Procedure 6.27. Opening the search wizard using the toolbar icon
• Click on the magnifying glass icon in the toolbar.
Search Criteria
The available search criteria are:
• "Search in request definitions globally"
• "Search in request parameters"
• "Search in URLs"
• "Search in request headers"
• "Search for a server in request definitions"
Certain search criteria allow you to specify regular expressions. For more information, see the Guide to
Regular Expressions
233
Design
Search in request definitions globally

The string is searched for both in the path and in the names and values of request headers and parameters.
Procedure 6.28. Searching in request definitions globally
1. Open the search wizard.
2. Select the "Search in request definitions globally".
3. Click "Next >".
4. Enter the string to be searched for in the "Search string" text box.
5. Enter the replacement string in the "Replace with" text box.
234
Design
6. If the String to search for is a regular expression, check the "String is a regular
expression" check box.
7. Click "Next >", then "Finish".
235
Design
Search in request parameters

The string is searched for in the request parameters. Several search types are available:
• "Search in names and values and replace"
Searches in the parameter names and values and replaces the text when found. This is particularly useful
for quickly replacing a same value in a scenario with a NeoLoad variable.
• "Search in names and replace parameter's value"
Searches the requests for a particular parameter (identified by its name) and changes the parameter's
value (whatever its initial value).
• "Search in names and delete parameter"
Searches the requests for a particular parameter (identified by its name) and deletes the parameter.
Useful for bulk deletion of parameters.
Each search type involves a specific procedure.
Procedure 6.29. Searching in names and values and replacing
2. Select the option "Search in request parameters".
3. Click "Next >".
4. Select "Search in names and values and replace".
5. Click "Next >".
6. Enter the string to be searched for in the "String to search for" text box.
7. Enter the replacement string in the "Replace string with" text box.
236
Design
8. If the search string is a regular expression, check the "String is a regular expression"
check box
237
Design
Procedure 6.30. Searching in names and replacing a parameter's value
3. Click "Next >".
4. Select the option "Search in names and replace parameter value".
5. Click "Next >".
check box.
238
Design
Procedure 6.31. Searching in names and deleting a parameter
3. Click "Next >".
4. Select the option "Search in names and delete parameter".
5. Click "Next >".
239
Design
check box.
240
Design
Search in URLs
Allows you to search in the request paths and replace the string.
Procedure 6.32. Searching in URLs
2. Select the option "Search in URLs".
3. Click "Next >".
check box.
241
Design
Search in request headers

The string is searched for in the requests' headers. Several types of search are available:
• "Search in names and values and replace"
Searches in the headers' names and values and replaces the text when found. This is particularly useful
for quickly replacing a same header value in a scenario with a NeoLoad variable.
• "Search in names and replace header's value"
Searches the requests for a particular header (identified by its name) and changes the header's value
(whatever its initial value).
• "Search in names and delete header"
Searches the requests for a particular header (identified by its name) and deletes the header. Useful for
bulk deletion of headers.
Each search type involves a specific procedure.
Procedure 6.33. Searching in names and values and replacing

2. Select the option "Search in request headers".
3. Click "Next >".
4. Select "Search in names and values and replace".
242
Design
5. Click "Next >".
check box.
243
Design
Procedure 6.34. Searching in names and replacing a header's value
3. Click "Next >".
4. Select the option "Search in names and replace header's value".
5. Click "Next >".
244
Design
check box.
245
Design
Procedure 6.35. Searching in names and deleting a header
3. Click "Next >".
4. Select the option "Search in names and delete header".
5. Click "Next >".
check box.
246
Design
Search for a server in request definitions

This search allows you to replace a server in a request definition with another server.
Procedure 6.36. Searching for a server in request definitions
2. Select the option "Search for a server in request definitions".
3. Click "Next >".
4. Select the "Server to search for" and the "Replacement server".
247
Design
248
Design
Replacements
If the search fails to return any results, a pop-up window prompts you to modify the search criteria.
If the search does return results, a pop-up window is displayed that lets you browse the results. The
results are flagged in the virtual user profiles tree. The search window automatically shows the first result
occurrence.
• You may scroll through the results using the "Next" and "Previous" buttons. The text to be changed
is highlighted:
• If the current item becomes de-selected due to some unexpected user input, click on the "Current"
button to return to it.
• Clicking the "Replace" button replaces the highlighted string with the value displayed in the pop-up
window. When all the results have been replaced, the pop-up window closes and a dialog box indicates
that there are no more results.
• Clicking the "Replace all" button replaces all the results found. Once completed, a dialog box is
displayed showing the number of replacements made.
Flags
A flags is used to identify a request that fulfills certain criteria. When a request fulfilling the criteria has
been identified, a mark is placed against its icon in the virtual user profile tree. Any container (container,
loop, virtual user...) containing a flagged item is itself flagged.
Procedure 6.37. Flagging requests

1. In the "Design" section, select the "Virtual Users" tab.
2. To display the flags pane:
249
Design
• Click on "Virtual user profiles" in the left-hand tree or,
• Right-click on a tree item and select the "Flag requests..." option.
3. Select the flagging criteria.
4. The items that fulfill the criteria, as well as their parent items, are flagged.
5. Close the window if required (no halt on the window). Flags stay in place until the "None" criterion
is selected.
Flagging Criteria
The criteria available for flags are:
• "None": Clears all flags.
• "With the variable": The request uses the variable.
# "as variable extractor" option: the request contains an extractor that extracts the specified
variable.
# "used in request" option: the variable is used in the request's content (URL parameters, form
parameters...)
At least one of the two options must be selected.
• "Whose definition contains": The request contains the specified string. The search is carried
out in:
# request paths
# parameter names and values
# validations
# names of the variable extractors' variables
# HTTP headers
# requests' text content where the request is "Post' -type with a text-type content.
• "Whose recorded response contains": the response to the request made during the recording
contains the specified string.
• "With response validations".
• "With variable extractors defined on":
# "requests": the request contains at least one variable extractor defined on its response.
# "parameters": the request contains at least one variable extractor defined on one of its parameters.
At least one of the two options must be selected.
• "Is link/form extractor": The request type is "Follow a link from the previous
request" or "Submit a form from the previous request".
250
Design
• "With parameters": the request features at least one parameter.
• "Is a POST form": The request method is "POST".
• "Whose type is":
# SOAP
# Adobe Flex/AMF
# Adobe RTMP
# Oracle Forms
# Google Web Toolkit
# Java Serialization
Scope
Flags are restricted in scope to the virtual user in which the item that was right-clicked is located. To carry
out a search in all virtual users, click on the "Virtual User Profiles" root node.
To change the search scope on the fly, click on the desired virtual user or on the root node while the
validation window is visible.
Importing and exporting a project

Importing a project
NeoLoad features an Import Wizard which allows the user to import the contents of an existing NeoLoad
project into the current project.
The import takes into account all the Scenario resources. Any linked files (variable source files, linked
JavaScript library files) are automatically copied to the current project. Files specified by an absolute path
on the hard disk and not included in the imported project directory will not be copied.
The imported resources (servers, pages, Virtual Users, Populations ...) must not already exist in the current
project under the same name. If a resource does already exist, NeoLoad will prompt you to rename the
resource to be imported in order to avoid any conflicts.
251
Design
Procedure 6.38. To import a project

1. Click on the "File / Import a project..." menu item.
2. Select the project on the hard disk to be imported by clicking on the file with the nlp extension, or
select the zipped archive.
3. Choose the renaming policy:
• "All elements": NeoLoad import all the resources, systematically applying the renaming
template (see below). In the event of a conflict, that is to say, if a resource that has been renamed
using the template already exists, NeoLoad prompt you to choose another unused name.
• "Conflicting elements": Only the items with a naming conflict are renamed, in accordance
with the renaming template.
4. Choose the renaming template. You may specify a prefix and/or suffix to be used to form the new
name for the item if it is renamed.
5. Click on "Import".
6. The import begins; in the event of a naming conflict, a pop-up window allows you to change the name
of a resource if the name already exists.
Exporting a Project
NeoLoad's Export Project wizard allows you to do the following:
• Export an entire project to NeoLoad's technical support server; as well as the project itself, the export
may also include the test results, configuration files, log files and one Virtual User validation result. The
exported archive is directly uploaded to a Neotys FTP server.
• Export an entire project for backup or transfer to another workstation; the exported archive is stored
on the destination medium. The archive can be imported in another project, see the section called
“Importing a project”.
252
Design
Procedure 6.39. To export a project
1. Use the "File / Export project..." menu item.
2. Select which test results to export: all, none, or just the results for the latest test run. Click on
"Next".
3. Select the export type:
# "Export to file": exports the project to an archive on a hard disk. In this case, specify the
destination archive and confirm to complete the procedure.
# "Export to Neotys support": exports the project and any debug items to an archive
that is automatically uploaded to the Neotys support team's FTP server.
Then click on "Next".
4. If exporting to the support server, select which items to include:
# log files (recommended)
# configuration files (recommended)
# a Virtual User validation result: NeoLoad takes the last validation result for the selected Virtual
User, or launches a validation if the Virtual User yet to be validated.
Enter the ID number supplied by Neotys technical support. If you do not have a number, leave
this box blank.
253
Design
Then click on "Next".
5. When you click on "Finish", NeoLoad creates the archive and uploads it to the FTP site. You
may continue to use NeoLoad normally during the upload process. Once the archive has been
uploaded, the Neotys support team is automatically informed of its reception.
254
Chapter 7. Monitors
Overview
Presentation
Monitors allow you to monitor the performance of the servers used in a test. The servers (or machines)
that can be monitored are:
• web servers,
• application servers,
• database servers,
• operating systems,
• networks components
The monitored machines can be accessed from the "Monitors" tab in the "Design" section.
This tab displays the monitored machines in the form of a tree. Under each monitored machine, you may
define several monitors for each type of system being monitored. You may also define several performance
counters and indicators for each of these monitors. These counters (numeric values) and indicators (text
values) are grouped by category. Several alert thresholds may be set for each performance counter above
which an alert will be triggered during the test. By default, NeoLoad automatically selects the most relevant
counters and indicators when the monitor is configured and sets the corresponding thresholds.
Note
Each monitor type is an optional module that may be purchased separately from Neotys.
A performance counter, represented by the icon, corresponds to a numeric value that varies during the
test. The icon indicates a performance counter for which alert thresholds have been set.
A performance indicator, represented by the icon, corresponds to a text content, across several lines,
that does not vary during the test. Depending on the type of indicator, this content is retrieved from the
monitored system either
• at the start of the test: for example, the JDBC pool configuration.
• at the end of the test: for example, the most resource-hungry SQL requests.
In the "Monitors" tab's tree, you may:
• move,
• delete,
• copy, or copy and paste each item in the tree.
255
Monitors
Creating and Configuring a Monitored Machine

Creating a monitored machine
There are two ways to open the New Monitored Machine Wizard.
Procedure 7.1. Opening the New Monitored Machine Wizard from the monitors
tree
1. In the monitors tree, select the "Monitored machines" item.
2. In the panel to the right of the tree, click on the "New monitored machine" button.
Procedure 7.2. Opening the New Monitored Machine Wizard using the pop-up
menu
1. In the monitors tree, select the "Monitored machines" item.
2. Right-click the item. In the pop-up menu, select the "New monitored machine" option.
Once the New Monitored Machine Wizard displays, the procedure for creating a new monitored machine
is as follows:
Procedure 7.3. Creating a monitored machine using the wizard

1. In the "Name of machine to be monitored" text field, enter the DNS name or IP address
of the server to be monitored.
2. In the monitors tree, select the monitors to be put in place on this server.
3. Click "Next >".
256
Monitors
4. NeoLoad displays the documentation for each of the selected monitors. If the monitor requires
an additional, specific configuration the following message is displayed: "This monitor
requires specific configuration". Once this specific configuration has been completed,
click "Next >".
Note
Configuring certain monitors may require NeoLoad to be restarted. In these cases, you will
need to repeat steps 1 through 3 of this procedure.
5. Information for connecting to the monitor must be entered for each selected monitor. Click the
"Test" button to check whether the monitor is correctly configured. Once the configuration is
correct, click "Next >".
6. By default, NeoLoad automatically selects the most common counters. You may also select the
counters manually. To return to the NeoLoad default counters, click on the "Default" button.
Click "Next >" to go to the next monitor, or "Finish" if the last monitor has been configured.
Depending on the type of monitor, NeoLoad displays the following steps (selecting the hard disk,
processes, web applications...). These steps are explained in the section dedicated to each monitor.
Configuring a monitored machine

To configure a monitored machine, the procedure is as follows:
Procedure 7.4. Configuring a monitored machine
1. Select the monitored machine to be configured in the monitored machine tree.
2. In the right-hand panel, edit the monitored machine's configuration.
257
Monitors
Definition
A monitored machine's definition contains the following information:
• "Name": the visual name used to represent the machine in NeoLoad.
• "Hostname": the host name is the machine's physical name (DNS name or IP address).
Note
The monitored machine's "Hostname" is used as the monitor's default "Hostname"when
creating a monitor.
• "Description": a description of the machine for the user's information purposes.
Monitoring
To create a new monitor on the monitored machine, click the "New Monitor" button. Creating a monitor
is explained in the next section.
Creating and Configuring a Monitor

Creating a monitor
There are two way to create a new monitor:
Procedure 7.5. Creating a monitor from a monitored machine's definition

1. Select the machine in the monitored machine tree.
2. In the right-hand panel, click on the "New Monitor" button.
Procedure 7.6. Creating a monitor using the pop-up menu

1. Select the machine in the monitored machine tree.
2. Right-click on the selected monitored machine, then select the "New Monitor" option.
The wizard is identical to the New Monitored Machine Wizard. The name of the monitored machine is
pre-entered in the "Hostname" field.
Configuring a monitor
The role of a monitor is to group all the counters and indicators in place on a given server. It also tells
NeoLoad how to connect to the monitored system.
258
Monitors
Definition
A monitor"s definition contains at least the following information:
• "Name": the visual name used to represent the monitor in NeoLoad.
• "Hostname": the host name is the machine's physical name (DNS name or IP address).
Note
The monitor's host name may be changed independently of the name of the monitored machine
in which it is located. This may be useful for example where the monitor is only available on
a particular network interface within the monitored machine.
Additional information may be required, depending on the type of monitor. This may include (non-
exhaustive list):
• "Port": network port number.
• "Connection URL"
• "Domain"
Contextual help for each monitor can be obtained by pressing "F1".
Properties
Certain properties common to all the counters within a monitor can be set in the monitor's panel:
• Enabled. Allows you to enable or disable the monitor. A disabled monitor will not collect any
information on the next test run. You may also enable or disable a monitor from the tree in the
Monitors panel by right-clicking on one or more monitors, or on a monitored machine.
• Monitoring interval. This refers to the interval between two monitor value readings for that
connection. The recommended default interval is 5 seconds. Too short an interval could have a negative
effect on the server's performance.
259
Monitors
Connection status
The "Test" button allows you to test the connection to the server. If it fails, you will need to check the
monitor's settings. A specific error message helps to identify the possible cause of the connection failure.
Pressing "F1" will give you a list of prerequisites for each type of monitor.
Creating and Configuring a Counter or an Indicator

Creating a counter or an indicator
There are two ways to create a counter or indicator:
Procedure 7.7. Creating a counter or indicator from a monitor's definition
1. Select the required monitor in the monitored machines tree.
2. In the right-hand pane, click "Configure counters".
Procedure 7.8. Creating a counter or indicator using the pop-up menu
2. Right-click on the selected monitor, then select the "Configure counters" option.
The Monitor Configuration Wizard is displayed.
Pressing the button erases the current selection and reinstates the automatically-configured
counters proposed by NeoLoad.
260
Monitors
Pressing the button erases the current counter selection.
The button saves the current selection of counters and their corresponding alert thresholds to a file.
The button restores the selection of counters and their corresponding alert thresholds from a file.
Pressing the "OK" button confirms all the changes made.
Pressing the "Cancel" button cancels all the changes made.
Configuring a counter or indicator

Counters are grouped by category. Each category groups counters and indicators for a common monitored
object. A counter or indicator is defined for a given monitor and for a specific category. A counter relating
to one monitor cannot be cut/pasted or moved to a monitor of a different type.
A counter returns numeric values. During a test, a counter can be viewed in the Runtime section (its value
changes during the course of the test) as well as in the Results section.
An indicator returns lines of text. During a test, an indicator can only be viewed in the Results section.
Definition
A counter's definition contains the following information:
• "Type": the default type name, non-editable.
• "Name": the visual name used to represent the counter or indicator in NeoLoad.
• "Description": a description of the counter or indicator, for the user's information purposes.
261
Monitors
Properties
A counter's properties depends on its type. See the documentation for the specific monitor type for more
information. Contextual help for each counter or indicator can be accessed
• by clicking on the "Help" link or,
• by pressing "F1" on the keyboard.
Advanced settings
Advanced settings are available for certain monitor types, such as SNMP or HTTP. These determine how
the counter's values are calculated and sampled.
• Value calculation. The value may be absolute or relative. In absolute mode, the value stored is the
value measured by the monitor on the server. In relative mode, the stored value is the variation between
the last two measured values.
For example, absolute mode is used for counters such as the size of a database's connection pool; the
value measured is exactly the value that will be used for subsequent plotting. Relative mode on the other
hand, is used for monitors such as the total count of inbound packets for a network interface; this count
increments regularly throughout the test , the interest lying more in plotting the packet reception rate
than the absolute number of packets.
• Value sampling. Sampling allows the user to select the number of values over which the stored value
is calculated. The monitoring interval is defined in the monitor's server connection. The stored value
may be a per-second average over the entire interval. This type of sampling is used for monitors such as
network interface throughputs, generally expressed in kb/s or mb/s. The stored value may also be based
on values measured throughout the measuring interval rather than on a per-second basis.
Setting and Configuring a Counter Alert Threshold

Setting a counter alert threshold
There are two ways to set an alert threshold on a counter:
Procedure 7.9. Setting an alert threshold from the counter's definition
1. Select the required counter in the monitored machines tree.
2. In the right-hand panel, click on the "Alert Thresholds" tab.
Procedure 7.10. Setting an alert threshold on a counter from the monitor's

definition
2. In the right-hand panel, click "Configure counters".
3. Select the required counter, then click on the "Alert Thresholds" tab in the right-hand panel.
The Alert Thresholds Configuration Wizard is displayed.
262
Monitors
Checking the "Enable alert triggering" check box will cause alerts to be triggered when the
alert thresholds defined for the selected counter are exceeded.
Click the button to add a new alert threshold to the selected counter.
Click the button to delete the selected alert threshold.
Click the button to move the selected alert threshold up the displayed list.
Click the button to move the selected alert threshold down the displayed list.
Click the button to restore the default alert thresholds for the selected counter.
Click the "OK" button to confirm the changes.
Click the "Cancel" button to cancel the changes.
Configuring a counter alert threshold

NeoLoad is able to set default alert thresholds. You may also modify or add counter alert thresholds
manually. Each alert threshold defines a condition under which an alert is triggered. When an alert
threshold is exceeded during a test, an alert is generated. Alerts can be viewed in the Alerts tab both in
the Runtime section and the Results section.
263
Monitors
Thresholds definition
A threshold's definition contains the following information:
• "Operand": the condition that triggers the alert.
Note
The available conditions are: lesser or equal to, greater or equal to, equal to and between two
values.
• "Value": the value that triggers the alert.
• "Delay": the triggering delay for the alert.
Note
An alert is triggered when the corresponding condition is met for a period at least equaling the
triggering delay. The triggering delay is set either for a given time or for a number of times
the condition is met.
• "Severity": the alert's severity level (critical or warning).
Note
Only one alert threshold may be exceeded at one time for one given counter. By default,
a critical alert is considered more important than a warning alert. If more than one alert
threshold is exceeded simultaneously on a same counter, the alert threshold taken as having
been exceeded will be the one that is highest placed in the list of thresholds.
264
Monitors
Note
The severity depends on the resources used for the selected counter. A critical-level alert
denotes a critical problem with a given resource that can only be resolved through the user's
intervention. A warning-level alert indicates that a resource is close to its operational limits.
• "Description": the alert description for the user's information purposes.
Note
This description appears in the final report.
Operating Systems
Linux Monitor
Supported versions
The Linux monitor has been tested on Fedora, Mandriva, Suse and Debian operating systems.
Connection settings
When creating a new monitor of this type, the protocol must be specified (Telnet or SSH).
Defining a Linux connection to a server requires the name or IP address of the machine to be monitored,
as well as the connection port. The standard access ports are port 23 for the Telnet protocol and port 22
for the SSH protocol.
A valid user account also must be entered to allow NeoLoad to connect to the server and retrieve the
performance counters to be monitored. NeoLoad can open up to three Telnet/SSH connections to the
server, depending on the counters to be monitored.
Warning
With some configurations, repeated connections to the server using the same account (e.g. root
account) may not be possible. If this is the case, and depending on the selected counters, certain
counters may not function.
In SSH mode, NeoLoad supports the following authentication methods: login / password, public key and
Keyboard-Interactive.
Note
On certain systems, the authentication must be configured in the SSH configuration file. If the
connection parameters are correct, and the authentication fails, check the SSH configuration
in the file /etc/ssh/sshd_config. Check to make sure that one of the following
parameters has the value yes: PasswordAuthentication, PubkeyAuthentication
or PAMAuthenticationViaKbdInt. In case of changes, the SSH service need to be
restarted for the change to take effect.
Creating a Linux monitor

You may create a new monitor either using the new monitored machine wizard, or from an existing
monitored machine.
265
Monitors
Depending on the type of counter selected, NeoLoad displays additional steps to select the hard disks
(Disk (per device)category counter) and processes (Process (per process)category
counter) to be monitored.
266
Monitors
Available counters
The counters available on Linux operating system are listed below.
• System.
# CPU User. Time spent running non-kernel code (user time, including nice time). Percentage of
total CPU time.
# CPU System. Time spent running kernel code (system time). Percentage of total CPU time.
# CPU Idle. Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time. Percentage of total
CPU time.
# Interruptions Count. The number of interrupts per second, including the clock.
# Context Switch Count. The number of context switches per second.
# Processes Runnable. The number of processes waiting for run time.
# Processes Runnable per CPU. The number of processes waiting for run time per CPU.
# Processes Sleeping. The number of processes in uninterruptible sleep.
# Processes Swapped. The number of processes swapped out but otherwise runnable. This field is
calculated; however, Linux never desperation swaps.
Warning
This field is not accessible on all Linux operating systems (w field in the procs section of
the vmstat command).
# CPU wait.
# Swap in. Amount of memory swapped in from disk (/s)
267
Monitors
# Swap out. Amount of memory swapped to disk (/s)
• Memory.
# Total Memory. Total usable ram (i.e. physical ram minus a few reserved bits and the kernel binary
code)
# Memory Used. Total memory - Memory free.
# Memory Free. Is sum of LowFree+HighFree (overall stat).
# Memory Buffered. Memory in buffer cache. Mostly useless as metric nowadays.
# Memory Cache. Memory in the pagecache (diskcache) minus SwapCache.
# User Memory. Memory used, except caches and buffers. (User Memory = Memory Total -
Memory Free - Memory Buffered - Memory Cache)
# % User Memory. Percentage of used memory (% User Memory = User Memory / Memory Total
* 100)
# Total Swap. Total amount of physical swap memory.
# Swap Free. Total amount of swap memory free.
# Swap Used. Swap Total - Swap Free.
• Disk (per device). The disk section counters are available per device. Outside the wizard, select the
device in the counter definition pane. A device picker is available using the 'Fill devices' button.
All the Disk counters need the iostat command installed on the server system. This command is a part
of the sysstat package. Please make sure that this command is available before using those counters.
# Disk Read Request Merged. The number of read requests merged per second issued to the device.
# Disk Write Request Merged. The number of write requests merged per second issued to the
device.
# Disk Read. The number of read requests issued to the device per second.
# Disk Write. The number of write requests issued to the device per second.
# Disk Read (sector). The number of sectors read from the device per second.
# Disk Write (sector). The number of sectors written to the device per second.
# Disk Read (KB). The number of kilobytes read from the device per second.
# Disk Write (KB). The number of kilobytes written to the device per second.
# Disk Request Size. The average size (in sectors) of the requests issued to the device.
# Queue Length. The average queue length of the requests issued to the device.
# IO Wait. The average time (in milliseconds) for I/O requests issued to the device to be served.
This includes the time spent by requests in a queue and the time spent servicing them.
# Disk Service Time. The average service time (in milliseconds) for I/O requests issued to the device.
268
Monitors
# IO CPU Time. Percentage of CPU time during which I/O requests are issued to the device
(bandwidth utilization for the device). Device saturation occurs when this value is close to 100%.
• Processes (per process). The processes section counters are available per process. Outside the
wizard, select the process identifier in the counter definition pane. A process identifier picker is available
using the '...' button.
# Process Memory Usage. Resident size (kb). The non-swapped physical memory a task has used.
# Process CPU Time. The task's share of the elapsed CPU time since the last update, expressed as
a percentage of total CPU time.
Solaris Monitor
Supported versions
The Solaris monitor has been validated on Solaris 10.
Connection settings
Defining a Solaris connection to a server requires the name or IP address of the machine to be monitored,
269
Monitors
Warning
account) may not be possible . If this is the case, and depending on the counters selected, certain
Keyboard-Interactive.
Note
Creating a Solaris monitor

monitored machine.
(Disk (per device)category counter) and processes (Process (per process)category
counter) to be monitored.
270
Monitors
Available counters
The counters available on Solaris operating system are listed below.
• System.
# CPU User. Time spent running non-kernel code (user time, including nice time). Percentage of
total CPU time.
# CPU System. Time spent running kernel code (system time). Percentage of total CPU time.
# CPU Idle. Time spent idle. Percentage of total CPU time.
# Interruptions Count. The number of interrupts per second, including the clock.
271
Monitors
# Context Switch Count. The number of context switches per second.
# Processes Runnable. The number of processes waiting for run time.
# Processes Runnable per CPU. The number of processes waiting for run time per CPU.
# Processes Sleeping. The number of processes in uninterruptible sleep.
# Processes Swapped. The number of processes swapped out but otherwise runnable. This field is
calculated; however, Linux never desperation swaps.
• Memory.
# Swap Space Available. Amount of swap space currently available (Kbytes).
# Free List Size. Size of the free list (Kbytes).
# Pages Reclaims Per Second. Report information about page faults: page reclaims per second.
# Minor Faults Per Second. Report information about page faults: minor faults.
# Paged In Per Second. Kilobytes paged in per second.
# Paged Out Per Second. Kilobytes paged out per second.
# Freed Per Second. Kilobytes freed per second.
# Anticipated Short - Term Memory Shortfall. Anticipated short-term memory shortfall (Kbytes)
per second.
# Pages Scanned by Clock Algorithm. Pages scanned by clock algorithm per second.
• Disk. The disk section counters are available per device. Outside the wizard, select the device in
the counter definition pane. A device picker is available using the 'Fill devices' button. All the
Disk counters need the iostat command installed on the server system. This command is a part of the
sysstat package. Please make sure that this command is available before using those counters.
# Disk Read. The number of read requests merged per second issued to the device.
# Disk Write. The number of write requests merged per second issued to the device.
# Disk Read (KB). The number of Kilobytes read per second.
# Disk Write (KB). The number of Kilobytes written per second.
# Transaction waiting for service. Average number of transactions waiting for service (queue
length).
# Average number of transaction. Average number of transactions actively being serviced

(removed from the queue but not yet completed)
# Percent time waiting. Percent of the time there are transactions waiting for service (queue non-
empty).
# Percent time busy. Percent of time the disk is busy (transactions in progress).
272
Monitors
• Processes. The processes section counters are available per process. Select the process identifier in
the counter definition pane. A process identifier picker is available using the '...' button.
# Process Memory Usage. Resident size (kb). The non-swapped physical memory a task has used.
# Process CPU Time. The task's share of the elapsed CPU time since the last update, expressed as
a percentage of total CPU time.
AIX Monitor
Supported versions
The AIX monitor has been validated on AIX 5
Connection settings
Defining an AIX connection to a server requires the name or IP address of the machine to be monitored,
Warning
Keyboard-Interactive
273
Monitors
Note
Creating an AIX monitor

monitored machine.
(Disk (per device)category counter) to be monitored.
274
Monitors
Available counters
The counters available on AIX operating system are listed below.
• System.
# CPU User. User time. Breakdown of percentage usage of CPU time.
# CPU System. System time. Breakdown of percentage usage of CPU time.
# CPU Idle. CPU idle time. Breakdown of percentage usage of CPU time.
# CPU Wait. CPU cycles to determine that the current process is wait and there is pending disk
input/output.
# Interruptions Count. Device interrupts. Trap and interrupt rate averages per second over the
sampling interval.
# Context Switch Count. Kernel thread context switches. Trap and interrupt rate averages per
second over the sampling interval.
# Processes Runnable. Average number of runnable kernel threads over the sampling interval.
Runnable refers to threads that are ready but waiting to run and to those threads already running.
# Processes Runnable per CPU. Average number of runnable kernel threads over the sampling
interval per CPU.
# Processes Sleeping. Average number of kernel threads placed in the VMM wait queue (awaiting
resource, awaiting input/output) over the sampling interval.
# Physical CPU. Number of physical processors consumed. Only available if the partition is running
with shared processor. (only available on micro-partitioned environments).
# Entitled consumed. The percentage of entitled capacity consumed. Only available if the partition
is running with shared processor. (Only available on micro-partitioned environments).
275
Monitors
• Memory.
# Active virtual pages. Active virtual pages.
Note
information about the usage of virtual and real memory. Virtual pages are considered active
if they have been accessed. A page is 4096 bytes.
# Free List Size. Size of the free list.
# Pager in/out list. Pager input/output list. Average pages per second over the interval.
# Paged In Per Second. Pages paged in from paging space. Average pages per second over the
interval.
# Paged Out Per Second. Pages paged out to paging space. Average pages per second over the
interval.
# Freed Per Second. Pages freed (page replacement). Average pages per second over the interval.
# Pages Scanned by page-replacement. Pages scanned by page-replacement algorithm. Average

pages per second over the interval.
# Clock cycles page-replacement. Clock cycles by page-replacement algorithm. Average clock

cycles per second over the interval.
# Data transferred (read/write). Indicates the amount of data transferred (read or written) per
second to the drive. Different suffixes are used to represent the unit of transfer. Default is in bytes
per second.
# Transfers per second. Indicates the number of transfers per second that were issued to the physical
disk. A transfer is an I/O request to the physical disk. Multiple logical requests can be combined into
a single I/O request to the disk. A transfer is of indeterminate size.
# Read transfers per second. Indicates the number of read transfers per second.
# Write transfers per second. Indicates the number of write transfers per second.
# Data read per second. Indicates the amount of data read per second, from the drive. Different
suffixes are used to represent the unit of transfer. Default is in bytes per second.
# Data written per second. Indicates the amount of data written per second, to the drive. Different
suffixes are used to represent the unit of transfer. Default is in bytes per second.
# Disk activity (percent). Indicates the percentage of time the physical disk was active (bandwidth
utilization for the drive).
276
Monitors
HP-UX Monitor
Supported versions
The HP-UX monitor has been validated on HP-UX 11.
Connection settings
Defining a HP-UX connection to a server requires the name or IP address of the machine to be monitored,
Warning
Keyboard-Interactive
Note
277
Monitors

Creating an HP-UX monitor

monitored machine.
(Disk (per device)category counter) to be monitored.
Available counters
The counters available on HP-UX operating system are listed below.
278
Monitors
• System.
# CPU User. User time for normal and low priority processes. Breakdown of percentage usage of
CPU time.
# CPU System. System time. Breakdown of percentage usage of CPU time.
# CPU Idle. CPU idle. Breakdown of percentage usage of CPU time.
# Interruptions Count. Device interrupts per second (nonclock).
# Context Switch Count. CPU context switch rate (switches/sec).
# Processes Runnable. The numbers of processes in run queue.
# Processes Runnable per CPU. The numbers of processes in run queue per CPU.
# Processes Sleeping. The numbers of processes blocked for resources (I/O, paging, etc.).
# Processes Swapped. The numbers of processes runnable or short sleeper (< 20 secs) but swapped.
• Memory.
# Active virtual pages. Active virtual pages.
Note
Virtual pages are considered active if they belong to processes that are running or have run
in the last 20 seconds.
# Free List Size. Size of the free list.
# Pages Reclaims Per Second. Report information about page faults: page reclaims per second.
(average each five second).
# Address translation faults. Report information about page faults: Address translation faults per
second. (average each five second).
# Processes swapped in. Processes swapped in per second. (average each five second).
# Processes swapped out. Processes swapped out per second. (average each five second).
# Pages paged in. Pages paged in per second. (average each five second).
# Pages pages out. Pages paged out per second. (average each five second).
# Pages freed per second. Pages freed per second. (average each five second).
# Anticipated short term memory shortfall. Anticipated short term memory shortfall. (average
each five second).
# Pages scanned by clock algorithm. Pages scanned by clock algorithm per second. (average each
five second).
279
Monitors
# Kilobytes transferred per second. The number of kilobytes transferred per second.
# Seeks per second. The number of seeks per second.
# Millisecond per average seek. The number of milliseconds per average seek.
Microsoft Monitors
Microsoft monitors allow you to monitor Microsoft servers.
• Windows monitor: monitors the operating system: CPU, memory, disk drives...
• IIS monitor: monitors Microsoft IIS web servers with the exception of dynamic pages.
• .Net monitor: monitors "ASP" and ".Net" applications.
• SQL Server monitor: monitors Microsoft SQL Server database servers.
All these monitors use the same Windows API to list and query the performance counters, namely the
Performance Data Helper (PDH) library used by the Perfmon tool that is part of Windows. The NeoLoad
monitors therefore have the same characteristics and constraints as Perfmon:
• the monitoring is done without an agent, which obviates the installation of a client or agent on the
machine to be monitored.
• the monitoring of Microsoft servers is available only for Windows controllers. It is not possible to
monitor a Microsoft server from a Unix/Linux machine.
• the appropriate user rights and settings are required to connect to the machine to be monitored. See the
section called “Connecting to a remote server”.
280
Monitors
Definition
A Microsoft monitor's definition must include the name or IP address of the machine to be monitored.
The account currently running NeoLoad also must have the appropriate user rights. See the section called
“Connecting to a remote server” for more details.
When defining a counter, and depending on the type of counter, you may also select one or more
instances. One instance corresponds to a certain sub-division of the monitored object. For example, the
Processor / Processor Time % has several instances, one for each processor present in the
monitored machine. Usually, an instance named _Total allows you to retrieve an average value across
all available instances.
Connecting to a remote server

To access a remote machine, you will need to have Authorized rights. Authorized rights are provided
to Administrators and members of the "Performance Monitor Users" Windows group, on the
monitored server. The "Performance Monitor Users" group is not available on some Windows
systems such as Windows XP.
If the current user account does not have the appropriate rights, run the Controller using the appropriate
account by right-clicking on NeoLoadGUI.exe and using the "Run as..." option. Alternatively, add the
account used to run the Controller to the "Performance Monitor Users" group on the monitored
server (or to "Administrators" group for Windows XP).
Important
The "Remote Registry" service must be started on the remote monitored machine.
Firewall settings
TCP Port 445 and TCP Port 139 must be open on firewalls. For the Windows Firewall, this can be done
by adding an exception for "File and printer sharing".
Microsoft Windows Monitor

Connection Settings
The Windows monitor allows you to monitor the operating system of Microsoft Windows servers: CPU,
memory, disk, network...
See the Microsoft monitors description for more information on how to connect to a remote server.
Creating a Windows monitor

monitored machine.
281
Monitors
Available counters
On a typical Windows server, the main, basic counters are as follows:
• Memory\Pages/sec. Detects the Pages/sec swap rate. The pages/sec rate is the speed at which the
pages are read from or written to the disk when resolving hardware page faults. A hardware page fault
occurs when a process has to access code on a physical disk because it cannot be accessed in the memory.
• Memory\Available Megabytes. Indicates how much physical memory remains after the working
sets of running processes and the cache have been served. Should be greater than 10% of the physical
memory.
• Processor\Processor Time \%. CPU activity in percentage.
• System\Processor Queue Length. This counter displays the number of threads waiting to be
executed in the queue that is shared by all processors on the system. If this counter (divided by the
number of processors) has a sustained value of five or more threads, there is a processor bottleneck.
• Physical disk\Disk Time \%. Percentage of elapsed time spent by the selected physical disk drive
executing read or write requests. More than 55% for continuous periods indicates a bottleneck.
• Network Interface\Packets/s. Rate at which packets are sent and received on the network interface.
282
Monitors
Network
RSTAT Monitor
Connection settings
RSTAT monitors allow you to monitor the rpc.rstatd daemon counters. This daemon is already installed
and running on most Solaris and Linux machines.
This protocol uses RPC calls. Its disadvantage is that it is blocked by most firewalls as it uses port 111,
the RPC port, which generally is blocked by default. This port may need to be opened to allow NeoLoad
to access the rstatd daemon.
The default connection port set by NeoLoad is 0. This setting causes NeoLoad to automatically search for
the RPC port used by the remote machine.
Creating an RSTAT monitor

monitored machine.
283
Monitors
Available counters
• System.
# CPU Usage. The percentage of CPU time, for all processors globally, taken up executing user
commands, and carrying out system tasks and I/O operations. This counter takes into account the
total number of processors in its calculation of CPU usage.
# User CPU. The percentage of CPU time, for all processors globally, taken up executing user
commands. This counter shows the CPU usage per user globally across all the processors.
# Nice CPU. The percentage of CPU time, for all processors globally, taken up by low-priority
processes. The time taken up by "nice" tasks is already taken into account in the System CPU and
User CPU times.
# System CPU. The percentage of CPU time, for all processors globally, taken up executing system
tasks, including system calls to kernel routines.
# Idle CPU. The percentage of CPU idle across all processors.
# CPU Average 1 mn. The average usage of CPU time during the last minute. This counter shows
the CPU usage globally across all the processors.
# CPU Average 5 mn. The average usage of CPU time during the last 5 minutes. This counter shows
the CPU usage globally across all the processors.
# CPU Average 15 mn. The average usage of CPU time during the last 15 minutes. This counter
shows the CPU usage globally across all the processors.
# Memory Page paged IN. The number of pages moved from the disk into cache memory.
# Memory Page paged OUT. The number of pages moved from cache memory to the disk.
# Memory Page swapped IN. The number of pages moved from swap space to storage space
284
Monitors
# Memory Page swapped OUT. The number of pages moved from storage space to swap space.
# Interruptions count. The number of interruptions occurring during a monitoring interval.
# Context switch count. The number of processor context changes per second.
• Network.
# IN packets count. The number of network packets entering per second.
# OUT packets count. The number of network packets exiting per second.
# IN errors count. The total number of network errors inbound per second.
# OUT errors count. The total number of network errors outbound per second.
# Collisions count. The number of network collisions occurring during the monitoring interval. A
collision is an undesirable event resulting from competing network packets being transmitted over
a same channel.
SNMP Monitor
Connection settings
Defining an SNMP monitor requires the name or IP address of the machine to be monitored, as well as
the connection port. The standard access port for SNMP parameters is port 161.
The connection is made through an SNMP community. The community name is required for authentication
and to allow NeoLoad to retrieve the SNMP counter values. The default community name is "public".
Creating an SNMP monitor

monitored machine.
285
Monitors
Adding counters
Adding SNMP counters is done via a dedicated pane. Each counter is defined by an OID.
To choose the OID, an MIB may be loaded. A MIB is an information base containing all the OIDs defined
for an SNMP component type. For example, router manufacturers such as Cisco provide MIBs containing
the OIDs monitoring open or waiting connections.
To load a MIB, click on the "Load MIB" button, then navigate to the MIB file. The OID tree for the MIB
is then displayed in the left-hand pane. Click on the nodes to obtain a description of the OID.
A MIB may be defined by OIDs present in other MIBs. For the MIB to load correctly, these other MIBs
must be available in the same directory.
An OID also may be entered directly in the "SNMP commands" box.
Once the OID has been specified, several commands may be executed that send requests to the server:
286
Monitors
• Get. Returns the value corresponding to the declared OID.
• Get next. Returns the value of the next OID implemented on the server after the declared OID. Please
note this OID may be in the selected MIB.
• Get all. Returns the values of all OIDs present, including those under the declared OID
Databases
Oracle DB monitor
Supported versions
NeoLoad supports most commons Oracle Database server versions: 8i, 9i, 10g and 11g.
Connection settings
Oracle monitors allow you to monitor Oracle database servers. The counters are sorted by category:
memory, call rates, cache ratio etc..
This monitor executes SQL requests on the Oracle Views dedicated to performance monitoring: V
$SYSSTAT, V$SYSTEM_EVENT, V$SGA_STAT, V$SESSION , V$LIBRARYCACHE, V$LATCH, V
$WAITSTAT, V$SQLAREA, V$VERSION.
Warning
To carry out the monitoring, NeoLoad requires an account with authorization to connect to the
database and to read all these views.
NeoLoad monitors the Oracle server using the JDBC protocol. The JDBC driver is included in the NeoLoad
software package and requires no particular installation or settings. The default connection port set by
NeoLoad is 1521, the standard JDBC port.
Using a custom JDBC connection. A specific JDBC connection URL may be defined in Advanced
Edit mode. This may be useful to provide extra connection settings to the JDBC driver, such as timeout,
cluster handling etc.
Example 7.1. Oracle JDBC URL:
jdbc:oracle:thin:@(description=(address_list=(address=(protocol=TCP)
(port=1521)(host=magnum))(source_route=yes)
(connect_data=(INSTANCE_NAME=PETSTORE)))
Creating an Oracle monitor

monitored machine.
287
Monitors
Available counters
• Sessions.
# Active. The number of sessions currently executing SQL on the database. The System sessions
are excluded.
# % Active. The percentage of sessions currently executing SQL on the database compared to the
total ones. The System sessions are excluded.
# Inactive. The number of sessions pending on the database. The System sessions are excluded.
# System. The number of sessions used by the System for management.
# Idle. The number of sessions that have not executed SQL since the last time the performance
monitor looked at the database.
• Call Rates.
# Parse. The calls per second for Parse (hard and soft). A soft parse is a check on an object already
in the shared pool, to verify that the permissions on the underlying object have not changed. A hard
parse is a very expensive operation in terms of memory use, because it requires Oracle to allocate a
workheap and other memory structures and then build a parse tree.
# Execute. The calls (user and recursive) per second that executed SQL statements.
# Commit. The calls per second for a commit. When a user commits a transaction, the redo generated
that reflects the changes made to database blocks must be written to disk. Commits often represent
the closest thing to a user transaction rate.
# Rollback. The calls per second for rollback. Rollbacks occur when users manually issue the
ROLLBACK statement or an error occurs during a user's transactions.
• Miss Rates.
288
Monitors
# Buffer Cache. Percentage of missed buffer cache. The buffer cache miss ratio is a measure of the
proportion of requests for data which is unsatisfied by data already in the buffer cache. Lower ratios
are better as access to data in memory is speedier than an IO operation to disk.
Tip
There comes a point of diminishing returns when increasing the size of the database buffer.
Also, remember that this is part of the SGA and it may be more important to use additional
memory for other parts of the SGA. It is vital that the whole SGA fits within main memory,
as paging of the SGA is disastrous for performance.
Note
Performance is optimum when this value is low.
Note
Oracle parameters that can be modified to improve this statistic: DB_BLOCK_BUFFER.
# SQL Area. Percentage of missed SQL cache. SQL shared pool reloads occur when Oracle has to
implicitly re-parse SQL or PL/SQL at the point when it attempts to execute it.
Tip
Larger shared pool will reduce the number of times that code needs to be reloaded. Also,
ensuring that similar pieces of SQL are written identically will increase sharing of code. To
take advantage of additional memory available for shared SQL areas, you may also need to
increase the number of cursors permitted for a session.
Note
Note
Oracle parameters that can be modified to improve this statistic: SHARED_POOL_SIZE,
OPEN_CURSORS.
# Latch. Percentage of latch get after a wait. Latches are simple, low-level serialization mechanisms
to protect shared data structures in the SGA. When attempting to get a latch, a process may have to
wait and then retry.
Note
• Indexed Queries.
# Percentage. The percentage of requests to the database using indexed queries.
289
Monitors
Note
A value of 90 percent or higher for this ratio is recommended. A lower value might be
acceptable in a data-warehousing or decision-support system where the full table scans are
frequently used.
• Logical IO.
# Block Changes. The blocks per second for Block Changes. This statistic counts the total number
of changes that were part of an update or delete operation that were made to all blocks in the SGA.
Such changes generate redo log entries and hence become permanent changes to the database if the
transaction is committed. This approximates total database work.
# Current Reads. The blocks per second for Current Reads. It counts the number of times a
CURRENT block was requested per second.
# Consistent Reads. The blocks per second for Consistent Reads. It counts the number of times a
consistent read was requested for a block. Transactions running alone in a database always see the
same state of data, plus any changes they make themselves. That state is called "consistent read" if
a transaction reads the same record twice, it sees the same data unless it changed the data itself. If
a transaction running alone in a database reads all the records in a table once, it will see exactly the
same number of records with the same contents the next time it reads the table, give or take changes
it makes itself. Write and read locks alone do not produce consistent reads.
• Physical IO.
# Datafile Reads. The blocks of data read from the disk per second. This number equals the value
of reads directly from the disk plus all reads into buffer cache.
Note
In high bandwidth, data-intensive operations such as parallel query, reads of disk blocks
bypass the buffer cache to maximize transfer rates and to prevent the premature aging of
shared data blocks resident in the buffer cache.
# Datafile Writes. The blocks of data written to the disk per second. This number equals the value
of writes directly to the disk plus all writes from buffer cache.
# Redo Writes. The redo blocks written per second by LGWR (Log writer process) to the redo log
files.
• Event Waits. These counters display the seconds waited per second on a particular usage. The waits
can be parallel and this number may exceed 1 second.
# Control File IO.
# DB File IO.
# Direct Path read.
# Log File write.
# SQL*Net.
# Buffer busy.
290
Monitors
• SGA Memory. These counters display the size in kilobytes of SGA (System Global Area) memory
allocated to the pools or buffers.
# Fixed SGA.
# Buffer Cache.
# Log Buffer.
# Shared Pool. Free memory allocated to the shared pool.
# Large Pool. Free memory allocated to the large pool.
# Java Pool. Free memory allocated to the Java pool.
• Miscellaneous.
# Direct Reads Ratio. The ratio of direct physical reads compared to all the direct reads. Direct reads
are performed for parallel scans, and reads from temporary table spaces. Blocks are read directly into
private buffers in the PGA, rather than into the database buffer cache in the SGA. There are no cache
hits, because blocks are not searched for in the cache before being read. And there are no subsequent
cache hits, because the blocks are just discarded after use, rather than cached.
# Library Cache Get Hit Ratio. The proportion of requests for a lock on an object which were
satisfied by finding that object's handle already in memory.
Note
Performance is optimum when this value is high.
Note
OPEN_CURSORS.
# Library Cache Pin Hit Ratio. The proportion of attempts to pin an object which were satisfied
by finding all the pieces of that object already in memory.
Note
Performance is optimum when this value is high.
Note
OPEN_CURSORS.
# Recursive Calls Ratio. A high ratio of recursive calls to total calls may indicate any of the
following:
# Dynamic extension of tables due to poor sizing
# Growing and shrinking of rollback segments due to unsuitable OPTIMAL

settings
291
Monitors
# Large amounts of sort to disk resulting in creation and deletion

of temporary segments
# Data dictionary misses
# Complex triggers, integrity constraints, procedures, functions and/

or packages
Note
# CPU Parse Overhead. The CPU parse overhead is the proportion of database CPU time being
spent in parsing SQL and PL/SQL code. High values of this figure indicate that either a large amount
of once-only code is being used by the database or that the shared SQL area is too small.
Note
Note
Oracle parameters that can be modified to improve this statistic: SORT_AREA_SIZE.
# Free List Contention. Free list contention occurs when more than one process is attempting to
insert data into a given table. The table header structure maintains one or more lists of blocks which
have free space for insertion. If more processes are attempting to make insert than there are free lists
some will have to wait for access to a free list.
Note
Performance is optimum when this value is very low.
# Chained Fetch Ratio. This is a proportion of all rows fetched which resulted in a chained row
continuation. Such a continuation means that data for the row is spread across two blocks, which can
occur in either of two ways:
# Row Migration. This occurs when an update to a row cannot fit within the current block. In
this case, the data for the row is migrated to a new block leaving a pointer to the new location in
the original block.
# Row Chaining. This occurs when a row cannot fit into a single data block, e.g. due to having
large or many fields. In this case, the row is spread over two or more blocks.
Note
Performance is optimum when this value is very low.
# Cursor Authentications. Number of privilege checks conducted during execution of an operation
# Opened Cursors. Total number of current open cursors.
292
Monitors
• Top SQL Statements. Top 3 SQL Statements related to a resource consumption during the test.
These counters are only available at the end of the test, not in real-time while the test is running. SQL
requests made by the system itself (SYS and SYSTEM based schemas) are excluded.
# CPU. SQL Statements that cause the highest CPU resource consumption.
# Physical Reads. SQL Statements that cause the highest number disk reads.
# Logical Reads. SQL Statements that hits the most the buffer.
# Rows Processed. SQL Statements that causes the highest total number of rows processed.
# Sorts. SQL Statements that causes the highest number of sorts that were done for all the child
cursors.
# Parse Calls. SQL Statements that causes the highest number of parse calls to all the child cursors
under this parent.
# Executed. SQL Statements that causes the highest number of executions, totaled over all the child
cursors.
# CPU per Execution. SQL Statements that cause the highest average of CPU resource consumption
per execution of the statement.
# Physical Reads per Execution. SQL Statements that cause the highest average of disk reads per
execution.
# Logical Reads per Execution. SQL Statements that hits, in average, the most the buffer per
execution.
# Rows Processed per Execution. SQL Statements that causes the highest average number of rows
processed per execution.
# Sorts per Execution. SQL Statements that causes the highest average of sorts that were done for
all the child cursors, per execution.
# Parse Calls per Execution. SQL Statements that causes the highest average of parse calls to all
the child cursors under this parent, per execution.
• Description. Textual description about the server.
# Database Components version. The version of the Oracle database.
293
Monitors
Microsoft SQL Server Monitor

Supported Versions
SQL Server monitors allow you to monitor all versions of Microsoft SQL Server.
Connection settings
The available performance objects are:
• SQL Server
• All objects starting with "MSSQL$SQLEXPRESS:"
Note
As the monitor uses the same technology as the Perfmon monitoring tool included with
Windows, NeoLoad is able to access all the counters available for SQL Server.
Creating an SQL Server monitor

monitored machine.
294
Monitors
Available counters
• SQL Server\Buffer Management: Buffer cache hit ratio \%. Indicates how often SQL Server goes
to the buffer, not the hard disk, to get data. Should be greater than 85.
• SQL Server\Memory Manager: Total Server Memory (KB). If this reaches the level of the overall
server memory, it means the server needs more RAM.
• SQL Server\general statistics : User connections. Number of users connected to the system.
295
Monitors
MySQL Monitor
Supported versions
NeoLoad supports most common MySQL Database server versions: 4.0, 4.1, 5.x and 6.0.
Connection settings
MySQL monitor allows the user to monitor a MySQL database server. The counters are sorted by category:
connections, read rates, query cache usage etc..
This monitor executes SQL requests on the database to obtain status and system variables. To carry out
the monitoring, NeoLoad requires an account with authorization to connect to the database and to read
and collect global status data and variables.
NeoLoad monitors the MySQL server using the JDBC protocol. The JDBC driver is included in the
NeoLoad software package and requires no particular installation or settings. The default connection port
set by NeoLoad is 3306, the standard JDBC port.
Using a custom JDBC connection. A specific JDBC connection URL may be defined in Advanced
Edit mode. This may be useful to provide extra connection settings to the JDBC driver, such as timeout,
cluster handling etc.
Example 7.2. MySQL JDBC URL:

jdbc:mysql://myhostname:3306/mydatabase?connectTimeout=30000
Creating a MySQL monitor

You may create a new monitor either using the New Monitored Machine Wizard, or from an existing
monitored machine.
Available counters
• Connections.
296
Monitors
# Threads connected. The number of currently open connections.
# Threads cached. The number of threads in the thread cache.
# Threads running. The number of threads that are not sleeping.
# Attempts. The number of connection attempts (successful or not) to the MySQL server.
# Aborted clients. The number of connections aborted (client died without closing the connection
properly) per second to the MySQL server.
# Aborted connects. The number of failed connections per second to the MySQL server.
# Max used. The maximum number of connections that have been in use simultaneously since the
server started.
# Outstanding connection requests. The number of outstanding connection requests MySQL can
have. This comes into play when the main MySQL thread gets very many connection requests in
a very short time. It then takes some time (although very little) for the main thread to check the
connection and start a new thread. The back_log value indicates how many requests can be stacked
during this short time before MySQL momentarily stops answering new requests. You need to
increase this only if you expect a large number of connections in a short period of time.
# Max allowed. The number of simultaneous client connections allowed. By default, this is 150,
beginning with MySQL 5.1.15. (Previously, the default was 100.)
# Max allowed per user. The maximum number of simultaneous connections allowed to any given
MySQL account. A value of 0 means “no limit.”
# Max threads cached. How many threads the server should cache for reuse. When a client
disconnects, the client's threads are put in the cache if there are fewer than thread_cache_size
threads there. Requests for threads are satisfied by reusing threads taken from the cache if possible,
and only when the cache is empty is a new thread created. This variable can be increased to
improve performance if you have a lot of new connections. (Normally, this doesn't provide a notable
performance improvement if you have a good thread implementation.)
• IO Requests.
# Bytes received. The number of bytes received from all clients.
# Bytes sent. The number of bytes sent to all clients.
# Open files. The number of files that are open.
• Select Rates.
# Select full join. The number of joins that perform table scans because they do not use indexes. If
this value is not 0, you should carefully check the indexes of your tables.
# Select full range join. The number of joins that used a range search on a reference table.
# Select range. The number of joins that used ranges on the first table. This is normally not a critical
issue even if the value is quite large.
# Select range check. The number of joins without keys that check for key usage after each row. If
this is not 0, you should carefully check the indexes of your tables.
297
Monitors
# Select scan. The number of joins that did a full scan of the first table.
• Read Rates.
# Handler read first. The number of times the first entry was read from an index. If this value is
high, it suggests that the server is doing a lot of full index scans; for example, SELECT col1 FROM
foo, assuming that col1 is indexed.
# Handler read key. The number of requests to read a row based on a key. If this value is high, it is
a good indication that your tables are properly indexed for your queries.
# Handler read next. The number of requests to read the next row in key order. This value is
incremented if you are querying an index column with a range constraint or if you are doing an index
scan.
# Handler read previous. The number of requests to read the previous row in key order. This read
method is mainly used to optimize ORDER BY ... DESC.
# Handler read random. The number of requests to read a row based on a fixed position. This value
is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of
queries that require MySQL to scan entire tables or you have joins that don't use keys properly.
# Handler read random next. The number of requests to read the next row in the data file. This
value is high if you are doing a lot of table scans. Generally this suggests that your tables are not
properly indexed or that your queries are not written to take advantage of the indexes you have.
• Key Rates.
# Key blocks not flushed. The number of key blocks in the key cache that have changed but have
not yet been flushed to disk.
# Key blocks unused. The number of unused blocks in the key cache. You can use this value to
determine how much of the key cache is in use.
# Key blocks used. The number of used blocks in the key cache. This value is a high-water mark
that indicates the maximum number of blocks that have ever been in use at one time.
# Key read requests (cache). The number of requests to read a key block from the cache.
# Key reads (disk). The number of physical reads of a key block from disk. If Key_reads is large,
then your key_buffer_size value is probably too small.
# Key write requests (cache). The number of requests to write a key block to the cache.
# Key writes (disk). The number of physical writes of a key block to disk.
• Commands Rates.
# Flush commands. The number of executed FLUSH statements.
# Handler commit. The number of internal COMMIT statements.
# Handler delete. The number of times that rows have been deleted from tables.
# Handler rollback. The number of requests for a storage engine to perform a rollback operation.
# Handler savepoint. The number of requests for a storage engine to place a savepoint.
298
Monitors
# Handler savepoint rollback. The number of requests for a storage engine to roll back to a
savepoint.
# Handler update. The number of requests to update a row in a table.
# Handler write. The number of requests to insert a row in a table.
• Query Cache.
# Query cache free blocks. The number of free memory blocks in the query cache.
# Query cache free memory. The amount of free memory for the query cache.
# Query cache hits. The number of query cache hits.
# Query cache inserts. The number of queries added to the query cache.
# Query cache low memory prunes. The number of queries that were deleted from the query cache
because of low memory.
# Not cached queries. The number of non-cached queries (not cacheable, or not cached due to the
query_cache_type setting).
# Cached queries. The number of queries registered in the query cache.
# Total blocks. The total number of blocks in the query cache.
• Tables.
# Open tables. The number of tables that are open.
# Opened tables. The number of tables that have been opened. If Opened_tables is big, your
table_open_cache value is probably too small.
# Table locks immediate. The number of times that a table lock was acquired immediately.
# Table locks waited. The number of times that a table lock could not be acquired immediately and
a wait was needed. If this is high and you have performance problems, you should first optimize your
queries, and then either split your table or tables or use replication.
# Table open cache. The number of open tables for all threads. Increasing this value increases the
number of file descriptors that mysqld requires.
# Max heap table size. This variable sets the maximum size to which MEMORY tables are allowed
to grow. The value of the variable is used to calculate MEMORY table MAX_ROWS values. Setting
this variable has no effect on any existing MEMORY table, unless the table is re-created with a
statement such as CREATE TABLE or altered with ALTER TABLE or TRUNCATE TABLE.
• Memory.
# Binlog cache size. The size of the cache to hold the SQL statements for the binary log during a
transaction. A binary log cache is allocated for each client if the server supports any transactional
storage engines and if the server has the binary log enabled (--log-bin option). If you often use large,
multiple-statement transactions, you can increase this cache size to get more performance.
# Bulk insert buffer size. MyISAM uses a special tree-like cache to make bulk inserts faster for
INSERT ... SELECT, INSERT ... VALUES (...), (...), ..., and LOAD DATA INFILE when adding
299
Monitors
data to non-empty tables. This variable limits the size of the cache tree in bytes per thread. Setting it
to 0 disables this optimization. The default value is 8MB.
# Join buffer size. The size of the buffer that is used for joins that do not use indexes and thus
perform full table scans. Normally, the best way to get fast joins is to add indexes. Increase the value
of join_buffer_size to get a faster full join when adding indexes is not possible. One join buffer is
allocated for each full join between two tables. For a complex join between several tables for which
indexes are not used, multiple join buffers might be necessary.
# Key buffer size. Index blocks for MyISAM tables are buffered and are shared by all threads.
key_buffer_size is the size of the buffer used for index blocks. The key buffer is also known as the
key cache. The maximum allowable setting for key_buffer_size is 4GB. The effective maximum size
might be less, depending on your available physical RAM and per-process RAM limits imposed by
your operating system or hardware platform. Increase the value to get better index handling (for all
reads and multiple writes) to as much as you can afford. Using a value that is 25% of total memory
on a machine that mainly runs MySQL is quite common. However, if you make the value too large
(for example, more than 50% of your total memory) your system might start to page and become
extremely slow. MySQL relies on the operating system to perform file system caching for data reads,
so you must leave some room for the file system cache.
# % Key buffer size. Percentage of the index block buffer used.
Warning: this value is an approximation because some space in the key buffer is be allocated internally
for administrative structures.
# Max binlog size. If a write to the binary log causes the current log file size to exceed the value of
this variable, the server rotates the binary logs (closes the current file and opens the next one). You
cannot set this variable to more than 1GB or to less than 4096 bytes. The default value is 1GB. A
transaction is written in one chunk to the binary log, so it is never split between several binary logs.
# Preload buffer size. The size of the buffer that is allocated when preloading indexes.
# Query alloc block size. The allocation size of memory blocks that are allocated for objects created
during statement parsing and execution. If you have problems with memory fragmentation, it might
help to increase this a bit.
# Read buffer size. Each thread that does a sequential scan allocates a buffer of this size (in bytes)
for each table it scans. If you do many sequential scans, you might want to increase this value, which
defaults to 131072.
# Read random buffer size. When reading rows in sorted order following a key-sorting operation,
the rows are read through this buffer to avoid disk seeks. Setting the variable to a large value can
improve ORDER BY performance by a lot. However, this is a buffer allocated for each client, so
you should not set the global variable to a large value. Instead, change the session variable only from
within those clients that need to run large queries.
# Sort buffer size. Each thread that needs to do a sort allocates a buffer of this size. Increase this
value for faster ORDER BY or GROUP BY operations.
# Transaction alloc block size. The amount in bytes by which to increase a per-transaction memory
pool which needs memory.
# Transaction prealloc size. There is a per-transaction memory pool from which various
transaction-related allocations take memory. The initial size of the pool in bytes is
transaction_prealloc_size. For every allocation that cannot be satisfied from the pool because it has
300
Monitors
insufficient memory available, the pool is increased by transaction_alloc_block_size bytes. When the
transaction ends, the pool is truncated to transaction_prealloc_size bytes.
• Miscellaneous.
# Slow queries. The number of queries that have taken more than long_query_time seconds.
# Long query time. If a query takes longer than this many seconds, the server increments the
Slow_queries status variable. If you are using the --log-slow-queries option, the query is logged to
the slow query log file. This value is measured in real time, not CPU time, so a query that is under
the threshold on a lightly loaded system might be above the threshold on a heavily loaded one. The
minimum value is 1. The default is 10.
# Slow launch threads. The number of threads that have taken more than slow_launch_time seconds
to create.
# Slow launch time. If creating a thread takes longer than this many seconds, the server increments
the Slow_launch_threads status variable.
# Sort merge passes. The number of merge passes that the sort algorithm has had to do. If this value
is large, you should consider increasing the value of the sort_buffer_size system variable.
# Sort range. The number of sorts that were done using ranges.
# Sort rows. The number of sorted rows.
# Sort scan. The number of sorts that were done by scanning the table.
# Not flushed delayed rows. The number of rows waiting to be written in INSERT DELAY queues.
# Database Version. The version of the MySQL database.
301
Monitors
DB2 Monitor
Configuration
NeoLoad monitors the DB2 server using the JDBC protocol. To monitor a DB2 server, you must place
the driver and license jars in the NeoLoad's lib/jdbcDrivers folder. You can find these files in the
DB2 Server installation at the following location:
• <DB2 Server>/java/db2jcc.jar
• <DB2 Server>/java/db2jcc_license_xx.jar
or in previous versions:
• <DB2 server>/SQLLIB/java/db2jcc.jar
• <DB2 server>/SQLLIB/java/db2jcc_license_xx.jar
Supported versions
NeoLoad supports most common DB2 Database server versions from 8.1 upwards.
Warning
NeoLoad does not support the DB2 database versions for AS400.
Connection settings
The DB2 monitor allows the user to monitor a DB2 database server. The counters are sorted by category:
connections, catalog cache, IO requests, command rates, tables memory, pool, joins etc.
This monitor executes SQL requests on the database to obtain status data and system variables. To carry
out the monitoring, NeoLoad requires an account with authorization to connect to the database and to read
and collect global status data and variables. The account must belong to the DB2ADMNS system group.
The default connection port set by NeoLoad is 50000, the standard JDBC port.
For NeoLoad to collect the indicators for the most resource-hungry requests (see Top Statements below),
the monitoring switches on the database server must be activated. These are the commands required to
activate the switches:
• All indicators: this switch allows NeoLoad to retrieve the list of SQL requests.
db2 update dbm cfg using dft_mon_stmt on
• CPU time indicator: this switch allows NeoLoad to retrieve the CPU time (in milliseconds) for each
SQL request.
db2 update dbm cfg using dft_mon_uow on
• Sort time indicator: this indicator allows NeoLoad to retrieve the sort times for each SQL request.
db2 update dbm cfg using dft_mon_sort on
The database server must be restarted for these changes to take effect.
302
Monitors
Using custom JDBC connection. A specific JDBC connection URL, used to provide extra connection
parameters to the JDBC driver such as timeout, cluster handling etc., may be defined in the Advanced
Edit Mode.
Example 7.3. DB2 JDBC URL:

jdbc:db2://myserver:50000/
mydatabase;traceLevel=(com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL)
Creating a DB2 monitor

monitored machine.
Available counters
• Connections.
# Remote connections. The current number of connections initiated from remote clients to the
instance of the database manager that is being monitored.
# Connections executing requests. The number of remote applications that are currently connected
to a database and are currently processing a unit of work within the database manager instance being
monitored.
Warning
This monitor is not available in versions 9.x and higher.
# Idle agents. The number of agents in the agent pool that are currently unassigned to an application
and therefore "idle".
You can use this element to help set the num_poolagents configuration setting. Having idle agents
available to service requests for agents can improve performance.
• Catalog Cache.
303
Monitors
# Catalog cache lookups. The number of times that the catalog cache was referenced to obtain table
descriptor information or authorization information.
This element includes both successful and unsuccessful accesses to the catalog cache. The catalog
cache is referenced whenever:
# a table, view, or alias name is processed during the compilation of an SQL statement.
# database authorization information is accessed.
# a routine is processed during the compilation of an SQL statement .
# Catalog cache inserts. The number of times that the system tried to insert table descriptor or
authorization information into the catalog cache.
# Catalog cache overflows. The number of times that the catalog cache overflowed the bounds of
its allocated memory.
If cat_cache_overflows is high, the catalog cache may be too small for the workload. Enlarging
the catalog cache may improve its performance.
• IO Requests.
# Direct reads. The number of read operations that do not use the buffer pool.
# Direct writes. The number of write operations that do not use the buffer pool.
# Direct read time. The elapsed time (in milliseconds) required to perform the direct reads.
A high average time may indicate an I/O conflict.
# Direct write time. The elapsed time (in milliseconds) required to perform the direct writes.
A high average time may indicate an I/O conflict.
• Command Rates.
# Select statements. The number of SQL SELECT statements that were executed. You can use this
element to determine the level of database activity.
# Commit statements. The total number of SQL COMMIT statements that have been attempted.
A small rate of change in this counter during the monitor period may indicate that applications are
not doing frequent commits, which may lead to problems with logging and data concurrency.
# Rollback statements. The total number of SQL ROLLBACK statements that have been attempted.
You should try to minimize the number of rollbacks, since higher rollback activity results in lower
throughput for the database.
# Update/insert/delete statements. The number of SQL UPDATE, INSERT, and DELETE

statements that were executed. You can use this element to determine the level of database activity.
# Overflow accesses. The number of accesses (reads and writes) to overflowed rows of tables.
Overflowed rows indicate that data fragmentation has occurred. If this number is high, you may be
able to improve database performance by reorganizing the database.
304
Monitors
Warning
This monitor is not available in versions 9.x and higher.
• Tables.
# Rows read. This is the number of rows read from the tables.
# Rows inserted. This is the number of row insertions attempted. You can use this element to gain
insight into the current level of activity within the database.
# Rows deleted. This is the number of row deletions attempted. You can use this element to gain
# Rows updated. This is the number of row updates attempted. You can use this element to gain
• Memory.
# Committed private memory. The amount of private memory that the instance of the database
manager has currently committed.
You can use this element to help set the min_priv_mem configuration parameter to ensure you
have enough private memory available.
# Total log space used. The total amount of active log space (in bytes) currently used in the database.
Use this element in conjunction with Log space available to determine whether you need to
adjust the following configuration parameters to avoid running out of log space:
# logfilsiz
# logprimary
# logsecond
# Log space available. The amount of active log space in the database that is not being used by
uncommitted transactions.
# Log pages read. The number of log pages read from disk by the logger.
You can use this element with an operating system monitor to quantify the amount of I/O on a device
that is attributable to database activity.
# Log pages write. The number of log pages written to disk by the logger.
You may use this element with an operating system monitor to quantify the amount of I/O on a device
that is attributable to database activity.
# Secondary logs allocated. The total number of secondary log files that are currently being used
for the database.
If this value is consistently high, you may need larger log files, or more primary log files, or more
frequent COMMIT statements within your application.
• Pool.
305
Monitors
# Pool data logical reads. Indicates the number of data pages which have been requested from the
buffer pool (logical) for regular and large table spaces.
# % Pool data logical reads. Percentage of data pages which have been requested from the buffer
pool (logical) for regular and large table spaces compared to data pages read in from the table space
containers (physical).
# Pool data physical reads. Indicates the number of data pages read in from the table space
containers (physical) for regular and large table spaces.
# Pool index logical reads. Indicates the number of index pages which have been requested from
the buffer pool (logical) for regular and large table spaces.
# % Pool index logical reads. Percentage of index pages which have been requested from the buffer
pool (logical) for regular and large table spaces compared to index pages read in from the table space
containers (physical).
# Pool index physical reads. Indicates the number of index pages read in from the table space
containers (physical) for regular and large table spaces.
# Pool index writes. Indicates the number of times a buffer pool index page was physically written
to disk.
# Pool read time. Indicates the total amount of time spent reading in data and index pages from the
table space containers (physical) for all types of table spaces. This value is given in microseconds.
# Pool write time. Provides the total amount of time spent physically writing data or index pages
from the buffer pool to disk. Elapsed time is given in microseconds.
• Hash Joins.
# Total hash joins. The total number of hash joins executed.
Use this value in conjunction with hash_join_overflows to determine if a significant

percentage of hash joins would benefit from modest increases in the sort heap size.
# Hash joins overflows. The number of times that hash join data exceeded the available sort heap
space.
# % Hash joins overflows. Percentage of hash join data exceeded the available sort heap space.
• Miscellaneous.
# Locks waiting. Indicates the number of agents waiting on a lock.
If this number is high, the applications may have concurrency problems; you should therefore identify
applications that are holding locks or exclusive locks for long periods of time.
# Locks held. The number of locks currently held. This is the total number of locks currently held
by all applications in the database.
# Deadlocks. The total number of deadlocks that have occurred.
This element can indicate that applications are experiencing contention problems. These problems
could be caused by the following situations:
306
Monitors
# Lock escalations are occurring for the database.
# An application may be locking tables explicitly when system-generated row locks may be
sufficient.
# An application may be using an inappropriate isolation level when binding.
# Catalog tables are locked for repeatable read.
# Applications are getting the same locks in different orders, resulting in deadlock..
You may be able to resolve the problem by determining in which applications (or application
processes) the deadlocks are occurring. You may then be able to modify the application to better
enable it to execute concurrently.
# Active sorts. The number of sorts in the database that currently have a sort heap allocated.
# Total sorts. The total number of sorts that have been executed. This value includes heaps for sorts
of temporary tables that were created during relational operations.
# Sorts overflows. The total number of sorts that ran out of sort heap and may have required disk
space for temporary storage.
When a sort overflows, additional overhead will be incurred because the sort will require a merge
phase and can potentially require more I/O, if data needs to be written to disk.
# % Sorts overflows. Percentage of sorts that ran out of sort heap and may have required disk space
for temporary storage.
When a sort overflows, additional overhead will be incurred because the sort will require a merge
phase and can potentially require more I/O, if data needs to be written to disk.
# Version. DB2 database server version.
• Top Statements.
# CPU. The three requests having consumed the most processor time.
# Rows read. The three requests having read the most rows from the database.
# Rows written. The three requests having written the most rows from the database.
# Sort time. The three requests with the longest sort times.
# Sort overflows. The three requests with the highest number of sort overflows.
307
Monitors
PostgreSQL Monitor
Supported versions
NeoLoad supports most common PostgreSQL Database server versions: 6.x, 7.x and 8.x.
Connection settings
PostgreSQL monitors allow you to monitor a PostgreSQL database server. The counters are sorted by
category: connections, read rates, query cache usage etc.
This monitor executes SQL requests on the database to obtain status data and system variables. To carry
out the monitoring, NeoLoad requires an account with authorization to connect to the database and to read
and collect global status data and variables.
NeoLoad monitors the PostgreSQL server using the JDBC protocol. The JDBC driver is included in the
NeoLoad software package and requires no particular installation or settings. The default connection port
set by NeoLoad is 5432, the standard JDBC port.
Using a custom JDBC connection. A specific JDBC connection URL, used to provide extra connection
parameters to the JDBC driver such as timeout, cluster handling etc.,may be defined in the Advanced Edit
Mode.
Example 7.4. PostgreSQL JDBC URL:
jdbc:postgresql://myserver:5432/mydatabase?loginTimeout=3000
Creating a PostgreSQL monitor

monitored machine.
308
Monitors
Available counters
• Connections.
# Current connections. The number of currently open connections.
# Connections executing requests. The number of currently open connections that are executing
requests.
# Idle connections. The number of currently idle connections.
# Max connections. The maximum number of concurrent connections to the database server.
# Used connections. Connections used as a percentage of maximum connections.
• Buffers.
# Shared buffers size. Current size of shared buffers.
# Disk cache size. Current size of disk cache buffer.
# Sort buffer size. Current size of sort buffer.
# Work buffer size. Current size of working requests buffer.
# Temp buffer size. Current size of temporary buffer.
• IO Requests.
# Blocks read. Number of blocks directly read on disk.
For optimal performance this value should be the smallest possible. If the database has to execute too
many disk accesses, performance will suffer.
# Index blocks read. Number of index blocks directly read on disk.
309
Monitors
# % Index blocks read. Percentage of index blocks directly read on disk.
# Sequence blocks read. Number of sequence blocks directly read on disk.
• Cache.
# Blocks read. Number of cached blocks read.
# Index blocks read. Number of cached index blocks read.
# % Index blocks read. Percentage of cached index blocks read.
For optimal performance, this value must be as large as possible. If an insufficient number of index
blocks are declared in the table, it could negatively impact the database server's performance.
# Sequence blocks read. Number of cached sequence blocks read.
• Index.
# Index read. Number of reads initiated by an index.
# Indexed rows read. Number of rows read by indexed requests.
# Indexed rows fetched. Number of live rows fetched by indexed requests.
• Command Rates.
# Rows read. Number of rows read.
# Rows fetched. Number of rows fetched.
# Inserted rows. Number of rows inserted.
# Updated rows. Number of rows updated.
# Deleted rows. Number of rows deleted.
# Committed transactions. Number of committed transactions.
This value should be relatively stable, indicating that there are no performance-reducing load peaks.
If applications do not commit often enough, it will lead to an overload on the database server.
# Rolled back transactions. Number of transactions rolled back.
# % Rolledback transactions. Percentage of transactions rolled back.
• Locks.
# Locks waiting. Number of locks waiting.
# Locks held. Number of locks held.
# Process holding locks. Number of processes holding locks.
• Description.
# Server version. Current version of the PostgreSQL database server.
310
Monitors
Web/EJB Tier
Microsoft IIS Monitor
Supported Versions
IIS monitor allows you to monitor all versions of Microsoft IIS (Internet Information Services).
Connection settings
• Internet Information Services Global

• Web Service
• Web Service Cache
• HTTP Indexing Service
Note
Windows, NeoLoad is able to access all the counters available for IIS.
Creating an IIS monitor

monitored machine.
311
Monitors
Apache Monitor
Configuration
Monitoring an Apache server requires the mod_status module, which publishes a dynamic page
containing the server's performance counters.
Apache monitors allow you to monitor any server that publishes a web page in the compatible format.
Whatever the application or application server (J2EE, PHP, .Net...), you need to develop a specific page
in order to publish the custom counters. See the section called “Using custom counters”.
Configuring the Apache server

For NeoLoad to be able to retrieve data from an Apache server, the mod_status module must be enabled.
To do this, you need to edit the httpd.conf file and include the commented out line:
LoadModule status_module modules/mod_status.so
To restrict access to the status report to machines on the foo.com domain, the following code must be
added to the httpd.conf configuration file:
<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>
Enabling extended statistics is recommended. This is done by editing the ExtendedStatus setting in
the httpd.conf file.
To check the Apache configuration, access the address http://<your.server.name>/server-

status from the NeoLoad controller machine. A page with the Apache server statistics should be
displayed.
312
Monitors
Using custom counters

To monitor a server other than an Apache, you need to develop a page containing the counters to be
monitored. This page must return the data in the format name: value, the value being numeric.
Example:
nameCounter1: 10
nameCounter2: -23.567
nameCounter2: +17.33
...
During the monitoring phase, NeoLoad queries the server regularly and records the counters' values.
Connection settings
The monitor definition requires a server (defined in the Servers section of the Virtual User profiles) and
a path. You may either create a server in the Servers section, or use one already created during a recording.
Creating an Apache monitor

monitored machine.
Available counters
Advanced settings are available for all HTTP monitors. These settings determine how the monitors' values
are calculated and sampled.
Apache web server

When extended statistics are enabled (ExtendedStatus setting in the httpd.conf file set to On), the
available counters are:
313
Monitors
• Total Accesses. Total access count since the server started

• Total kBytes. Total volume delivered in bytes since the server started
• Uptime. Time during which the server was running
• ReqPerSec. Average number of requests per second since the server started
• BytesPerSec. Average number of bytes delivered per second
• BytesPerReq. Average number of bytes per request
Default counters are:
• BusyWorkers. Number of child processes actively processing requests

• %BusyWorkers. Percentage of the number of child processes actively processing requests
• IdleWorkers. Number of child processes idle
Other web servers

The available counters are those that follow the counterName: counterValue syntax and whose
value is an integer or a real number.
Microsoft .Net Monitor

Supported Versions
.NET monitor allow you to monitor all versions of Microsoft .NET applications.
Connection settings
• Active Server Pages

• ASP.Net
• ASP.Net Apps vx.x.xxx
314
Monitors
• .NET CLR Loading

• .NET CLR Memory
• .NET CLR jit
• .NET CLR Network
• ...
Note
Windows, NeoLoad is able to access all the counters available for .Net and ASP applications.
Creating a .NET monitor

monitored machine.
Available counters
• ASP.NET\Requests Queued. The number of queued ASP requests that are waiting to be processed
• ASP.NET\Requests Executing. The number of ASP requests currently executing
• ASP.NET\Request Wait Time. The number of milliseconds that the most recent ASP request was
waiting in the queue. Warning, this value can be somewhat misleading because it is not an average.
• ASP.NET\Request Execution Time. The number of milliseconds that the most recent ASP request
took to execute. Warning, this value can be somewhat misleading because it is not an average.
315
Monitors
WebLogic 8 Monitor
Configuration
Before using the WebLogic monitor, the WebLogic server's jar must be installed in NeoLoad's jmxlib/
weblogic8 directory.
Copy the weblogic.jar file from the WebLogic server/lib directory to jmxlib/weblogic8
directory, then re-start NeoLoad for the change to take effect.
Connection settings
Defining a monitor to a WebLogic server requires the name or IP address of the machine to be monitored,
as well as the connection port (the default port is 7001). In addition to these settings, the domain to
be monitored must be provided, together with the valid user account used to connect to the WebLogic
Administration Console.
Creating a WebLogic 8 monitor

monitored machine.
316
Monitors
NeoLoad displays a list of the EARs (Enterprise Archive) and WARs (Web Application archive) deployed
on the configured server. It then automatically selects the most appropriate counters for each of the selected
applications.
Available counters
The first tree level displays all the servers running within the WebLogic Server domain. For each
WebLogic server, the counters are:
• Server. This section allows the user to monitor the sockets open for each server.
# SocketsOpenedTotalCount. Total number of sockets opened by this server.
# OpenSocketsCurrentCount. Number of sockets currently opened by this server.
317
Monitors
# ComponentsVersion. Description for WebLogic components version.
• Session. This section allows the user to monitor all session counters for each EAR deployed on this
server, and for each WAR contained therein.
# OpenSessionsCurrentCount. Current total number of open sessions in this module.
# OpenSessionsHighCount. Highest number of open sessions in this module. The count starts at
zero each time the module is activated.
# SessionsOpenedTotalCount. Total number of sessions opened in this module.
• JDBC Connection Pool. This section allows the user to monitor the JDBC connection pool counters.
The counters are available for each server or connexion pool.
# ActiveConnectionsCurrentCount. Number of physical database connections from this instance

of the connection pool currently in use.
# WaitingForConnectionCurrentCount. Current number of application requests waiting for a

connection.
# NumUnavailable. Number of connections currently unavailable to applications because the

connection is being tested or refreshed.
# ActiveConnectionsAverageCount. Average number of active connections in this instance of the

JDBC connection pool.
# ConnectionDelayTime. Average time taken, in milliseconds, to create a physical database

connection. The time is calculated as the sum of the time taken to create all physical database
connections in the connection pool, divided by the total number of connections created.
# ActiveConnectionsHighCount. Highest number of active database connections in this instance of

the connection pool since the connection pool was instantiated. Active connections are connections
in use by an application.
# ConnectionsTotalCount. Total number of database connections created in this instance of the

connection pool since the connection pool was instantiated.
# CurrCapacity. Current number of database connections in this instance of the connection pool.
The number includes available connections, connections in use by applications, and connections
unavailable for testing.
# % CurrCapacity. Percentage of database connections in this instance of the connection pool.
# FailuresToReconnectCount. Number of times this instance of the connection pool attempted to

refresh a connection to a database and failed. Failures occur when the database is unavailable or when
the network fails.
# HighestNumUnavailable. Highest number of unavailable connections in this instance of the

# MaxCapacity. Maximum number of database connections this connection pool can contain.
# WaitSecondsHighCount. Highest number of seconds an application waited for a connection from

this instance of the connection pool since the connection pool was instantiated.
318
Monitors
# WaitingForConnectionHighCount. Highest number of application requests concurrently waiting

for a connection from this instance of the connection pool.
# PoolConfiguration. Textual description for data source pool configuration.
• JRockit. This section allows the user to monitor the runtime counters for each server instance on the
JRockit Virtual Machine. The following counters are presented for each server:
# AllProcessorsAverageLoad. Average load of all processors in the host machine.
Note
This value is between 0 and 1 where 1 represents 100% load (no idle time) and 0 represents
0% load (pure idle time).
# JvmProcessorLoad. The load that this Virtual Machine is placing on all processors in the host
machine. If the host contains multiple processors, this is a snapshot of the average load.
Note
# HeapFreeCurrent. Current amount of memory (in bytes) that is available in this Virtual Machine.
# HeapSizeCurrent. Current size (in bytes) of this Virtual Machine
# FreeHeap. Amount (in bytes) of Java heap memory that is currently free in this Virtual Machine.
# UsedHeap. Amount (in bytes) of Java heap memory that is currently being used by the Virtual
Machine.
# % UsedHeap. Percentage of amount of Java heap memory that is currently being used by the
Virtual Machine.
# TotalHeap. Amount (in bytes) of memory currently allocated to this Virtual Machine's Java heap.
# HeapSizeMax. Maximum amount (in bytes) of memory of this Virtual Machine's Java heap.
# FreePhysicalMemory. Amount (in bytes) of physical memory that is currently free on the host
computer.
# UsedPhysicalMemory. Amount (in bytes) of physical memory that is currently being used on the
host computer. The value describes the memory that is being used by all processes on the computer,
not just by this Virtual Machine.
# TotalPhysicalMemory. Amount (in bytes) of physical memory on the host computer. The value
does not include memory that the operating system makes available through swap space on a disk
or other types of virtual memory.
# NumberOfDaemonThreads. Number of daemon Java threads currently running in this Virtual

Machine across all processors.
# NumberOfProcessors. Number of processors on this Virtual Machine's host machine. If this is

not a Symmetric Multi Processor (SMP) system, the value will be 1.
319
Monitors
# TotalGarbageCollectionCount. Number of garbage collection runs that have occurred since this
Virtual Machine was started.
# TotalGarbageCollectionTime. Number of milliseconds that this Virtual Machine has spent on all
garbage collection runs since the Virtual Machine was started.
# TotalNumberOfThreads. Number of Java threads (daemon and non-daemon) that are currently
running in this Virtual Machine across all processors.
# TotalNurserySize. Amount (in bytes) of memory that is currently allocated to the nursery. If you
are not using a generational garbage collector, the nursery size is 0.
# Version. Textual description of JVM Version.
# OS. Textual description of Operating System running WebLogic server.
• JVM. This section allows the user to collect information for each server on the Java Virtual Machine.
The available counters are:
# HeapFreeCurrent. Available memory in bytes for this Virtual Machine.
# HeapSizeCurrent. Total memory size in bytes for this Virtual Machine.
# Version. Textual description of JVM Version.
• Connector. A connector component (also called a resource adapter) is a system-level software

driver used by an application server such as WebLogic Server to connect to an EIS. A resource
adapter serves as the "J2EE connector." The WebLogic J2EE Connector Architecture supports resource
adapters developed by Enterprise Information Systems (EISes) vendors and third-party application
developers that can be deployed in any application server supporting the Sun Microsystems J2EE
Platform Specification, Version 1.3. Resource adapters contain the Java, and if necessary, the native
components required to interact with the EIS.
# ConnectionPoolsTotalCount. Total size of the connection pool.
# ConnectionPoolCurrentCount. Size of connection pool at the time of the counter's query.
• JMS Servers. This section allows the user to monitor the JMS runtime counters for all JMS Servers
both globally and for each server instance.
# Total. This section allow the user to monitor JMS counters for all JMS Servers of this WebLogic
server.
# ConnectionsCurrentCount. Current number of connections for all JMS Server.
# ConnectionsHighCount. Highest number of connections to this server since the last reset.
# ConnectionsTotalCount. Total number of connections made to this server since the last reset.
# JMSServersCurrentCount. Current number of JMS servers deployed on this WebLogic Server

instance.
# JMSServersHighCount. Highest number of JMS servers deployed on this WebLogic Server

instance since this server was started.
320
Monitors
# JMSServersTotalCount. Total number of JMS servers deployed on this WebLogic Server

# Servers. This section allow the user to monitor each JMS Server of this WebLogic server.
# DestinationsCurrentCount. Number of current destinations for this JMS server.
# DestinationsHighCount. Highest number of destinations on this JMS server since the last reset.
# DestinationsTotalCount. Number of destinations instantiated on this JMS server since the last
reset.
# MessagesCurrentCount. Number of messages currently stored on this JMS server. This number
does not include the pending messages.
# MessagesHighCount. Highest number of messages stored in the JMS server since the last reset.
# MessagesPendingCount. Number of messages currently pending (unacknowledged or

uncommitted) stored on this JMS server. Pending messages are over and above the current number
of messages.
# MessagesReceivedCount. Number of messages received on this destination since the last reset.
# SessionPoolsCurrentCount. Number of session pools currently instantiated on this JMS server.
# SessionPoolsHighCount. Highest number of session pools instantiated on this JMS server since
the last reset.
# SessionPoolsTotalCount. Number of session pools instantiated on this JMS server since the
last reset.
• JTA. This section allows the user to monitor the transaction counters for this WebLogic server. All
values are calculated per interval.
# TransactionTotalCount. Total number of transactions processed by this server.
# TransactionCommittedTotalCount. Total number of transactions committed by this server.
# TransactionRolledBackTotalCount. Total number of transactions rolled back by this server.
# % TransactionRolledBackTotalCount. Percentage of total number of transactions rolled back

by this server.
# TransactionRolledBackTimeoutTotalCount. Number of transactions rolled back by this server

due to a timeout expiration.
# TransactionRolledBackResourceTotalCount. Number of transactions rolled back by this server

due to a resource error.
# TransactionRolledBackAppTotalCount. Number of transactions rolled back by this server due

to an application error.
# TransactionRolledBackSystemTotalCount. Number of transactions rolled back by this server

due to an internal system error.
321
Monitors
# TransactionHeuristicsTotalCount. Total number of transactions completed with a heuristic

status.
# TransactionAbandonedTotalCount. Total number of transactions abandoned by this server.
# ActiveTransactionsTotalCount. Number of active transactions on this server.
# SecondsActiveTotalCount. Average amount of time (in milliseconds) that transactions

coordinated by this server have taken to commit.
• Queue. This section allows the user to monitor counters for each WebLogic Queue of this WebLogic
Server.
# PendingRequestCurrentCount. Number of waiting requests in the queue.
# ServicedRequestTotalCount. Number of requests that have been processed by the queue.
# ExecuteThreadTotalCount. Total number of execute threads assigned to the queue.
# ExecuteThreadCurrentIdleCount. Number of idle threads assigned to the queue.
# % ExecuteThreadCurrentIdleCount. Percentage of idle threads assigned to the queue.
• EJB. This section allows the user to monitor all instances, transactions and cache counters for each
EAR deployed on this server, and for each EJB contained therein.
# Pool. Monitors EJB instances for Entity Beans, Message-Driven Beans and Stateless Beans.
# AccessTotalCount. Total number of times an attempt was made to get an instance from the
free pool.
# BeansInUseCurrentCount. Number of bean instances currently being used from the free pool.
# DestroyedTotalCount. Total number of times a bean instance from this pool was destroyed due
to a non-application exception being thrown from it.
# MissTotalCount. Total number of times a failed attempt was made to get an instance from the
free pool. An Attempt to get a bean from the pool will fail if there are no available instances in
the pool.
# PooledBeansCurrentCount. Number of currently available bean instances in the free pool.
# TimeoutTotalCount. Total number of threads that have timed out waiting for an available bean
instance from the free pool.
# WaiterCurrentCount. Number of threads currently waiting for an available bean instance from
the free pool.
# Transaction. Monitors transaction counters for Entity Beans, MessageDriven Beans, Stateless
Beans and Stateful Beans.
# TransactionsCommittedTotalCount. Total number of transactions that have been committed

for this EJB.
# TransactionsRolledBackTotalCount. Total number of transactions that have been rolled back

for this EJB.
322
Monitors
# TransactionsTimedOutTotalCount. Total number of transactions that have timed out for this
EJB.
# Cache. Monitors cache counters for Entity Beans and Stateful Beans.
# ActivationCount. Total number of beans from this EJB that have been activated (beans that
have been de-serialized by the application server).
# CacheAccessCount. Total number of attempts to access a bean from the cache.
# CachedBeansCurrentCount. Total number of beans from this EJB currently in the EJB cache.
# CacheMissCount. Total number of times an attempt to access a bean from the cache failed.
# PassivationCount. Total number of beans from this EJB that have been passivated (beans that
have been serialized by the application server).
WebLogic 9/10 Monitor

Configuration
Before using the WebLogic monitor, several of the WebLogic server's jars must be installed in NeoLoad's
<neoload>/jmxlib/weblogic9 or <neoload>/jmxlib/weblogic10 directory.
Copy the following files from the WebLogic directory to <neoload>/jmxlib/weblogic9 or

<neoload>/jmxlib/weblogic10 directory:
• <weblogic>/server/lib/wlclient.jar
• <weblogic>/server/lib/wljmxclient.jar
Once these files have been copied, restart NeoLoad for the changes to take effect.
323
Monitors
Connection settings
Defining a monitor to a WebLogic Administration Server domain requires the name or IP address of the
machine to be monitored, as well as the connection port of the Weblogic Administration Console (the
default port is 7001). In addition to these settings, a valid user account must be provided with which to
connect to the WebLogic Administration Console.
WebLogic 9/10 monitor connects to WebLogic Administration Server, so please make sure that the
WebLogic Administration Server is running. If there is only one WebLogic Server, it will automatically
act as a WebLogic Administration Server domain. If there are several WebLogic servers (with or without
clustering), please start up the WebLogic Administration Server domain.
Creating a WebLogic 9/10 monitor

monitored machine.
applications.
324
Monitors
Available counters
The first tree level displays all the servers running within the WebLogic Server domain. For each
WebLogic server, the counters are:
• Server. This section allows the user to monitor the sockets open for each server.
# SocketsOpenedTotalCount. Total number of sockets opened by this server.
# OpenSocketsCurrentCount. Number of sockets currently opened by this server.
• Session. This section allows the user to monitor all session counters for each EAR deployed on this
server, and for each WAR contained therein.
# OpenSessionsCurrentCount. Current total number of open sessions in this module.
# OpenSessionsHighCount. Highest number of open sessions in this module. The count starts at
zero each time the module is activated.
# SessionsOpenedTotalCount. Total number of sessions opened in this module.
• JDBC Connection Pool. This section allows the user to monitor the JDBC connection pool counters.
The counters are available for each connexion pool of this server.
# ActiveConnectionsCurrentCount. Number of physical database connections from this instance

of the connection pool currently in use.
# WaitingForConnectionCurrentCount. Current number of application requests waiting for a

connection.
# NumUnavailable. Number of connections currently unavailable to applications because the

connection is being tested or refreshed.
# ActiveConnectionsAverageCount. Average number of active connections in this instance of the

JDBC connection pool.
325
Monitors
# ConnectionDelayTime. Average time taken, in milliseconds, to create a physical database

connection. The time is calculated as the sum of the time taken to create all physical database
connections in the connection pool, divided by the total number of connections created.
# ActiveConnectionsHighCount. Highest number of active database connections in this instance of

the connection pool since the connection pool was instantiated. Active connections are connections
in use by an application.
# ConnectionsTotalCount. Total number of database connections created in this instance of the

# CurrCapacity. Current number of database connections in this instance of the connection pool.
The number includes available connections, connections in use by applications, and connections
unavailable for testing.
# % CurrCapacity. Percentage of database connections in this instance of the connection pool.
# FailuresToReconnectCount. Number of times this instance of the connection pool attempted to

refresh a connection to a database and failed. Failures occur when the database is unavailable or when
the network fails.
# HighestNumUnavailable. Highest number of unavailable connections in this instance of the

# MaxCapacity. Maximum number of database connections this connection pool can contain.
# WaitSecondsHighCount. Highest number of seconds an application waited for a connection from

this instance of the connection pool since the connection pool was instantiated.
# WaitingForConnectionHighCount. Highest number of application requests concurrently waiting

for a connection from this instance of the connection pool.
• JRockit. This section allows the user to monitor the runtime counters for each server instance on the
JRockit Virtual Machine. The following counters are presented for each server:
# AllProcessorsAverageLoad. Average load of all processors in the host machine.
Note
# JvmProcessorLoad. The load that this Virtual Machine is placing on all processors in the host
machine. If the host contains multiple processors, this is a snapshot of the average load.
Note
# HeapFreeCurrent. Current amount of memory (in bytes) that is available in this Virtual Machine.
# HeapSizeCurrent. Current size (in bytes) of this Virtual Machine
# FreeHeap. Amount (in bytes) of Java heap memory that is currently free in this Virtual Machine.
326
Monitors
# UsedHeap. Indicates the amount (in bytes) of Java heap memory that is currently being used by
the Virtual Machine.
# % UsedHeap. Percentage of amount of Java heap memory that is currently being used by the
Virtual Machine.
# TotalHeap. Amount (in bytes) of memory currently allocated to this Virtual Machine's Java heap.
# FreePhysicalMemory. Amount (in bytes) of physical memory that is currently free on the host
computer.
# UsedPhysicalMemory. Amount (in bytes) of physical memory that is currently being used on the
host computer. The value describes the memory that is being used by all processes on the computer,
not just by this Virtual Machine.
# TotalPhysicalMemory. Amount (in bytes) of physical memory on the host computer. The value
does not include memory that the operating system makes available through swap space on a disk
or other types of virtual memory.
# NumberOfDaemonThreads. Number of daemon Java threads currently running in this Virtual

Machine across all processors.
# NumberOfProcessors. Number of processors on this Virtual Machine's host machine. If this is

not a Symmetric Multi Processor (SMP) system, the value will be 1.
# TotalGarbageCollectionCount. Number of garbage collection runs that have occurred since this
Virtual Machine was started.
# TotalGarbageCollectionTime. Number of milliseconds that this Virtual Machine has spent on all
garbage collection runs since the Virtual Machine was started.
# TotalNumberOfThreads. Number of Java threads (daemon and non-daemon) that are currently
running in this Virtual Machine across all processors.
# TotalNurserySize. Amount (in bytes) of memory that is currently allocated to the nursery. If you
are not using a generational garbage collector, the nursery size is 0.
• JVM. This section allows the user to collect information for each server on the Java Virtual Machine.
The available counters are:
# HeapFreeCurrent. Available memory in bytes for this Virtual Machine.
# HeapSizeCurrent. Total memory size in bytes for this Virtual Machine.
• Connector. A connector component (also called a resource adapter) is a system-level software

driver used by an application server such as WebLogic Server to connect to an EIS. A resource
adapter serves as the "J2EE connector." The WebLogic J2EE Connector Architecture supports resource
adapters developed by Enterprise Information Systems (EISes) vendors and third-party application
developers that can be deployed in any application server supporting the Sun Microsystems J2EE
Platform Specification, Version 1.3. Resource adapters contain the Java, and if necessary, the native
components required to interact with the EIS.
# ConnectionPoolsTotalCount. Total size of the connection pool.
# ConnectionPoolCurrentCount. Size of connection pool at the time of the monitor's query.
327
Monitors
• JMS Servers. This section allows the user to monitor the JMS runtime counters for all JMS Servers
both globally and for each server instance.
# Total. This section allow the user to monitor JMS counters for all JMS Servers of this WebLogic
server.
# ConnectionsCurrentCount. Current number of connections for all JMS Server.
# ConnectionsHighCount. Highest number of connections to this server since the last reset.
# ConnectionsTotalCount. Total number of connections made to this server since the last reset.
# JMSServersCurrentCount. Current number of JMS servers deployed on this WebLogic Server

instance.
# JMSServersHighCount. Highest number of JMS servers deployed on this WebLogic Server

# JMSServersTotalCount. Total number of JMS servers deployed on this WebLogic Server

# Servers. This section allow the user to monitor each JMS Server of this WebLogic server.
# DestinationsCurrentCount. Number of current destinations for this JMS server.
# DestinationsHighCount. Highest number of destinations on this JMS server since the last reset.
# DestinationsTotalCount. Number of destinations instantiated on this JMS server since the last
reset.
# MessagesCurrentCount. Number of messages currently stored on this JMS server. This number
does not include the pending messages.
# MessagesHighCount. Highest number of messages stored in the JMS server since the last reset.
# MessagesPendingCount. Number of messages currently pending (unacknowledged or

uncommitted) stored on this JMS server. Pending messages are over and above the current number
of messages.
# MessagesReceivedCount. Number of messages received on this destination since the last reset.
# SessionPoolsCurrentCount. Number of session pools currently instantiated on this JMS server.
# SessionPoolsHighCount. Highest number of session pools instantiated on this JMS server since
the last reset.
# SessionPoolsTotalCount. Number of session pools instantiated on this JMS server since the
last reset.
• JTA. This section allows the user to monitor the transaction counters for this WebLogic server. All
values are calculated per interval.
# TransactionTotalCount. Total number of transactions processed by this server.
# TransactionCommittedTotalCount. Total number of transactions committed by this server.
# TransactionRolledBackTotalCount. Total number of transactions rolled back by this server.

328
Monitors
# TransactionRolledBackTimeoutTotalCount. Number of transactions rolled back by this server

due to a timeout expiration.
# TransactionRolledBackResourceTotalCount. Number of transactions rolled back by this server

due to a resource error.
# TransactionRolledBackAppTotalCount. Number of transactions rolled back by this server due
to an application error.
# TransactionRolledBackSystemTotalCount. Number of transactions rolled back by this server

due to an internal system error.
# TransactionHeuristicsTotalCount. Total number of transactions completed with a heuristic

status.
# TransactionAbandonedTotalCount. Total number of transactions abandoned by this server.
# ActiveTransactionsTotalCount. Number of active transactions on this server.
# SecondsActiveTotalCount. Average amount of time (in milliseconds) that transactions

coordinated by this server have taken to commit.
• Queue. This section allows the user to monitor counters for each WebLogic Queue of this WebLogic
Server.
# PendingRequestCurrentCount. Number of waiting requests in the queue.
# ExecuteThreadTotalCount. Total number of execute threads assigned to the queue.
# ServicedRequestTotalCount. Number of requests that have been processed by the queue.
# ExecuteThreadCurrentIdleCount. Number of idle threads assigned to the queue.
• EJB. This section allows the user to monitor all instances, transactions and cache counters for each
EAR deployed on this server, and for each EJB contained therein
# Pool. Monitors EJB instances for Entity Beans, MessageDriven Beans and Stateless Beans.
# AccessTotalCount. Total number of times an attempt was made to get an instance from the
free pool.
# BeansInUseCurrentCount. Number of bean instances currently being used from the free pool.
# DestroyedTotalCount. Total number of times a bean instance from this pool was destroyed due
to a non-application exception being thrown from it.
# MissTotalCount. Total number of times a failed attempt was made to get an instance from the
free pool. An Attempt to get a bean from the pool will fail if there are no available instances in
the pool.
# PooledBeansCurrentCount. Number of currently available bean instances in the free pool.
# TimeoutTotalCount. Total number of threads that have timed out waiting for an available bean
instance from the free pool.
# WaiterCurrentCount. Number of threads currently waiting for an available bean instance from
the free pool.
329
Monitors
# Transaction. Monitors transaction counters for Entity Beans, MessageDriven Beans, Stateless
Beans and Stateful Beans
# TransactionsCommittedTotalCount. Total number of transactions that have been committed

for this EJB.
# TransactionsRolledBackTotalCount. Total number of transactions that have been rolled back

for this EJB.
# TransactionsTimedOutTotalCount. Total number of transactions that have timed out for this
EJB.
# Cache. Monitors cache counters for Entity Beans and Stateful Beans.
# ActivationCount. Total number of beans from this EJB that have been activated (beans that
have been de-serialized by the application server).
# CacheAccessCount. Total number of attempts to access a bean from the cache.
# CachedBeansCurrentCount. Total number of beans from this EJB currently in the EJB cache.
# CacheMissCount. Total number of times an attempt to access a bean from the cache failed.
# PassivationCount. Total number of beans from this EJB that have been passivated (beans that
have been serialized by the application server).
• Thread. Monitors thread pool information for the WebLogic Server.
# CompletedRequestCount. Number of completed requests in the priority queue.
# ExecuteThreadIdleCount. Number of idle threads in the pool. This count does not include standby
threads and stuck threads. The count indicates threads that are ready to pick up new work when it
arrives.
# ExecuteThreadTotalCount. Total number of threads in the pool.
# HoggingThreadCount. Number of threads that are being hogged by a request right now. These
threads will either be declared as stuck after the configured timeout or will return to the pool before
that. The self-tuning mechanism will backfill if necessary.
# MinThreadsConstraintsCompleted. Number of requests with min threads constraint picked up

out of order for execution immediately since their min threads requirement was not met. This does
not include the case where threads are idle during schedule.
# MinThreadsConstraintsPending. Number of requests that should be executed now to satisfy the

min threads requirement.
# PendingUserRequestCount. Number of pending user requests in the priority queue. The priority
queue contains requests from internal subsystems and users. This is just the count of all user requests.
# QueueLength. Number of pending requests in the priority queue. This is the total of internal system
requests and user requests.
# StandbyThreadCount. Number of threads in the standby pool. Surplus threads that are not needed
to handle the present work load are designated as standby and added to the standby pool. These threads
are activated when more threads are needed.
330
Monitors
# Throughput. Mean number of requests completed per second
• Channel. This section allows the user to monitor the channels (network access points from the
WebLogic Server). The counters are available for each channel.
# AcceptCount. Number of sockets that have been accepted on this channel. This includes sockets
both past and present so gives a good idea of the connection rate to the server.
# ConnectionsCount. Number of active connections and sockets associated with this channel.
# MessagesReceivedCount. Number of messages received on this channel.
# MessagesSentCount. Number of messages sent on this channel.
# JVM or JRockit.
# Version. Textual description for the Java Runtime running WebLogic server.
WebSphere Monitor
Configuration
Before using the WebSphere monitor, several of the WebSphere server's jars must be installed in
NeoLoad's jmxlib/websphere directory.
WebSphere 6.0 configuration

To connect NeoLoad to WebSphere 6.0, copy the following files from the WebSphere directory to the
<neoload>/jmxlib/websphere directory:
331
Monitors
• <websphere>/AppServer/java/jre/lib/ibmcertpathprovider.jar
• <websphere>/AppServer/java/jre/lib/ext/ibmjceprovider.jar
• <websphere>/AppServer/etc/tmx4jTransform.jar
• <websphere>/AppServer/lib/admin.jar
• <websphere>/AppServer/lib/bootstrap.jar
• <websphere>/AppServer/lib/classloader.jar
• <websphere>/AppServer/lib/client.jar
• <websphere>/AppServer/lib/emf.jar
• <websphere>/AppServer/lib/ffdc.jar
• <websphere>/AppServer/lib/idl.jar
• <websphere>/AppServer/lib/iwsorb.jar
• <websphere>/AppServer/lib/j2ee.jar
• <websphere>/AppServer/lib/mail-impl.jar
• <websphere>/AppServer/lib/management.jar
• <websphere>/AppServer/lib/nls.jar
• <websphere>/AppServer/lib/pmi.jar
• <websphere>/AppServer/lib/pmij2ee.jar
• <websphere>/AppServer/lib/ras.jar
• <websphere>/AppServer/lib/runtime.jar
• <websphere>/AppServer/lib/sas.jar
• <websphere>/AppServer/lib/soap.jar
• <websphere>/AppServer/lib/utils.jar
• <websphere>/AppServer/lib/wasjmx.jar
• <websphere>/AppServer/lib/wasproduct.jar
• <websphere>/AppServer/lib/wsexception.jar
• <websphere>/AppServer/lib/wsprofile.jar
• <websphere>/AppServer/lib/wssec.jar
• <websphere>/AppServer/lib/wssoap.jar
• <websphere>/AppServer/lib/security.jar

To connect NeoLoad to WebSphere 6.1, copy the following files from the WebSphere directory to
the<neoload>/jmxlib/websphere directory:
• <websphere>/AppServer/runtimes/com.ibm.ws.admin.client_6.1.0.jar
• <websphere>/AppServer/runtimes/
com.ibm.ws.webservices.thinclient_6.1.0.jar
• <websphere>/AppServer/plugins/com.ibm.ws.runtime_6.1.0.jar
• <websphere>/AppServer/java/jre/lib/ibmjsseprovider2.jar
• <websphere>/AppServer/lib/webadmin/management.jar
If you are using the FixPack 11 or later, you must also copy the following file:
• AppServer\plugins\org.eclipse.osgi_*.jar

To connect NeoLoad to WebSphere 7.0, copy the following files from the WebSphere directory to
the<neoload>/jmxlib/websphere directory:
332
Monitors
• <websphere>/AppServer/runtimes/com.ibm.ws.admin.client_7.0.0.jar
• <websphere>/AppServer/runtimes/
com.ibm.ws.webservices.thinclient_7.0.0.jar
• <websphere>/AppServer/plugins/com.ibm.ws.runtime.jar
• <websphere>/AppServer/java/jre/lib/ibmjsseprovider2.jar
• <websphere>/AppServer/java/jre/lib/ibmjgssprovider.jar
• <websphere>/AppServer/lib/webadmin/management.jar
Supported versions
The WebSphere monitor supports WebSphere 6.0.X, WebSphere 6.1.X and WebSphere 7.0.X.
Connection settings
Defining a monitor for a WebSphere server requires the name or IP address of the machine to be monitored,
as well as the connection port (the default port is 8880). The port is the WebSphere server's SOAP
connection port (SOAP_CONNECTOR_ADDRESS in the administration console). In addition to these
settings, a valid user account must be provided with which to connect to the WebSphere Administration
Console.
Warning
NeoLoad requires the PMI interface to be enabled on the monitored WebSphere server. To enable
it from the WebSphere Administration Console, click on the Servers > Applications
servers node, and select the server. Then click on the Configuration tab and check
the Enable Performance Monitoring option. Confirm the changes and re-start the
application server for the new settings to take effect.
Creating a WebSphere monitor

monitored machine.
333
Monitors
NeoLoad automatically selects the most appropriate counters available on the server, for example, failed
transactions, data pool states...
Available Counters
WebSphere counters are automatically determined, based on all the Manageable Objects available. Since
WebSphere counters are dynamic, retrieving all the counters can take several seconds. Clicking on a
counter displays its description. These are the most common categories.
• JDBC Provider. Data counters for this category contain usage information about the JDBC
connection pools for a database. Examples include the number of managed connections or physical
connections and the total number of connections or connection handles.
• ThreadPool. Data counters for this category contain information about the thread pools for Object
Request Broker (ORB) threads and the Web container pools used to process HTTP requests. Examples
include the number of threads created and destroyed, the maximum number of pooled threads allowed,
and the average number of active threads in the pool.
Note
The % UsedPoolSize/count counter shows the percentage of the current thread pool
used. This figure may exceed 100% if the thread pool has been configured to be extensible:
in this case, the application server allows the maximum number of threads configured to be
exceeded.
• JVM (Java Virtual Machine API). Data counters for this category contain information about the
memory used by a process, as reported by JVM runtime. Examples are the total memory available and
the amount of free memory for the JVM. JVM runtime also includes data from the JVMPI. This data
provides detailed information about the JVM running the application server.
• Session manager. Data counters for this category contain usage information for HTTP sessions.
Examples include the total number of accessed sessions and the average number of concurrently active
HTTP sessions.
334
Monitors
JBoss Monitor
Configuration
Before using a JBoss monitor, several of the JBoss server's jars must be installed in NeoLoad's jmxlib/
jboss directory.
JBoss 4.X configuration

To connect NeoLoad to JBoss 4.X, several of the JBoss server's jars must be installed in NeoLoad's
jmxlib/jboss directory.
Copy to <neoload>/jmxlib/jboss directory the following files from the JBoss directory :
• <jboss>/client/jbossall-client.jar
• <jboss>/lib/jboss-jmx.jar
• <jboss>/server/<your-jboss-instance>/lib/jboss-management.jar
JBoss 5.X configuration

To connect NeoLoad to JBoss 5.X, several of the JBoss server's jars must be installed in NeoLoad's
jmxlib/jboss directory.
Copy to <neoload>/jmxlib/jboss directory the following files from the JBoss directory :
• <jboss>/lib/jboss-jmx.jar
• <jboss>/common/lib/jboss-management.jar
• <jboss>/client/jboss-client.jar
• <jboss>/client/jboss-common-core.jar
• <jboss>/client/jboss-integration.jar
• <jboss>/client/jboss-javaee.jar
• <jboss>/client/jboss-logging-spi.jar
• <jboss>/client/jboss-remoting.jar
• <jboss>/client/jboss-security-spi.jar
• <jboss>/client/jboss-serialization.jar
• <jboss>/client/jbosssx-as-client.jar
• <jboss>/client/jbosssx-client.jar
• <jboss>/client/jmx-invoker-adaptor-client.jar
• <jboss>/client/jnp-client.jar
Supported versions
Several JBoss server versions are supported, such as JBoss 4.0.X, JBoss 4.2.X and JBoss 5.X. NeoLoad
automatically hides any counters that are not supported by a particular JBoss version.
Connection settings
Defining a connection to a JBoss server requires the name or IP address of the machine to be monitored, as
well as the connection port (the default port is 1099). The port is your JBoss server's JNP connection port
335
Monitors
For JBoss 4.0.X and 4.2.X, connection port is the Port attribute in the Mbean referenced
by org.jboss.naming.NamingService in the server\<your-jboss-instance>\conf
\jboss-service.xml file.
<mbean code="org.jboss.naming.NamingService"
name="jboss:service=Naming"
xmbean-dd="resource:xmdesc/NamingService-xmbean.xml">
...

<attribute name="Port">1099</attribute>
...
For JBoss 5.0.X, connection port is the Port attribute of the service named jboss:service=Naming
in the server\<your-jboss-instance>\conf\bindings.xml file.


<bean class="org.jboss.services.binding.ServiceBindingMetadata">
<property name="serviceName">jboss:service=Naming</property>
<property name="bindingName">Port</property>
<property name="port">1099</property>
</bean>
For JBoss 5.1.X, connection port is the Port attribute of the service named jboss:service=Naming
in the server\<your-jboss-instance>\conf\bindingservice.beans\META-INF
\bindings-jboss-beans.xml file.


<bean class="org.jboss.services.binding.ServiceBindingMetadata">
<property name="serviceName">jboss:service=Naming</property>
<property name="bindingName">Port</property>
<property name="port">1099</property>
</bean>
If the JBoss server has been configured for secured JNP, a valid user account must be provided with which
to connect to the JBoss Administration Console.
Note
If the JBoss server is being monitored from behind a firewall, the following ports must be opened:
• 1099 (configurable via the Port attribute in the jboss-service.xml file)
• 1098 (configurable via the RmiPort attribute in the jboss-service.xml file)
• 4444 (configurable via the RmiObjectPort attribute in the jboss-service.xml file)
Creating a JBoss monitor

monitored machine.
336
Monitors
applications.
Available counters
All JBoss counters are documented here. Depending on the JBoss version, some counters may be
automatically hidden because they are not supported by this particular JBoss version.
• Cache. This section allows the user to monitor the cache for each application.
# cacheSize. Current cache size in KB.
# hitsCount. Number of cache hits since last call.
337
Monitors
# accessCount. Number of accesses to the cache since last call.
• Session. This section allows the user to monitor the sessions for each application.
# activeSessions. Number of active sessions at this moment.
# sessionCounter. Number of sessions created by this manager since last call.
# maxActive. Maximum number of active sessions so far.
# sessionMaxAliveTime. Longest time an expired session had been alive.
# sessionAverageAliveTime. Average time an expired session had been alive.
# rejectedSessions. Number of sessions rejected since last call due to maxActive being reached.
# % rejectedSessions. Percentage of sessions rejected since last call due to maxActive being
reached.
# expiredSessions. Number of sessions that expired ( doesn't include explicit invalidations ) since
last call.
• RequestProcessor. Provides management information on the processed requests.
# requestCount. Number of requests processed by this processor since last call.
# errorCount. Number of errors since last call.
# % errorCount. Percentage of errors since last call.
# bytesSent. Number of bytes sent by this processor since last call.
# maxTime. Longest time a request processing take.
# processingTime. Request processor processing time since last call.
• DataSource. Provides data source connection pool information for each data source.
# InUseConnectionCount. Number of connections currently in use.
# % InUseConnectionCount. Percentage of connections currently in use.
# MaxConnectionsInUseCount. Maximum number of connections currently in use so far.
# ConnectionCount. Number of connections.
# MaxSize. Maximum of connections.
# ConnectionCreatedCount. Number of connections created since last call.
# ConnectionDestroyedCount. Number of connections physically destroyed since last call.
# Pool Configuration. Textual description of datasource pool configuration.
• ThreadPool. Monitors thread pool information for each pool.
# currentThreadsBusy. Number of busy threads in the pool.

338
Monitors
# % currentThreadsBusy. Percentage of busy threads in the pool.
# currentThreadCount. Number of threads in the pool.
# maxThreads. Maximum number of threads in the pool.
# threadsConfiguration. Textual description of connection pool configuration.
• Transactions. Monitors transactions for the whole server.
# TransactionCount. Number of active transactions.
# CommitCount. Number of committed transactions since last call.
# RollbackCount. Number of transactions that have been rolled back since last call.
# % RollbackCount. Percentage of transactions that have been rolled back since last call.
• JMS.
# Queue. The following counters are presented for each JMS queue.
# InProcessMessageCount. Number of in process messages in the queue.
# ScheduledMessageCount. Number of scheduled messages in the queue.
# QueueDepth. Depth of the queue.
# SubscribersCount. Number of active subscribers for the queue since last call.
# ReceiversCount. Number of receivers waiting for a message since last call.
# Topic. A JMS Topic allows management of the message flow from publisher to subscribers. The
following counters are shown for each JMS topic.
# AllMessageCount. Number of all messages in the topic (DurableMessageCount +

NonDurableMessageCount).
# AllSubscriptionsCount. Number of all subscribers in the topic (DurableSubscriptionsCount +

NonDurableSubscriptionsCount).
# DurableMessageCount. Number of persistent messages in the topic. If the subscriber is not

connected to the topic, these messages will be delivered the next time the subscriber connects.
# NonDurableMessageCount. Number of non-persistent messages in the topic. If the subscriber

is not connected to the topic, these messages will be never delivered to the subscriber.
# DurableSubscriptionsCount. Number of subscribers for persistent messages in the topic.
# NonDurableSubscriptionsCount. Number of subscribers for non-persistent messages in the

topic.
• EJB. Monitors invocation counts for each EJB.
# CreateCount. Number of create invocations since last call.
# RemoveCount. Number of remove invocations since last call.
339
Monitors
• EJB3. Monitors invocation counts for each EJB compatible with EJB3.0. The counters available
depend of the current selected EJB kind.
# AvailableCount. Number of instances currently available.
# MaxSize. Maximum number of instances.
# CurrentSize. Number of instances allocated and ready to be used (often equals to CacheSize).
# CacheSize. Number of instances in the cache.
# TotalSize. Total Number of instances (CacheSize + PassivatedCount).
# PassivatedCount. Number of instances that have been passivated (beans that have been serialized
by the application server).
# MinPoolSize. Minimal size pool.
# MaxPoolSize. Maximum size pool.
# MaxMessages. Maximum number of messages managed.
• VM. Monitors the VM Heap.
# FreeMemory. Amount of memory available (in bytes).
# MaxMemory. Maximum amount of memory (in bytes) that can be used
# UsedMemory. Amount of memory currently used (in bytes).
# % UsedMemory. Percentage of memory currently used.
# Specification.
# Host. Textual description about operating system and server hardware.
# JVM. Textual description for the Java Runtime running JBoss server.
# Version.
# Server. Textual description for JBoss server components version.
340
Monitors
Tomcat 5.5/6.0 Monitor

Configuration
Before using Tomcat monitor, it is required to enable JMX monitoring on the Tomcat server.
The list of options and how to configure JMX Remote in Java 5 can be found on the Sun website: http://
java.sun.com/j2se/1.5.0/docs/guide/management/agent.html.
The following serves as a quick installation guide:
Add the following parameters to your Tomcat startup script:
On Linux:
set CATALINA_OPTS="-Dcom.sun.management.jmxremote -
Dcom.sun.management.jmxremote.port=9004 -
Dcom.sun.management.jmxremote.ssl=false -
Dcom.sun.management.jmxremote.authenticate=false"
On Windows:
set CATALINA_OPTS=-Dcom.sun.management.jmxremote -
Dcom.sun.management.jmxremote.port=9004 -
Dcom.sun.management.jmxremote.ssl=false -
Dcom.sun.management.jmxremote.authenticate=false
1. If you want to include authentication, change the above parameter to:
-Dcom.sun.management.jmxremote.authenticate=true
and add and configure the following parameters:
-Dcom.sun.management.jmxremote.password.file=../conf/
jmxremote.password -Dcom.sun.management.jmxremote.access.file=../conf/
jmxremote.access \
341
Monitors
2. Then, edit the access allow file $CATALINA_BASE/conf/jmxremote.access :
monitorRole readonly
controlRole readwrite
3. Next, edit the password file $CATALINA_BASE/conf/jmxremote.password :
monitorRole tomcat controlRole tomcat
Tip
The password file must be read-only and not be accessible to any other user! Remove access
rights to this file for all other users under Windows.
Connection settings
Defining a monitor to a Tomcat server requires the name or IP address of the machine to be monitored,
as well as the connection port (the default port is 9004). In addition to these settings, a valid user account
must be provided if authentication is enabled.
Creating a Tomcat monitor

monitored machine.
NeoLoad displays a list of the WARs (web application resources) deployed on the configured server. It
then automatically selects the most appropriate counters for each of the selected applications.
342
Monitors
Available counters
• Session. This section allows the user to monitor the sessions for each applications.
# sessionMaxAliveTime. Longest time an expired session had been alive.
# sessionAverageAliveTime. Average time an expired session had been alive.
# rejectedSessions. Number of sessions tomcat rejected since last call due to maxActive being
reached.
# % rejectedSessions. Percentage of tomcat sessions rejected since last call due to maxActive being
reached.
last call.
• RequestProcessor. Provides management information on the requests processed.
343
Monitors
# maxTime. Longest time a request processing take.
• DataSource. Data source connection pool information for each data source.
# numActive. Number of active connections.
# % numActive. Percentage of active connections.
# numIdle. Number of idle connections.
# maxActive. Maximum number of active connections so far.
# maxIdle. Maximum number of idle connections so far.
# poolConfiguration. Textual description of datasource pool configuration.
• ThreadPool. Monitors connection pool information for each pool.
# currentThreadsBusy. Number of busy threads in the pool.
# % currentThreadsBusy. Percentage of busy threads in the pool.
# currentThreadCount. Number of threads in the pool.
# maxThreads. Maximum number of threads in the pool.
# threadsConfiguration. Textual description of connection pool configuration.
• VM. JVM counters. Since Tomcat 5.5/6.0 is launched in a 1.5 VM, the following VM counters are
provided:
# Memory. The Java virtual machine has a heap that is the runtime data area from which memory
for all class instances and arrays are allocated. It is created at the Java virtual machine start-up. Heap
memory for objects is reclaimed by an automatic memory management system which is known as a
garbage collector. The heap may be of a fixed size or may be expanded and shrunk.
# Used. Represents the amount of memory currently used (in bytes).
# % Used. Represents the percentage amount of memory currently used.
# Committed. Represents the amount of memory (in bytes) that is guaranteed to be available for
use by the Java virtual machine. The amount of committed memory may change over time (increase
or decrease). The Java virtual machine may release memory to the system and committed could be
less than init. committed will always be greater than or equal to used.
# Max. Represents the maximum amount of memory (in bytes) that can be used for memory
management. Its value may be undefined. The maximum amount of memory may change over time
if defined. The amount of used and committed memory will always be less than or equal to max
if max is defined. A memory allocation may fail if it attempts to increase the used memory such
that used > committed even if used <= max would still be true (for example, when the system is
low on virtual memory).
344
Monitors
# Garbage Collector. Garbage collection is the process that the Java virtual machine uses to find
and reclaim unreachable objects to free up memory space. The Sun JVM defines garbage collection in
two modes: Minor 'copy' and major 'MarkSweepCompact', .A minor collection runs relatively quickly
and involves moving live data around the heap in the presence of running threads. A major collection
is a much more intrusive garbage collection that suspends all execution threads while it completes its
task. The following counters are available for both modes:
# CollectionCount. Returns the number of collections that have occurred since last call.
# CollectionTime. Returns the approximate accumulated collection elapsed time in milliseconds

since last call.
# Threads. Information on the thread system of the Java virtual machine.
# ThreadCount. Returns the current number of live threads including both daemon and non-
daemon threads.
# DaemonThreadCount. Returns the current number of live daemon threads.
# PeakThreadCount. Returns the peak live thread count since the Java virtual machine started
or peak was reset.
# Description. Textual description about the server.
# JVM. Textual description for the Java Runtime running Tomcat server.
# Host. Textual description about operating system and server hardware.
345
Monitors
Oracle Application Server 9.X-10.X Monitor

Configuration
To define the connection to an Oracle Application Server server using this monitor requires that the DMS
(Dynamic Monitoring System) library be activated. By default, the is activated on OC4J (Oracle Container
4 Java) servers version 10g.
The following procedure can be used to make sure the server metrics are accessible via the DMS library:
Procedure 7.11. Testing the DMS
1. Launch an Internet browser from the machine on which NeoLoad is installed.
2. Enter the following address: http://<server>:<port>/dms0/Spy?format=xml.

<server> is the server hostname. <port> is the server's port.
Example: http://oc4jserver.com:8888/dms0/Spy?format=xml
3. Check that the returned content is in XML format. The content should start with <?xml
version='1.0'?>.
In the event of an HTTP 404 (Not Found) error, repeat step 2 using this address: http://
<server>:<port>/dmsoc4j/Spy?format=xml.
For more details on monitoring Oracle Application Server servers via DMS, see the related
documentation in the Oracle Performance Guide [http://download-west.oracle.com/docs/cd/B10464_01/
core.904/b10379/toc.htm].
Supported versions
This monitor supports Oracle Application Server 9 and later.
Connection settings
Defining a connection to an Oracle Application Server server requires a server (defined in the Server
section of the Virtual Users)tab and a path. The server to be used can be created, or you can use a server
created during a recording.
Creating an Oracle Application Server 9.X-10.X monitor

monitored machine.
346
Monitors
applications.
Available counters
The counter advanced settings are available for all the HTTP counters.
The Oracle Application Server counters are automatically calculated based on all the available managed
objects. As the list of Oracle Application Server counters is dynamic, calculating the total number of
counters may take several seconds. For certain counters, a description allows access to its documentation.
Here are some of the most common sections.
• JMS. Counters in this category contain information on JDBC connection pools. For example, you
mat retrieve the number of expired messages for each pool.
347
Monitors
• JVM (Java Virtual Machine API). Counters in this category contain information on the Java Virtual
Machine memory usage, including the total available memory and the size of the memory available
for the JVM.
• oc4j. The sub-categories of this category are the EARs deployed on the server. For example, you may
retrieve the number of requests processed for each EAR.
Oracle Application Server 10.1.3 Monitor

Configuration
Before using an Oracle Application Server monitor, several of the Oracle Application Server server's jars
must be installed in NeoLoad's jmxlib/oas directory.
Copy the following files from the Oracle Application Server directory to <neoload>jmxlib/oas
directory:
• <oas>/lib/dms.jar
• <oas>/opmn/lib/optic.jar
• <oas>/j2ee/<your-instance>/oc4jclient.jar
• <oas>/j2ee/<your-instance>/lib\adminclient.jar
• <oas>/j2ee/<your-instance>/lib\ejb.jar
• <oas>/j2ee/<your-instance>/lib\oc4j-internal.jar
Warning
Several versions of the application server (development versions) does not contain these
files. These files are embedded on Companion CD of application server or available for
downloading at : http://www.oracle.com/technology/software/products/
ias/htdocs/utilsoft.html (select then Administrative Client Utility).
348
Monitors
Supported versions
This monitor allows NeoLoad to access Oracle Application Server 10g 10.1.3 and higher.
Connection settings
Defining a connection to an Oracle Application Server server requires the name or IP address of the
machine to be monitored, as well as the connection port (the default port is 6003). The application server
connection port is configured in the file: <Serveur>/opmn/conf/opmn.xml,
<notification-server> <port local="6100" remote="6200" request="6003" /> ... </notification-server>
A valid user account must be provided in addition to these settings (same as the one used for connecting
to the Oracle Application Server Management Console).
Note
If the Oracle Application Server server is being monitored from behind a firewall, the following
ports must be opened:
• 6003 (configurable in the opmn/conf/opmn.xml file, line: <notification-server>

<port local="6100" remote="6200" request="6003" />)
• 12401 (configurable in the opmn/conf/opmn.xml file, line: <port id="rmi"

range="12401-12500"/>)
Creating an Oracle Application Server 10.1.3 monitor

monitored machine.
applications.
349
Monitors
Available Counters
# UseTime. Use time of a connection.
# WaitTime. Waiting time for an available connection.
# CloseConnectionCount. Closed connection count.
# CreateConnectionCount. Created connection count.
# FreePoolSize. Number of available connections in the pool.
# PoolSize. Total number of connections (available and used).
# WaitingThreadCount. Number of threads waiting for an available connection.
# % UsedPoolSize. Percent of pooled connections used.
• ThreadPool. Monitors thread pool information for each pool.
# PoolSize. Number of threads in the pool.
# QueueSize. Number of tasks waiting for an available thread.
# % usedPoolSize. Percent of pooled threads used.
# ActiveCount. Total count of active transactions. A consistently high value can indicate a heavy
load on a server.
# CommitedCount. Total count of transactions which have committed.
# RolledbackCount. Total count of transactions that have rolled back.
350
Monitors
# RolledbackDueToTimedOutCount. Total count of transactions that have rolled back due to

timeout.
# RolledbackDueToAppCount. Total count of transactions that have rolled back due to the
application calling setRollbackOnly or rollback explicitly.
# RolledbackDueToResourceCount. Total count of transactions that have rolled back due to and
error in an enlisted resource.
# RolledbackDueToAdminCount. Total count of transactions that have rolled back due to

administrative action.
A high value here suggests that the system or application may not be automated enough; for example,
too much system administration in general or inadequate handling of transaction architecture, or a
particular issue has occurred which required extensive administration.
# RolledbackExceptionCount. Total count of RolledBackExceptions encountered.
# HeurisitcMixedExceptionCount. Total count of HeuristicMixedExceptions encountered.
# HeurisitcRollbackExceptionCount. Total count of HeurisitcRollbackExceptions encountered.
# SecurityExceptionCount. Total count of SecurityExceptions encountered.
# IllegalStateExceptionCount. Total count of IllegalStateExceptions encountered.
# SystemExceptionCount. Total count of SystemExceptions encountered.
# HeuristicCommitedCount. Total count of heuristically committed transactions.
# HeuristicRolledbackCount. Total count of heuristically rolled back transactions.
# HeuristicCount. Total count of all heuristically rolled back and committed transactions. See
comments for HeuristicCommittedCount and HeuristicRolledbackCount.
# PerformTransaction. Time from beginning to end of the transaction.
# AverageCommitTime. Average commit time of all transactions. This is the average of the
jtaresource_performTransaction values. This is a mean average however, so there may be spikes in
the system indicating other issues as well.
# SinglePhaseCommitCompletion. Time required for a one-phase commit completion.
# TwoPhaseCommitCompletion. Time required for a two-phase commit completion.
# TransactionSuspended. Time transaction has been suspended.
# RollbackCompletion. Time required for a rollback completion.
# % RolledbackCount. Percent of rolled back transactions.
• JMS.
# ActiveConnections. Number of active connections on the JMS server.
# ActiveHandlers. Number of active handlers on the JMS server.
351
Monitors
# MessageCommited Count. Number of committed messages.
# MessageRolledBack Count. Number of rolled back messages.
# MessageCount. Number of messages (committed and rolled back).
# MessageDequeued Count. Number of dequeued messages.
# MessageEnqueued Count. Number of enqueued messages.
# MessageDiscarded Count. Number of discarded messages.
# MessageExpired Count. Number of expired messages.
# MessagePagedIn Count. Number of paged in messages.
# MessagePagedOut Count. Number of paged out messages.
# MessageRecovered Count. Number of recovered messages.
# PendingMessage Count. Number of pending messages.
• WebModule. Monitors web modules on the server.
# ResolveServletTime. Total time spent to create/locate servlet instances (within the servlet
context). This includes the time for any required authentication.
# ResolveServletActive. Number of active servlet resolve requests.
# ProcessRequestTime. Total time spent servicing this application's web requests.
# ProcessRequestActive. Number of threads servicing web requests.
# SessionActivationTime. Total time for which sessions have been active.
# SessionActivationActive. Number of active sessions.
• JVM. Monitors the VMs on the server.
# UpTime. Total elapsed time since VM's start.
# HeapSize. VM's heap size in kilobytes.
# FreeHeapSize. Free VM's heap size in kilobytes.
# ActiveThreads. Current number of VM's active threads.
# Version. Version of the JVM used by the server.
# % UsedHeapSize. Percent of used VM's heap size.
• EJB. Monitors the activity for each EJB. EJB's are divided into three types:
StatefulSessionBean, StatelessSessionBean and MessageDrivenBean.

352
Monitors
# MethodReadyCount. Number of session bean methods whose state is Ready.
# PassiveCount. Number of instances that have been passivated (beans that have been serialized by
the application server).
You can monitor method calls for each EJB.
JOnAS Monitor
Supported versions
NeoLoad supports all Jonas server versions marked as certified Java Enterprise Edition (J2EE).
Connection settings
Defining a monitor to a Jonas server requires the name or IP address of the machine to be monitored, as
well as the connection port (the default port is 1099). The port is the Jonas server's RMI connection port.
In addition to these settings, a valid user account must be provided if authentication is enabled (same
account than the one used to connect to Jonas Administration Console). By default authentication is not
enabled.
Creating a JOnAS monitor

monitored machine.
353
Monitors
applications.
Available counters
All Jonas counters are documented here. Depending on the Jonas version, some counters may be
automatically hidden because they are not supported by this particular Jonas version.
• Servlet. This section allows the user to monitor each servlets by application.
# loadTime. Servlet load time.
# classLoadTime. Servlet class load time.
354
Monitors
# processingTime. Total execution time of the servlet's service method.
# requestCount. Number of requests processed by this wrapper since last call.
# errorCount. Error count since last call.

• Sessions. This section allows the user to monitor the sessions for each application:
# Tomcat.
# rejectedSessions. Number of sessions rejected since last call due to maxActive being reached.
# % rejectedSessions. Percentage of sessions rejected since last call due to maxActive being
reached.
last call.
# processingTime. Time spent doing housekeeping and expiration.

# duplicates. Number of duplicated session ids generated.
# Jetty.
# connections. Total number of connections.
# connectionsOpen. Number of opened connections.
# connectionsOpenMax. Maximum number of opened connections.
# connectionsDurationAve. Average duration of a connection.
# connectionsRequestsAve. Average number of requests of a connection.
# errors. Number of errors since last call.
# requests. Number of requests since last call.
# requestsActive. Number of active requests since last call.
# requestsDurationAve. Average duration of a request.
• JCA Resource. This section allows the user to monitor JCA server resources.
# connectionFailures. Number of connection failures.
# connectionLeaks. Number of connection leaks. A connection leak is an unused connection which

has not been released.
# currentBusy. Number of busy connections.
# currentOpened. Number of opened connections.
355
Monitors
# currentWaiters. Current number of connection waiters.
# rejectedFull. Number of open calls that were rejected because too many waiters
# rejectedOpen. Total number of open calls that were rejected.

# rejectedOther. Number of open calls that were rejected by an unknown reason.
# rejectedTimeout. Number of open calls that were rejected by timeout.
# waitingTime. Total waiting time (millisec) since datasource creation.
• JMS.
# Topic. A JMS Topic allows management of the message flow from publisher to subscribers. The
following counters are shown for each JMS topic.
# nbMsgsReceiveSinceCreation. Number of received messages since last call.
# nbMsgsSendToDMQSinceCreation. Number of queued messages since last call.
# nbMsgsDeliverSinceCreation. Number of delivered messages since last call.
# Queue. The following counters are presented for each JMS queue.
# PendingMessages. Number of pending messages.
# PendingRequests. Number of pending requests.
# nbMsgsReceiveSinceCreation. Number of received messages since last call.
# nbMsgsSendToDMQSinceCreation. Number of queued messages since last call.
# nbMsgsDeliverSinceCreation. Number of delivered messages since last call.
• Server Proxy. This section allows the user to monitor the state of each servers of the domain.
# ConnectionFailuresJCAConnection. Number of connection failures to a JCA resource.
# ConnectionLeaksJCAConnection. Number of connection leaks to a JCA resource. A connection

leak is an unused connection which has not been released.
# CurrentBusyJCAConnection. Number of busy JCA connection.
# CurrentOpenedJCAConnection. Number of opened JCA connection.
# ConnectionFailuresJDBCResource. Number of connection failures to a JDBC resource.
# ConnectionLeaksJDBCResource. Number of connection leaks to a JDBC resource. A connection

leak is an unused connection which has not been released.
# CurrentBusyJDBCResource. Number of busy JDBC connection.
# CurrentOpenedJDBCResource. Number of opened JDBC connection.
# CurrentNumberOfEJB. Number of EJB.
# CurrentNumberOfEntityBean. Number of EntityBean
356
Monitors
# CurrentNumberOfMDB. Number of MDB.
# CurrentNumberOfSBF. Number of SBF.
# CurrentNumberOfSBL. Number of SBL.
# AllThreadsCount. Number of threads.
# CurrentTotalMemory. Total size of the memory.
# CurrentUsedMemory. Current used memory size.
# CurrentWorkerPoolSize. Current worker pool size.
# connectionFailures. Number of connection failures to the data source.
# connectionLeaks. Number of connection leaks to the data source. A connection leak is an unused
connection which has not been released.
# currentBusy. Number of connections currently in use.
# busyMax. Maximum number of connections currently in use.
# jdbcMaxConnPool. Maximum number of connections to the data source.
# currentOpened. Number of opened connections to the data source.
# servedOpen. Number of accepted connections since last call.
# currentWaiters. Number of threads waiting for the data source.
# jdbcMaxWaiters. Maximum number of threads waiting for the data source.
# rejectedFull. Number of rejected connections.
# rejectedOpen. Number of rejected opened connections.
# rejectedOther. Number of rejected connections for an unknown reason.
# rejectedTimeout. Number of rejected connections due to a timeout.
# waitingTime. Current waiting time for the data source to be available.
# configuration. Textual description of datasource pool configuration.
# totalBegunTransactions. Number of begun transactions since last call.
# totalCommittedTransactions. Number of committed transactions since last call.
# totalCurrentTransactions. Number of active transactions.
# totalExpiredTransactions. Number of expired transactions since last call.
# totalRolledbackTransactions. Number of transactions that have been rolled back since last call.
357
Monitors
• EJB. Monitors invocation counts for each EJB.. Counters are separated in two categories:
Warning
Those counters are only available since 4.8.x version server.
# StatelessSessionBean.
# poolSize. Pool size.
# cacheSize. Number of instances in cache.
# maxCacheSize. Maximum number of instances in cache.
# StatefulSessionBean.
# EntityBean.
• Description. Informations concerning the applications server configuration.
# Server.
# Version. Server version.
# currentTotalMemory. Total memory that the server can use.
# currentUsedMemory. Current memory usage.
# % currentUsedMemory. Percentage of current memory usage.
# JVM.
# Version. JVM version.
# allThreadsCount. Threads count started by the JVM.
358
Monitors
GlassFish Monitor
Supported versions
NeoLoad supports all GlassFish server versions, but some counters may not be available for versions 2.0.x
and earlier.
Connection settings
Defining a monitor on a GlassFish server requires the name or IP address of the machine to be monitored,
as well as the connection port (the default port is 8686). The port is the GlassFish server's JMX connection
port.
account than the one used to connect to GlassFish Administration Console). The default account is
"admin" and the password "adminadmin".
To retrieve all the selected performance counters, NeoLoad requires the GlassFish server's monitoring
level to be set to "high". To display the server's monitoring levels, enter the following command from the
server's "bin" directory:
asadmin get server.monitoring-service.module-monitoring-levels.*
server.monitoring-service.module-monitoring-levels.connector-connection-pool = OFF
server.monitoring-service.module-monitoring-levels.connector-service = OFF
server.monitoring-service.module-monitoring-levels.ejb-container = OFF
server.monitoring-service.module-monitoring-levels.http-service = OFF
server.monitoring-service.module-monitoring-levels.jdbc-connection-pool = OFF
server.monitoring-service.module-monitoring-levels.jms-service = OFF
server.monitoring-service.module-monitoring-levels.jvm = OFF
server.monitoring-service.module-monitoring-levels.orb = OFF
server.monitoring-service.module-monitoring-levels.thread-pool = OFF
359
Monitors
server.monitoring-service.module-monitoring-levels.transaction-service = OFF
server.monitoring-service.module-monitoring-levels.web-container = OFF
To change monitoring level, enter the following commands from the server's "bin" directory:
asadmin set server.monitoring-service.module-monitoring-levels.connector-connection-pool=HIGH

asadmin set server.monitoring-service.module-monitoring-levels.connector-connection-pool=HIGH
asadmin set server.monitoring-service.module-monitoring-levels.connector-service=HIGH
asadmin set server.monitoring-service.module-monitoring-levels.ejb-container=HIGH
asadmin set server.monitoring-service.module-monitoring-levels.http-service=HIGH
asadmin set server.monitoring-service.module-monitoring-levels.jdbc-connection-pool=HIGH
asadmin set server.monitoring-service.module-monitoring-levels.jms-service=HIGH
asadmin set server.monitoring-service.module-monitoring-levels.jvm=HIGH
asadmin set server.monitoring-service.module-monitoring-levels.orb=HIGH
asadmin set server.monitoring-service.module-monitoring-levels.thread-pool=HIGH
asadmin set server.monitoring-service.module-monitoring-levels.transaction-service=HIGH
asadmin set server.monitoring-service.module-monitoring-levels.web-container=HIGH
To obtain the names of the monitoring modules, see the list of available counters.
Creating a GlassFish monitor

monitored machine.
NeoLoad displays a list of the WARs (Web application ARchive) deployed on the configured server. It
then automatically selects the most appropriate counters for each of the selected applications.
360
Monitors
Available counters
All GlassFish counters are documented here. Depending on the GlassFish monitoring level you have set,
some counters may be automatically hidden because they are not offered by the GlassFish server.
• Sessions. This section allows the user to monitor the sessions for each application.
# sessionCount. Number of sessions created by this manager since last call.
# sessionMaxAliveTimeSeconds. Longest time an expired session had been alive.
# sessionAverageAliveTimeSeconds. Average time an expired session had been alive.
# rejectedSessions. Number of sessions GlassFish rejected since last call due to maxActive being
reached.
# % rejectedSessions. Percentage of sessions GlassFish rejected since last call due to maxActive
being reached.
last call.
• RequestProcessor. Provides management information on the requests processed.
361
Monitors
# maxTime. Longest time taken to process a request.
• EJB. Statistics for the application server's EJB's.
Warning
For NeoLoad to monitor EJB's, the following monitoring module must be
activated: server.monitoring-service.module-monitoring-levels.ejb-
container
# EJB Pool. Pool usage statistics for the application server's EJB's.
# TotalBeansDestroyed_Count. Number of beans destroyed from associated pool.
# NumThreadsWaiting_Current. Number of threads waiting for free beans, giving an indication

of possible request congestion.
# TotalBeansCreated_Count. Number of beans created in associated pool.
# NumBeansInPool_Current. Provides statistical information on the number of EJB's in the

associated pool, giving an idea of how the pool is changing.
# EJB Method. Method call statistics for the application server's EJB's.
# TotalNumErrors_Count. Total number of errors that occurred during invocation or execution

of an operation.
# TotalNumSuccess_Count. Total number of successful invocations of the method.
# ExecutionTime_Count. Time in milliseconds spent during the last successful/unsuccessful

attempt to execute the operation.
# MethodStatistic_Count. Number of times an operation was called.
# MethodStatistic_MinTime. Minimum time spent during the invocation of an operation.
# MethodStatistic_MaxTime. Maximum time spent during the invocation of an operation.
# MethodStatistic_TotalTime. Total time spent during the invocation of an operation.
• JDBC Connection Pool. Connection pool information for each data source.
Warning
For NeoLoad to monitor JDBC connection pools, the following monitoring
module must be activated: server.monitoring-service.module-monitoring-
levels.jdbc-connection-pool
362
Monitors
# NumConnUsed_Current. Provides connection usage statistics. In addition to number of

connections being used currently, this also provides information about the maximum number of
connections that were used.
# NumConnReleased_Count. Count value reflecting the number of connections released back to

the pool.
# NumConnDestroyed_Count. Count value reflecting the number of connections that were

destroyed.
# NumConnFree_Current. Count value reflecting the number of connections in the connection

pool that are free.
# NumConnTimedOut_Count. Count value reflecting the number of connections in the connection

pool that timed out.
# NumConnCreated_Count. Count value reflecting the number of connections that were created
by the pool.
# NumConnAcquired_Count. Count value reflecting the number of connections acquired from the
pool.
# NumPotentialConnLeak_Count. Count value reflecting the number of potential connection

leaks.
# NumConnFailedValidation_Count. Count value reflecting the number of connections in the

connection pool that failed validation.
# WaitQueueLength_Count. Count value indicating the number of connection requests in the queue
waiting to be serviced.
# PoolConfiguration. Textual description of JDBC connection pool configuration.
• JMS. Statistics for the application server's message services.
Warning
For NeoLoad to monitor message services, the following monitoring module must be activated:
server.monitoring-service.module-monitoring-levels.jms-service
# Destination. Statistics for destinations configured on the application server.
# NumActiveConsumers. Current number of associated active message consumers.
# % NumActiveConsumers. Percentage of associated active message consumers.
# NumBackupConsumers. Current number of associated backup message consumers.
# % NumBackupConsumers. Percentage of associated backup message consumers.
# NumConsumers. Current number of associated message consumers. For queue destinations,

this attribute includes both active and backup consumers.
# NumProducers. Current number of associated message producers.
# MsgBytesIn. Cumulative size in bytes of messages received since broker started.
363
Monitors
# MsgBytesOut. Cumulative size in bytes of messages sent since broker started.
# NumWildcards. Current number of wildcard message producers and wildcard message

consumers associated with the destination. For topic destinations only.
# NumWildcardConsumers. Current number of wildcard message consumers associated with

the destination. For topic destinations only.
# NumWildcardProducers. Current number of wildcard message producers associated with the

destination. For topic destinations only.
# NumMsgs. Current number of messages stored in memory and persistent store. Does not include
messages held in transactions.
# NumMsgsRemote. Current number of messages stored in memory and persistent store that
were produced to a remote broker in a cluster. This number does not include messages included
in transactions.
# NumMsgsHeldInTransaction. Current number of messages being held in memory and

persistent store in uncommitted transactions.
# NumMsgsIn. Cumulative number of messages received since broker started.
# NumMsgsOut. Cumulative number of messages sent since broker started.
# NumMsgsPendingAcks. Current number of messages being held in memory and persistent

store pending acknowledgment.
# TotalMsgBytes. Current total size in bytes of messages stored in memory and persistent store.
Does not include messages held in transactions.
# TotalMsgBytesRemote. Current total size in bytes of messages stored in memory and persistent
store that were produced to a remote broker in a cluster. This value does not include messages
included in transactions.
# TotalMsgBytesHeldInTransaction. Current total size in bytes of messages being held in

memory and persistent store in uncommitted transactions.
# DiskReserved. Amount of disk space, in bytes, reserved for destination.
# DiskUsed. Amount of disk space, in bytes, currently in use by destination.
# DiskUtilizationRatio. Ratio of disk space currently in use to disk space reserved for destination.
# DestinationConfiguration. Textual description of JMS destination configuration.
# Connection Pool. Statistics for connection pools configured on the application server.
# numconnused-current. Count value reflecting the number of connections that are in use.
# numconnfree-current. Count value reflecting the number of connections in the connection pool
that are free.
# waitqueuelength-count. Count value indicating the number of connection requests in the queue
waiting to be serviced.
364
Monitors
# numconnreleased-count. Count value reflecting the number of connections released back to

the pool.
# numpotentialconnleak-count. Count value reflecting the number of potential connection leaks.
# numconntimedout-count. Count value reflecting the number of connections in the connection

pool that timed out.
# numconndestroyed-count. Count value reflecting the number of connections that were

destroyed.
# numconnacquired-count. Count value reflecting the number of connections acquired from the
pool.
# numconncreated-count. Count value reflecting the number of connections that were created
by the pool.
# numconnfailedvalidation-count. Count value reflecting the number of connections in the

connection pool that failed validation.
# PoolConfiguration. Textual description of JMS connection pool configuration.
• Transaction Service. Monitors transactions for the server as a whole.
Warning
For NeoLoad to monitor transaction services, the following monitoring
module must be activated: server.monitoring-service.module-monitoring-
levels.transaction-service
# ActiveCount_Count. Number of transactions that are currently active.
# RolledbackCount_Count. Number of transactions that have been rolled back.
# % RolledbackCount_Count. Percentage of transactions that have been rolled back.
# CommittedCount_Count. Number of transactions that have been committed.
• Thread Pools. Thread pool statistics.
Warning
For NeoLoad to monitor thread pools, the following monitoring module must be activated:
server.monitoring-service.module-monitoring-levels.thread-pool
# CurrentNumberOfThreads_Current. Current number of total threads in the thread pool.
# NumberOfAvailableThreads_Count. Current number of available threads in the thread pool.
# NumberOfBusyThreads_Count. Number of busy threads in the thread pool.
# % NumberOfBusyThreads_Count. Percentage of busy threads in the thread pool.
# AverageWorkCompletionTime_Current. Average elapsed time taken to complete a work item

by the thread pool.
365
Monitors
# TotalWorkItemsAdded_Count. Total number of Work items added to the Queue.
# AverageTimeInQueue_Current. Average time a work item waits in the work queue.
# WorkItemsInQueue_Current. Number of Work items in the Queue to be processed.
• JVM. Java Virtual Machine counters.
# Memory. The Java Virtual Machine has a heap that is the runtime data area from which memory
for all class instances and arrays are allocated. It is created at the Java Virtual Machine start-up. Heap
memory for objects is reclaimed by an automatic memory management system which is known as a
garbage collector. The heap may be of a fixed size or may be expanded and shrunk.
# Used. Amount of memory currently used (in bytes).
# % Used. Percentage of memory currently used.
# Committed. Amount of memory (in bytes) that is guaranteed to be available for use by the Java
Virtual Machine. The amount of committed memory may change over time (increase or decrease).
The Java Virtual Machine may release memory to the system and committed could be less than
init. committed will always be greater than or equal to used.
# Max. Maximum amount of memory (in bytes) that can be used for memory management. Its
value may be undefined. The maximum amount of memory may change over time if defined. The
amount of used and committed memory will always be less than or equal to max if max is defined. A
memory allocation may fail if it attempts to increase the used memory such that used > committed
even if used <= max would still be true (for example, when the system is low on virtual memory).
# Garbage Collector. Garbage collection is the process that the Java Virtual Machine uses to find
and reclaim unreachable objects to free up memory space. The Sun JVM defines garbage collection in
two modes: minor 'copy' and major 'MarkSweepCompact'. A minor collection runs relatively quickly
and involves moving live data around the heap in the presence of running threads. A major collection
is a much more intrusive garbage collection that suspends all execution threads while it completes its
task. The following monitor are available for both modes:
# CollectionCount. Number of collections that have occurred since last call.
# CollectionTime. Approximate accumulated collection elapsed time in milliseconds since last

call.
# Threads. Information on the Java Virtual Machine thread system.
# ThreadCount. Current number of live threads including both daemon and non-daemon threads.
# DaemonThreadCount. Current number of live daemon threads.
# PeakThreadCount. Peak live thread count since the Java Virtual Machine started or peak was
reset.
• Description. Information on the application server configuration.
# Host. Textual description of operating system and server hardware.
# JVM. Textual description of the Java Runtime running GlassFish server.
366
Monitors
SAP NetWeaver Monitor 7.0

Supported versions
NeoLoad supports SAP NetWeaver Web Application Server versions 7.0.x and later.
Configuration
Before the SAP NetWeaver monitor can be used, several NetWeaver server jars need to be installed.
Copy the following files from the NetWeaver installation directory to the <neoload>/jmxlib/
netweaver70 directory:
• <netweaver>/<instance>/<java server>/j2ee/admin/lib/admin.jar
• <netweaver>/<instance>/<java server>/j2ee/admin/lib/com_sap_pj_jmx.jar
• <netweaver>/<instance>/<java server>/j2ee/JSPM/lib/exception.jar
• <netweaver>/<instance>/<java server>/j2ee/JSPM/lib/logging.jar
Connection settings
Defining a monitor on a SAP NetWeaver server requires the name or IP address of the machine to be
monitored, as well as the connection port. The port is the SAP NetWeaver's server access point for the
P4 protocol. You can retrieve the port number using the SAP Management Console at: "Management
Console / SAP Systems / <SAP System name> / <SAP Instance name> / Access
Points". The access point is named P4.
account as the one used to connect to the SAP NetWeaver Administration Console).
367
Monitors
Creating a SAP NetWeaver monitor

monitored machine.
NeoLoad displays a list of the applications deployed on the configured server. It then automatically selects
the most appropriate counters for each of the selected applications.
Available counters
All SAP NetWeaver counters are documented here.
The first-level nodes in the monitors tree show the domain (only for 7.1.x versions), the instance name
and the cluster's node number respectively.
368
Monitors
• Connections. Counters on all the connections of the SAP NetWeaver server.
# ConnectionsUsageRate. Connections used, of all types, as a percentage of maximum number of

connections.
# FreeConnectionsInPool. Number of free connections in the pool.
# HTTPConnectionsCount. Number of HTTP connections to the server.
# IIOPConnectionsCount. Number of IIOP connections to the server.
# JMSConnectionsCount. Number of JMS connections to the server.
# MaxPossibleConnections. Maximum number of simultaneous connections to the server.
# OtherConnectionsCount. Number of connections to the server other than HTTP, IIOP, JMS, P4
or Telnet.
# P4ConnectionsCount. Number of P4 connections to the server.
# TELNETConnectionsCount. Number of Telnet connections to the server.
# TotalConnectionsCount. Total number of connections to the server, of all types.
• Sessions. This section allows the user to monitor the server sessions.
# HTTP. Server HTTP session monitors.
# TotalResponseTime. Current response time for all responses.
# AllResponsesCount. Number of all responses.
# AllRequestsCount. Number of all requests.
# CurrentHttpSessions. Number of currently valid HTTP sessions.
# TimedOutHttpSessions. Number of sessions that have timed out.
# HttpSessionsInvalidatedByApplication. Number of HTTP sessions invalidated by the

application.
# CurrentSecuritySessions. Number of currently valid security sessions created for HTTP

clients.
# TimedOutSecuritySessions. Number of security sessions that have timed out.
# SecuritySessionsInvalidatedByApplication. Number of security sessions that have been

invalidated by the application.
# Security. Server security sessions.
# InvalidSessionsCount. Number of invalid security sessions.
# LoggedOffSessionsCount. Number of all security sessions for which the user has successfully
logged off.
# TimedOutSessionsCount. Number of all security sessions that have timed out.

369
Monitors
# LoggedUsersCount. Number of logged-in users.
# TotalSessionsCount. Number of all security sessions.
# UserStoreAccessCount. Number of store accesses made by a user.
# ActiveSessionsCount. Number of all active security sessions. Such sessions can be created for
every protocol that has access to the server: HTTP, P4, IIOP, Telnet, RFC.
# UnsuccessfullLogonAttempsCount. Number of all unsuccessful logon attempts.
# Session Manager. Session counters for the server's resources as a whole.
# Active Web Sessions Count. Number of active Web sessions.
# Logged-In Users Count. Number of logged-in users.
# Opened EJB Sessions Count. Number of opened EJB sessions.
# Opened Security Sessions Count. Number of opened security sessions.
# Opened Web Sessions Count. Number of opened Web sessions.
• Transactions. Counters for the server's transactions as a whole.
# ActiveTransactionsCount. Number of active transactions.
# TimeoutedTransactionsCount. Number of transactions that have timed out
# SuspendedTransactionsCount. Number of suspended transactions
# CommittedTransactionsCount. Number of transactions that have been committed
# OpenTransactionsCount. Number of running transactions.
# RolledBackTransactionsCount. Number of transactions that have been rolled back
# TransactionSuccessRate. Ratio between committed transactions count and total transactions

count.
• EJB. Counters for EJBs deployed on the NetWeaver server. The EJBs are categorized by type
(Entity Bean, Message Driven Bean, Session Stateful Bean or Session
Stateless Bean) and sorted by EAR.
# ActivationsNumber. Number of times a bean instance has been activated.
# CreationsNumber. Number of times a bean has been created.
# CurrentPoolSize. Number of bean instances provided by this pool, which are currently used by
the application or are stored in the pool.
# InitialPoolSize. Initial number of bean instances created in the pool.
# LoadsNumber. Number of times a bean instance has been loaded.
# MaxPoolSize. Maximum number of bean instances the pool can hold.
370
Monitors
# PassivationsNumber. Number of times a bean instance has been passivated.
# PoolCurrentlyUsedObject. Number of bean instances provided by the pool currently used.
# PoolIncrementSize. Number by which the bean pool will be incremented.
# RemovalsNumber. Number of times a bean has been removed.
# StoresNumber. Number of times a bean has been saved.
• HTTP Channel. Counters for the HTTP access point.
# ThreadsInProcessRate. Ratio between the number of active threads count and the total size of
the pool.
# ActiveThreadsCount. Number of threads from the thread pool that are executing a runnable task.
# ResponseFromCacheCount. Number of responses served from the cache.
# ThreadPoolSize. Current number of threads created by the thread pool.
• JDBC DataSource. Provides data source connection pool information for each data source.
# Free managed connections number. Number of free ManagedConnections for the specified data
source.
# Maximum connections number. Maximum number of ManagedConnections simultaneously

opened from a specific data source.
# Used managed connections number. Number of used ManagedConnections.
# Waiting for connections number. Number of clients waiting for pooled ManagedConnection.
• Portal. Information on SAP portal activity.
# Portal Runtime Cache. Counters for portal cache access.
# Fail Count. Number of failed cache accesses.
# Hit Count. Number of requests served by the cache.
# Load Count. Number of responses loaded by the cache.
# Miss Count. Number of responses that failed to be handled by the cache.
# Read Count. Number of responses read by the cache.
# Write Count. Number of responses written to the cache.
# Portal Runtime.
# Loaded Applications. Number of applications loaded by the portal.
371
Monitors
# Loaded Component Contexts. Number of component contexts loaded by the portal.
# Loaded Component. Number of components loaded by the portal.
# Loaded Services. Number of services loaded by the portal.
• Request Performance. Counters for JARM (Java Application Response Time Measurement)
performance requests.
# Average CPU time. Average CPU time for JARM requests.
# Average outbound data. Average outbound data for JARM requests.
# Average response time. Average response time of JARM requests.
# Component calls. Number of component calls by all JARM requests.
# Number of requests. Number of JARM requests.
# Requests per second. Number of JARM requests per second.
• Memory. Counters for SAP NetWeaver server memory.
# AvailableMemory. Current value of the available memory.
# AllocatedMemory. Current value of the allocated memory.
# AllocatedMemoryRate. Ratio of allocated memory to the available memory.
# UsedMemory. Current value of the memory used.
# UsedMemoryRate. Ratio of the used memory to the available memory.
# UsageRate. Ratio between the used memory and the total memory of the process.
• Thread Pool. Thread pool counters. These counters are divided between application threads and
system thread.
# CurrentThreadCount. Current number of threads created by the thread pool.
# InitialThreadCount. Initial size of the thread pool.
# ActiveThreadsCount. Number of threads from the thread pool that are executing an executable
task pool. It shows how many threads from the thread pool are currently processing custom tasks.
This monitor does not indicate a problem.
The number of used threads depends on the number of configured threads and the value of
the maximum pool size, and whether this size is reached or whether the pool can still be
resized. Even if the pool is resized to maximum and the value of ActiveThreadsCount and
CurrentThreadCount are the same, this does not indicate a problem. The purpose of the threads
pool is to restrict the request load to a point where the engine can still have enough resources to
process these parallel requests fast enough.
# MinThreadCount. Minimum size of the thread pool.
# MaxThreadCount. Maximum size of the thread pool.
372
Monitors
# WaitingTasksCount. The number of tasks waiting to be executed by a free thread.
WaitingTasksCount shows the number of custom tasks that are waiting to be processed, which
means that at the moment there are no free threads in the thread pool although the thread pool is
resized to its maximum size. In this case, the tasks that are waiting to be processed start accumulating
in a queue. Even when the load is high, the threads process a custom task for a certain time and take
the next task from the queue. When the size of the queue grows, it mean that either the request rate
is growing and the server node cannot handle such a high load, or there is a blocking situation in the
server and the threads are not released from the tasks they are currently executing.
The monitor is important to detect how effectively the threading system executes the tasks. With
100% usage rate, caller threads are blocked until some of the tasks that are currently executing finish.
This could be a symptom of a deadlock or a bottleneck.
# WaitingTasksUsageRate. The ratio of the current size of the waiting tasks queue to the maximum
configured size. WaitingTasksUsageRate shows the percentage of the waiting tasks queue that
is currently used.
The ratio shows how effectively the threading system executes the tasks. When the usage is 100%, the
caller threads are blocked until any of the currently executing tasks finishes. This can be a symptom
for a deadlock or bottleneck.
# WaitingTasksQueueOverflow. The number of threads waiting to deposit a task in the waiting

tasks queue when the queue is full.
WaitingTasksQueueOverflow shows the number of blocked threads waiting to submit a task

in the queue of waiting tasks. In this situation there are no free threads to process requests and also
the size of the queue of waiting tasks is full, so the threads that need to submit a new task in this queue
are blocked until a free slot is available. This monitor shows a problem.
This counter is unlikely to change its value from 0 because it means that the capacity of the requests
queue is exhausted. This is a severe performance problem. This can also be a symptom for a locking
situation (blocking back-end calls or Java level deadlock).
# MaxWaitingTasksQueueSize. Capacity of the waiting tasks queue, where tasks waiting for
execution are stored.
# ThreadPoolCapacityRate. The ratio of the current thread pool size to the maximum pool size in
percentages. ThreadPoolCapacityRate shows the percentage of the maximum pool size that
the thread pool has currently reached. This is an informative monitor that does not indicate a problem.
If the percentage is high, it means that soon the ability to resize the pool will be exhausted. If the
ThreadPoolUsageRate is also high, a requests queue will be formed.
# ThreadPoolUsageRate. Ratio of active threads count to maximum pool size. The outcome is
presented as a percentage.
# UsageRate. Ratio between active threads count to maximum pool size in percent.
# Configuration. Configuration of the Threads pool.
• Description. Information concerning the SAP NetWeaver server.
# Version. Version of the SAP NetWeaver server.
373
Monitors
SAP NetWeaver Monitor 7.1

Supported versions
NeoLoad supports SAP NetWeaver Web Application Server versions 7.1.x and later.
Configuration
Before the SAP NetWeaver monitor can be used, several NetWeaver server jars need to be installed.
Copy the following files from the NetWeaver installation directory to the <neoload>/jmxlib/
netweaver71 directory:
• <netweaver>/<instance>/<java server>/j2ee/JSPM/deploy/lib/sap.com~tc~bl~pj_jmx~api.jar
• <netweaver>/<instance>/<java server>/j2ee/JSPM/deploy/lib/sap.com~tc~exception~impl.jar
• <netweaver>/<instance>/<java server>/j2ee/j2eeclient/sap.com~tc~je~clientlib~impl.jar
• <netweaver>/<instance>/<java server>/j2ee/j2eeclient/sap.com~tc~je~leanClient.jar
• <netweaver>/<instance>/<java server>/j2ee/JSPM/deploy/lib/sap.com~tc~logging~java~impl.jar
Connection settings
Defining a monitor on a SAP NetWeaver server requires the name or IP address of the machine to be
monitored, as well as the connection port. The port is the SAP NetWeaver's server access point for the
P4 protocol. You can retrieve the port number using the SAP Management Console at: "Management
Console / SAP Systems / <SAP System name> / <SAP Instance name> / Access
Points". The access point is named P4.
account as the one used to connect to the SAP NetWeaver Administration Console).
374
Monitors
Creating a SAP NetWeaver monitor

monitored machine.
NeoLoad displays a list of the applications deployed on the configured server. It then automatically selects
the most appropriate counters for each of the selected applications.
Available counters
All SAP NetWeaver counters are documented here.
The first-level nodes in the monitors tree show the domain (only for 7.1.x versions), the instance name
and the cluster's node number respectively.
375
Monitors
• Sessions. This section allows the user to monitor the server sessions.
# HTTP. Server HTTP session monitors.
# CurrentHttpSessions. Number of currently valid HTTP sessions.
# TimedOutHttpSessions. Number of sessions that have timed out.
# HttpSessionsInvalidatedByApplication. Number of HTTP sessions invalidated by the

application.
# CurrentSecuritySessions. Number of currently valid security sessions created for HTTP

clients.
# TimedOutSecuritySessions. Number of security sessions that have timed out.
# SecuritySessionsInvalidatedByApplication. Number of security sessions that have been

invalidated by the application.
# Security. Server security sessions.
# InvalidSessionsCount. Number of invalid security sessions.
# LoggedOffSessionsCount. Number of all security sessions for which the user has successfully
logged off.
# TimedOutSessionsCount. Number of all security sessions that have timed out.
# LoggedUsersCount. Number of logged-in users.
# TotalSessionsCount. Number of all security sessions.
# UserStoreAccessCount. Number of store accesses made by a user.
# ActiveSessionsCount. Number of all active security sessions. Such sessions can be created for
every protocol that has access to the server: HTTP, P4, IIOP, Telnet, RFC.
# UnsuccessfullLogonAttempsCount. Number of all unsuccessful logon attempts.
# Session Manager. Session counters for the server's resources as a whole.
# Active Web Sessions Count. Number of active Web sessions.
# Logged-In Users Count. Number of logged-in users.
# Opened EJB Sessions Count. Number of opened EJB sessions.
# Opened Security Sessions Count. Number of opened security sessions.
# Opened Web Sessions Count. Number of opened Web sessions.
• Transactions. Counters for the server's transactions

376 as a whole.
Monitors
# ActiveTransactionsCount. Number of active transactions.
# TimeoutedTransactionsCount. Number of transactions that have timed out
# SuspendedTransactionsCount. Number of suspended transactions
# CommittedTransactionsCount. Number of transactions that have been committed
# OpenTransactionsCount. Number of running transactions.
# RolledBackTransactionsCount. Number of transactions that have been rolled back
# TransactionSuccessRate. Ratio between committed transactions count and total transactions

count.
• EJB. Counters for EJBs deployed on the NetWeaver server. The EJBs are categorized by type
(Entity Bean, Message Driven Bean, Session Stateful Bean or Session
Stateless Bean) and sorted by EAR.
# ActivationsNumber. Number of times a bean instance has been activated.
# CreationsNumber. Number of times a bean has been created.
# CurrentPoolSize. Number of bean instances provided by this pool, which are currently used by
the application or are stored in the pool.
# InitialPoolSize. Initial number of bean instances created in the pool.
# LoadsNumber. Number of times a bean instance has been loaded.
# MaxPoolSize. Maximum number of bean instances the pool can hold.
# PassivationsNumber. Number of times a bean instance has been passivated.
# PoolCurrentlyUsedObject. Number of bean instances provided by the pool currently used.
# PoolIncrementSize. Number by which the bean pool will be incremented.
# RemovalsNumber. Number of times a bean has been removed.
# StoresNumber. Number of times a bean has been saved.
• HTTP Channel. Counters for the HTTP access point.
# ThreadsInProcessRate. Ratio between the number of active threads count and the total size of
the pool.
# ActiveThreadsCount. Number of threads from the thread pool that are executing a runnable task.
# ResponseFromCacheCount. Number of responses served from the cache.
# ThreadPoolSize. Current number of threads created by the thread pool.
377
Monitors
• JMS. JMS session counters.
# SessionContainer.
# Connections Count. Number of connections.
# Consumers Count. Number of consumers.
# Producers Count. Number of producers.
• Applications. Overall connectivity to back-end resource systems.
# FreeManagedConnectionCount. Number of free ManagedConnections for the specified

ResourceAdapter.
# ManagedConnectionUsageRate. Ratio between used connections and connection pool maximum

size for a specific connector.
# MaxConnectionNumber. Maximum number of ManagedConnections simultaneously opened

from a specified ResourceAdapter.
# TimeoutedConnectionCount. Count of connection timeouted events.
# UsedManagedConnectionCount. Number of used ManagedConnections.
# WaitingConnectionCount. Number of clients waiting for pooled ManagedConnection.
• JDBC DataSource. Provides data source connection pool information for each data source.
# FreeManagedConnectionCount. Number of free ManagedConnections for the specified data

source.
# ManagedConnectionUsageRate. Ratio between the used connections and connection pool

maximum size for a specific data source.
# MaxConnectionCount. Maximum number of ManagedConnections simultaneously opened from

a specific data source.
# TimeoutedConnectionCount. Count of the connection timeouted events.
# UsedManagedConnectionCount. Number of used ManagedConnections.
# WaitingForConnectionCount. Number of clients waiting for pooled ManagedConnection.
• Table Buffers. Describes the monitored data for Open SQL table buffers.
# BufferSize. The maximum size of the table buffer.
# FreeSize. The remaining free space in the buffer in bytes.
# % FreeSize. Percent of remaining free space if the buffer.
# Number of displacements. The total number of displacements in the buffer since buffer instance
startup.
• Portal. Information on SAP portal activity.
378
Monitors
# Portal Runtime Cache. Counters for portal cache access.
# Fail Count. Number of failed cache accesses.
# Hit Count. Number of requests served by the cache.
# Load Count. Number of responses loaded by the cache.
# Miss Count. Number of responses that failed to be handled by the cache.
# Read Count. Number of responses read by the cache.
# Write Count. Number of responses written to the cache.
# Portal Runtime.
# Loaded Applications. Number of applications loaded by the portal.
# Loaded Component Contexts. Number of component contexts loaded by the portal.
# Loaded Component. Number of components loaded by the portal.
# Loaded Services. Number of services loaded by the portal.
• Request Performance. Counters for JARM (Java Application Response Time Measurement)
performance requests.
# Average CPU time. Average CPU time for JARM requests.
# Average outbound data. Average outbound data for JARM requests.
# Average response time. Average response time of JARM requests.
# Component calls. Number of component calls by all JARM requests.
# Number of requests. Number of JARM requests.
# Requests per second. Number of JARM requests per second.
• Memory. Counters for SAP NetWeaver server memory.
# AvailableMemory. Current value of the available memory.
# AllocatedMemory. Current value of the allocated memory.
# AllocatedMemoryRate. Ratio of allocated memory to the available memory.
# UsedMemory. Current value of the memory used.
# UsedMemoryRate. Ratio of the used memory to the available memory.
# UsageRate. Ratio between the used memory and the total memory of the process.
• Thread Pool. Thread pool counters. These counters are divided between application threads and
system thread.
# CurrentThreadCount. Current number of threads created by the thread pool.

379
Monitors
# InitialThreadCount. Initial size of the thread pool.
# ActiveThreadsCount. Number of threads from the thread pool that are executing an executable
task pool. It shows how many threads from the thread pool are currently processing custom tasks.
This monitor does not indicate a problem.
The number of used threads depends on the number of configured threads and the value of
the maximum pool size, and whether this size is reached or whether the pool can still be
resized. Even if the pool is resized to maximum and the value of ActiveThreadsCount and
CurrentThreadCount are the same, this does not indicate a problem. The purpose of the threads
pool is to restrict the request load to a point where the engine can still have enough resources to
process these parallel requests fast enough.
# MinThreadCount. Minimum size of the thread pool.
# MaxThreadCount. Maximum size of the thread pool.
# WaitingTasksCount. The number of tasks waiting to be executed by a free thread.
WaitingTasksCount shows the number of custom tasks that are waiting to be processed, which
means that at the moment there are no free threads in the thread pool although the thread pool is
resized to its maximum size. In this case, the tasks that are waiting to be processed start accumulating
in a queue. Even when the load is high, the threads process a custom task for a certain time and take
the next task from the queue. When the size of the queue grows, it mean that either the request rate
is growing and the server node cannot handle such a high load, or there is a blocking situation in the
server and the threads are not released from the tasks they are currently executing.
The monitor is important to detect how effectively the threading system executes the tasks. With
100% usage rate, caller threads are blocked until some of the tasks that are currently executing finish.
This could be a symptom of a deadlock or a bottleneck.
# WaitingTasksUsageRate. The ratio of the current size of the waiting tasks queue to the maximum
configured size. WaitingTasksUsageRate shows the percentage of the waiting tasks queue that
is currently used.
The ratio shows how effectively the threading system executes the tasks. When the usage is 100%, the
caller threads are blocked until any of the currently executing tasks finishes. This can be a symptom
for a deadlock or bottleneck.
# WaitingTasksQueueOverflow. The number of threads waiting to deposit a task in the waiting

tasks queue when the queue is full.
WaitingTasksQueueOverflow shows the number of blocked threads waiting to submit a task

in the queue of waiting tasks. In this situation there are no free threads to process requests and also
the size of the queue of waiting tasks is full, so the threads that need to submit a new task in this queue
are blocked until a free slot is available. This monitor shows a problem.
This counter is unlikely to change its value from 0 because it means that the capacity of the requests
queue is exhausted. This is a severe performance problem. This can also be a symptom for a locking
situation (blocking back-end calls or Java level deadlock).
# MaxWaitingTasksQueueSize. Capacity of the waiting tasks queue, where tasks waiting for
execution are stored.
380
Monitors
# ThreadPoolCapacityRate. The ratio of the current thread pool size to the maximum pool size in
percentages. ThreadPoolCapacityRate shows the percentage of the maximum pool size that
the thread pool has currently reached. This is an informative monitor that does not indicate a problem.
If the percentage is high, it means that soon the ability to resize the pool will be exhausted. If the
ThreadPoolUsageRate is also high, a requests queue will be formed.
# ThreadPoolUsageRate. Ratio of active threads count to maximum pool size. The outcome is
presented as a percentage.
# UsageRate. Ratio between active threads count to maximum pool size in percent.
# Configuration. Configuration of the Threads pool.
• JVM. Information concerning the Java Virtual Machine.
# Version. Version of the Java Virtual Machine.
• Description. Information concerning the SAP NetWeaver server.
# Version. Version of the SAP NetWeaver server.
LiveCycle Data Services Monitor

Supported versions
NeoLoad supports LiveCycle Data Services (LCDS) versions 2.6 and later .
Connection settings
Defining a monitor on a LiveCycle Data Services server requires the name or IP address of the machine
to be monitored, as well as the connection port. The port is the JMX port that is configured to the Java
Virtual Machine.
381
Monitors
If the JMX connection has not been configured, add the following parameters to the application server's
start-up script:
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=9004
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
To enable authentication, or for more information on configuring the JMX connection, please refer to the
relevant Sun documentation: http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html.
In addition to these settings, a valid user account must be provided if authentication is enabled (see
com.sun.management.jmxremote.authenticate property).
Creating a LCDS monitor

monitored machine.
NeoLoad displays a list of the applications deployed on the configured server.
382
Monitors
When selecting an application, NeoLoad displays a list of endpoints configured for this application. It then
automatically selects the most appropriate counters for each of the selected endpoints.
Available counters
All LCDS counters are documented here. The first tree level shows the available message brokers.
• EndPoints. Counters for the defined endpoints on the server. Not all counters are available for all the
end points (e.g.: streaming counters are only available for streaming endpoints).
# BytesDeserialized. Total amount of bytes received by the endpoints since last call.
# BytesSerialized. Total amount of bytes sent by the endpoints since last call.
# ServiceMessageCount. Count of messages decoded by this endpoint and routed to the broker.
383
Monitors
# ServiceMessageFrequency. Number of service message invocations per minute.
# PushCount. Count of push invocations.
# PushFrequency. Number of push invocations per minute.
# StreamingClientsCount. Current number of clients connected to the streaming endpoint.
# MaxStreamingClients. Maximum number of clients connected to the streaming endpoint.
• Services. Statistics for the LCDS application's various services.
# Data Services.
# ServiceMessageCount. Number of service message invocations.
# ServiceMessageFrequency. Number of service message invocations per minute.
# ServiceCommandCount. Number of service command invocations.
# ServiceCommandFrequency. Number of service command invocations per minute.
# ServiceMessageFromAdapterCount. Number of messages from an adapter that the managed

service has processed.
# ServiceMessageFromAdapterFrequency. Number of service message from adapter

invocations per minute.
# Remoting Services.
# InvocationSuccessCount. Current number of method invocations succeeded.
# InvocationFaultCount. Current number of method invocations failed.
# % InvocationFaultCount. Percentage of method invocations failed.
# AverageInvocationProcessingTimeMillis. Average processing time (in milliseconds) of all the

method invocations.
# HTTP Proxy Services.
# InvokeSOAPCount. Current number of method invocation using SOAP protocol.
# InvokeSOAPFrequency. Frequency of method invocation using SOAP protocol.
# InvokeHTTPCount. Current number of method invocation using HTTP protocol.
# InvokeHTTPFrequency. Frequency of method invocation using HTTP protocol.
• Throughput. Data throughput processed by the different types of endpoints.
# AMFThroughput. Total number of bytes passing through all AMF endpoints.
# HTTPThroughput. Total number of bytes passing through all HTTP endpoints.
# EnterpriseThroughput. Total number of bytes passing through all Enterprise endpoints.
384
Monitors
# StreamingAMFThroughput. Total number of bytes passing through all streaming AMF

endpoints.
# StreamingHTTPThroughput. Total number of bytes passing through all streaming HTTP

endpoints.
• Sequence Manager.
# AssociationCount. Number of objects associated by the manager.
# FillCount. Number of objects created by the manager.
# ClientCount. Number of clients connected to the manager.
# SMOSequenceCount. Number of SMO's (Service Message Objects) processed by the manager.
# ItemCount. Number of objects currently being handled by the manager.
• Throttle Manager. Statistics for messages whose throughput has been throttled.
# ClientIncomingMessageThrottleCount. Number of incoming client messages that have been

throttled.
# ClientIncomingMessageThrottleFrequency. Number of incoming client messages that have

been throttled per minute.
# ClientOutgoingMessageThrottleCount. Number of outgoing client messages that have been

throttled.
# ClientOutgoingMessageThrottleFrequency. Number of outgoing client messages that have been

throttled per minute.
# DestinationIncomingMessageThrottleCount. Number of incoming destination messages that

have been throttled.
# DestinationIncomingMessageThrottleFrequency. Number of incoming destination messages

that have been throttled per minute.
# DestinationOutgoingMessageThrottleCount. Number of outgoing destination messages that

have been throttled.
# DestinationOutgoingMessageThrottleFrequency. Number of outgoing destination messages

that have been throttled per minute.
• FlexClientManager. Counters for Flex clients.
# FlexClientCount. Current number of Flex clients connected to the server.
385
Monitors
386
Chapter 8. Runtime
Test Settings
A scenario contains all the settings required to run a load test:
• the test duration,

• which populations to test,
• the load policy, i.e. the number and variety of virtual users to be generated,
• which load generators should run the test and,
• the runtime policy.
Scenarios
NeoLoad can generate several scenarios for each project, making it easy to switch from one test
configuration to another: a short test with a ramp-up load, a very long test with load peaks, a test with
a realistic load etc..
The simulated load in a scenario is determined by a duration and a number of virtual users. Each virtual
user plays the pages contained in its profile, then stops. NeoLoad immediately runs another virtual user
with the same profile to maintain the predetermined load.
387
Runtime
Duration Policy
Sets the population duration : unlimited, set time, or iterations. One iteration represents one virtual user
played once, through to its end. When iterations are selected, a population's runtime must be defined by
entering the number of iterations in the "Duration Policy" panel.
In any event, a test can be stopped at any point by clicking on the "Stop" button.
Load Policy
Specifies the number and variety of virtual users to be generated. Select one or more populations to test
and the load policy for each population:
In standard mode:
• Constant - Generates a fixed number of virtual users.
• Ramp-up - Generates a number of virtual users that increases throughout the test. Useful for checking
the server's behavior under an increasing load.
• Peak - Generates a fixed number of virtual users with periodic phases of high load. Useful for checking
whether the server recovers its normal behavior after a load peak.
• Custom - Allows you to set the load to be applied by plotting the virtual user variation curve. You may
import the curve using a CSV file. The file must be in the format Time (seconds) <separator>
Number of users.
In iteration mode:
In this mode, the population is played for the number of iterations specified in the panel. Each simulated
user is run for a predetermined number of iterations without any break between iterations. Towards the
end of the test, some users will have finished their iterations and some others will still be active, which is
why the load decreases until all the users are finished.
For ramp-up or peak load, adding users for a new phase takes place once all existing users have finished
their iterations. Before each new phase therefore, and depending on the virtual user definition, the load
may drop to 0.
• Constant - Defines the number of play iterations for the virtual users.
• Ramp-up - The "Number of iterations" field allows you to set the test duration, since the test ends
once each virtual user launched for a first iteration completes the number of iterations entered in the
"Number of iterations (for each initial user)" field. Subsequent users launched at each increment do not
affect the test duration.
Example: a ramp-up load of 10 users, incremented by 2 users every 5 iterations. Running the test with
the number of iterations set at 20 will give the following load:
# 10 users for 5 iterations
# and finally 16 users for 5 iterations. (The test ends once the first 10 users have completed 20 iterations.)
• Peak - The "Number of iterations" field allows you to set the test duration, since the test ends once each
virtual user launched for the first peak stage completes the number of iterations entered in the "Number
of iterations (for each initial user)" field. Subsequent users launched for each peak do not affect the
test duration.
388
Runtime
Example: a minimum peak load of 10 users for 5 iterations and a maximum peak load of 20 users for 3
iterations. Running the test with the number of iterations set at 20 will give the following load:
# and finally 10 users for 4 iterations.(The test ends once the first 10 users have completed 20 iterations.)
• Custom - The number of virtual users to be launched and the number of iterations are set by plotting
the load curve. You may import the curve using a CSV file. The file must have the following format :
iteration count <séparateur> Number of users.
Load Generator Hosts

The load generator is the program that simulates the application users. Each NeoLoad controller features
a load generator. Load generators may be installed as separate programs on other machines.
The Load Generator Hosts list shows the load generators available for use. Each load generator running
on the local network is automatically detected by the controller on start up. Click "Discover" to auto-
discover the load generators currently running (the discovery make take a few seconds). Load generators
may be declared manually by entering the list of host names or IP addresses.
Load generators that are running are indicated by a green light; those that are halted by a red light; and those
that require an update by an orange light (See the section called “Automatically updating load generators”).
Select the load generators to be used for each population. The controller distributes the virtual users among
the selected, running load generators.
Advanced host configuration

Network
This panel lists all the network interfaces detected for the load generator. For those hosts acting as network
routers for several networks, select the network card to be used by the load generator. All the host's IP
addresses are listed on the selected interfaces. By default, a single IP address is selected and all the virtual
users generated by that load generator use that same address.
389
Runtime
Defining several IP addresses allows the user to test applications that use a load balancer based on IP
addresses. In this case, a random IP address is assigned to each virtual user. The IP addresses must be
available, i.e. not used by other machines within the network. Check with a system administrator to make
sure these addresses may be used.
Configure IP spoofing
To define IP addresses in the list, define additional IP addresses in the load generator's operating system
settings.
These parameters will modify the load generator's network settings. Please check with a system
administrator before changing the host's settings. In some documentation, multiple IP address settings are
referred to as virtual IP settings.
• Windows.
1. In the Start menu, click Control Panel.
2. In Network Connections, right-click on Local Area Connection and select

Properties
3. Select Internet Protocol (TCP/IP) in the list, then click on the Properties button.
4. Multiple IP address configuration is not available in DHCP mode. If DHCP mode is set (i.e.
"Obtain an IP address automatically" is selected), this setting must be changed to
the static IP mode (i.e. "Use the following IP address").
390
Runtime
5. Click on the Advanced button to display the list of defined IP addresses. Click on the Add
button.
6. Enter the new IP address and subnet mask in the appropriate boxes. Then click on the Add button.
7. The new IP address should appear in the list.
8. Repeat steps 5 through 7 to define each IP address.
• Linux. Multiple IP address configuration is not available in DHCP mode. Change the settings to use
static IP addresses. Use the ifconfig command to add a new IP address.
For example, the command line for adding 2 new IP addresses (say, 192.168.1.10 and 192.168.1.11)
to the eth0 network interface would be:
ifconfig eth0:0 192.168.1.10

ifconfig eth0:1 192.168.1.11
Load balancing
The virtual users used in the test are spread among all the available load generators. All the load generators
generate the same number of virtual users by default.
Increasing the load factor proportionally increases the number of virtual users created by each load
generator. For example, where NeoLoad needs to creates 5 more virtual users and load generator A has a
load factor of "3" and Load generator B a load factor of "2", A will create 3 virtual users and B will create
2. The more powerful machines may be configured to create a greater number of virtual users.
391
Runtime
Automatically updating load generators

A NeoLoad controller can automatically update obsolete load generators (orange indicator in the list). This
is particularly useful after a controller update.
Procedure 8.1. Updating a Load Generator

1. In the "Scenarios" tab, click on the "Modify..." button in "Load Generator Hosts"
section.
2. Click on the load generator's Edit button.
3. Click on the "Version" tab.
4. Click on the "Update" button (twin arrows icon). If the update is unavailable or unnecessary, the
button is grayed-out.
When the test is launched, NeoLoad checks the versions of the load generators being used and prompts
the user to update those that are obsolete. Once the load generators have been updated, the test continues
as normal.
A controller cannot update a load generator handled by a different controller. In this case, perform a manual
update using the standard installer.
If the load generator's agent has been started with an account that does not have privileges required to
update the program, then the load generator cannot be updated automatically. In this case, perform a manual
update using the standard installer.
392
Runtime
Important
If the update fails, or if the load generator fails to function properly after an automatic update,
perform a manual update using the standard installer.
Note
This function is only available for load generators having the same major and minor version
numbers as the controller. For example, the controller version 3.1.2 can update the load generator
3.1.0 but cannot update the version 3.0.9. When the automatic udate is not supported, the load
generators must be updated manually using the standard installer.
Population Advanced Settings

Runtime policy
In this section, you can define the following:
• Start policy - Defines how the population is started:
# "Immediate": the population is started at the beginning of the test.
# "Delayed": the populations starts after a preset delay.
393
Runtime
# "Sequential": the population is started once the selected population has finished.
How virtual users start may also be defined: simultaneously or with a preset delay. This policy is used
each time new virtual users are created, either at each load increase for a ramp-up load policy or at each
load peak for a peak load policy.
• Stop policy - Defines how the population is stopped:
# "Immediate": the users are stopped at the end of the time set for the population; they do not finish
their actions.
# "Delayed": set a timeout for virtual users to end their actions before they are stopped.
# "Unspecified": the virtual users are given time to finish their actions.
Scenario Advanced Settings

General information
The following settings can be edited for each scenario:
• Scenario properties - name and description of the scenario.
• Advanced Runtime:
# Virtual users : enable or disable the real-time display of virtual users.
# Monitoring settings : enable a monitoring period before and/or after the test. This allows you
to check the stressed server's behavior prior to running the test and the load test's impact upon it.
394
Runtime
• Debug mode: This mode logs the runs (requests and responses) of all the virtual users. See the
documentation on starting a test in debug mode.
There are two logging levels:
# Only virtual users containing errors.
# All virtual users.
Warning
Launching a scenario in debug mode can severely hamper performance, especially when too
many virtual users are started on a single load generator.
To carry out a large-scale test, we recommend you use several load generators with lighter
loads.
Details of the virtual users' runs are available in the test results in the "Debug" tab. See the
documentation on debug mode for more details.
Rendezvous policies
For detailed information on configuring rendezvous policies, see the documentation on configuring a
scenario's rendezvous.
Scheduling a test
NeoLoad allows you to schedule a test at a specified time.
395
Runtime
Procedure 8.2. Scheduling a test
1. Select the scenario to be run.
2. Click on the "Advanced..." button.
3. Select the "Schedule a test" tab.
4. Check the "Activate scheduling for this scenario" check box.
5. Select a date and time.
6. Enter a repeat rule (optional).
7. Enter a test description (optional).
8. Click "OK".
Note
NeoLoad must be running at specified time to be able to run the tests.
URL exclusion filter

Requests whose URL corresponds to one of the regular expressions in the exclusion filter are excluded
from the scenario and will not be played back during the load test. Likewise, the resulting empty pages
and containers will be deleted.
396
Runtime
Runtime supervision
The Runtime section displays real-time information while the test is running.
397
Runtime
Starting the Test

NeoLoad provides two test modes, normal and debug.
In normal mode, the test starts with all the system's resources used to generate the virtual users. Click on
the "Start" button to start a test in normal mode.
Debug mode allows you to validate the various virtual user profiles defined in the scenario. To validate a
test scenario in debug mode, use the following procedure:
1. Set the level of information NeoLoad should retrieve in the scenario's advanced settings.
2. Click on "Debug" to start the test in debug mode.
3. At the end of the test, the "Debug" tab in the "Results" section allows you to validate the virtual
user runtimes.
Warning
Launching a scenario in debug mode can severely hamper performance, especially when too many
virtual users are started on a single load generator.
To carry out a large-scale test, we recommend you use several load generators with lighter loads.
When you click on either of the buttons, a new window opens in which you may add a description for
the test to be launched. This description will be inserted in the test results and will serve to identify the
purpose of the test.
398
Runtime
This window also features a check box that gives you the option of updating the cache. This check box
is enabled where appropriate, that is to say only if a virtual user has been configured with the cache
management set to "Returning user" mode. If this box is checked at the start of the test, a virtual
user is launched in order to retrieve the cache information.
The test then starts and its progress can be followed in real time.
Stopping the Test

A running test may be stopped by clicking on the "Stop" button in the toolbar. The test is halted in 6 steps:
• Each load generator stops running its virtual users.

• Post monitoring: NeoLoad collects the performance counters for the duration defined.
• Collection of runtime information in debug mode for the virtual users concerned.
• Shutting down of the load generators.
• Calculation of the test statistics: this step may take several minutes, depending on the test duration. The
progress bar shows the progress of the calculations. This step may be halted manually by clicking the
"Stop" button again. Any statistics that could not be calculated due to this interruption will have a
value of -1. All other statistics will be correct.
• Generation of the results summary: the controller reads the statistics and generates the summary.
Once these steps have been completed, the Results screen is displayed.
Runtime Overview
The "Runtime overview" tab displays the following statistics:
Name Description
Scenario name Name of the scenario currently running
Start time Scenario start date
Elapsed time Time elapsed since test started
399
Runtime
Name Description
Total hits Total number of hits since test started
Total throughput Total number of megabytes received from server
Total errors Total number of errors since test started
Total alerts Total number of alerts since test started
Total users launched Total number of virtual users launched since test
started, including those currently running.
Average response time (requests) Average response time for HTTP requests since
test started
Average response time (pages) Average response time for web pages since test
started
Average hits/sec. Average hits/sec. since test started
Average throughput Average throughput since test started
Current response time (requests) Average request response time for HTTP requests
over the last second
Current response time (pages) Average request response time for web pages over
the last second
Current hits/sec. Average hits/sec. for HTTP requests over the last
second
Current throughput Average throughput over the last second
Current users count Number of virtual users currently running
Graphs
The main statistics are plotted in real time: number of virtual users currently running, error rate (errors/
sec.), number of alerts, hits/sec. and average request response time.
Load generators
Monitors the load generators' activity:
• Host - Machine running the load generator.
• Virtual Users - Number of virtual users currently being run by that load generator.
• Hit Rate - Average hit rate generated by that load generator.
• Errors - Current error rate (number of errors per second).
• CPU Load - CPU load for the machine hosting the load generator.
• Memory Used - Memory used, expressed as a percentage of the memory allocated to the load generator
program (the program's default memory allocation is 384Mb).
• Throughput - Throughput in Megabits per second for the network interface used on the load generator.
If the CPU Load or Memory Used figure regularly exceeds 90%, this indicates that the load generator is
overloaded. Run the test with fewer virtual users or a longer think time, or use additional load generators.
400
Runtime
Real-Time Graphs
Statistics and the monitors set on the servers can be plotted on graphs during the test runtime. When the
test is first run, NeoLoad creates default graphs. These can be modified during the test, or new graphs
can be created. When subsequent tests are run, NeoLoad restores the settings of the graphs used in the
previous test.
The legend panel displays the legend for the selected graph.
Note
Depending on the monitor value sampling interval, there may be a delay before the curves are
displayed on the graph (30 seconds using the default parameters).
The statistics can be accessed in the "Repository" tab and monitors in the "Monitors" tab.
The available statistics are:
• Minimum time - Minimum response time over the entire test.

• Average time - Average response time over the entire test.
• Maximum time - Maximum response time over the entire test.
• Hit rate - Number of hits.
• Minimum TTFB - Minimum time to first byte.
• Average TTFB - Average time to first byte.
• Maximum TTFB - Maximum time to first byte.
• Errors - Number of hits flagged as errors.
Monitors for general statistics are available for plotting by default: number of virtual users, number of
pages per second and their response times, average test throughput, number of alerts etc. Statistics for CPU
and memory usage and throughput, in percentage, are also available for each load generator.
401
Runtime
Filtering by load generator, population or virtual user
Filtering by a specific virtual user displays only that virtual user's web pages and actions (containers, loops
etc..).
Likewise, filtering by a specific population displays only that population's virtual users.
Likewise, filtering by a specific load generator displays only that load generator's populations and virtual
users. In that case, the statistics displayed are the one get by the selected load generator.
Note
The load generator filter is disabled by default. It can be enabled in the project's preferences,
section "Runtime parameters". It will be taken in account for the next test. See the section
called “Statistics”.
Working with graphs

Graphs can be used in the same way as for the Runtime and Results views. See the section called
“Working with Graphs”.
Graph features
The graphs' features are the same as those for the Runtime and Results views. See the section called
“Graph Features”.
Restoring default graphs

Use the Restore button in the toolbar to delete all the current graphs and restore the default graphs.
Plotting interval
The graph curves are plotted using a plotting interval (time interval between two points on a same curve)
which is separate from the monitoring interval.
For example, with the default plotting interval of 15 seconds and a monitoring interval of 5 seconds,
NeoLoad will use the average of the 3 recorded monitor values to produce the point on the curve.
A long plotting interval produces a more readable curve, whereas a short plotting interval produces a more
accurate curve.
Procedure 8.3. Changing the plotting interval
1. Go to the "Edit / Preferences" menu item.
2. Select the "Graphs" section.
3. Modify the settings in the "Runtime Graphs" section.
402
Runtime
Alerts
The icon indicates a performance counter for which one or more alert thresholds have been set.
Current and past alerts are shown by an extra notification against the performance counter's icon: for
a warning alert, for a critical alert.
Alerts are also displayed on graphs as yellow and red zones. The alert thresholds are only shown for the
graph curve selected in the legend bar.
To hide or show the alerts and thresholds:
• Right-click, then select "Show alert zones" or "Show thresholds".
You may display a tooltip for the alerts and thresholds:
• Hover the mouse pointer over the alert zone or threshold.
Real-Time Errors
Error details may be obtained while the test is running. Click on the "Refresh" button to display the
latest error occurrences.
403
Runtime
General error information

Select an error to obtain the following information:
• Time - Time between test start and occurrence of error.
• Code - Error code: the HTTP error code as defined by the HTTP protocol or the NeoLoad error code.
• Duration - Duration of the failed request.
• Size - Size of the server response content in bytes.
• Page - Link to the definition of the page containing the request with the error.
• Load Generator - Name of the load generator that played the request containing the error.
• Population - Population within which the request containing the error originated.
• Virtual User - Virtual user within which the request containing the error originated.
• Request - Link to the definition of the request containing the error.
Selected error details

Request
Displays details of the HTTP request sent to the server. Check your form parameter values if need be.
Server response
Displays the server response. If the server could not be contacted, this contains an error message generated
by NeoLoad.
404
Runtime
Assertions
Displays the assertion results (validations) for the response. Empty if the assertion is validated.
Previous request
Displays details of the previous request (determined by the referrer) to help find the root cause of the
current error. Indeed, an anomaly or error on a page may cause the following page to fail.
Real-Time Alerts
Alert details may be obtained while the test is running. Click on the "Refresh" button to display the
latest alert occurrences.
Alert Table
• Time. Alert start and end time, relative to the test start time.
• Severity. Alert severity level.
• Name. Alert name. The name comprises the corresponding performance counter's name plus a text
description of the alert threshold.
Alert details
Select an alert to obtain the following details:
• Monitored Machine. Name of the monitored machine that triggered the alert.
• Monitor. Name of the monitor that triggered the alert.
• Duration. Alert duration.
• Description. Alert description.
405
Runtime
• Delay trigger. Delay trigger for the alert's threshold.
Alert graphs
When an alert is selected in the table, the graph displays all the alerts relating to the same performance
counter: a red zone for critical alerts and a yellow zone for warning alerts. The zone corresponding
to the selected alert is shown in a slightly darker color.
The alert threshold values are represented by a horizontal dotted line.
Tip
Click on an alert zone to select the corresponding entry in the table.
Graph Options
Check the following boxes to display the corresponding elements:
• User Load. Displays the user load.
• Critical Alerts. Displays the thresholds and zones indicating critical-level alerts.
• Warning Alerts. Displays the thresholds and zones indicating warning-level alerts.
Viewing Virtual Users in Real Time

During the test, the virtual users running may be viewed in real time.
Virtual user information

The following information is available for each virtual user currently running:
• Date - Date of instance's start in relation to start of the test.
• Load Generator - Name of the load generator running the instance.
• User Type - The user type for the instance.
406
Runtime
• Instance - The instance number for the virtual user.
• Current Action - Name of the container the instance is currently running. If the virtual user does not
contain any containers, the virtual user's name is displayed.
The virtual users displayed may be filtered by:
• Number: by default, only the last hundred users currently running are displayed.
• Population : "All" is selected by default.
Virtual user run monitoring

A particular virtual user's run can be monitored using the validation window.
Procedure 8.4. Monitoring a virtual user's run

1. Click the "Monitor virtual user" button, or use the pop-up menu, or double-click on the
desired virtual user.
2. The virtual user monitoring window appears. The real-time monitoring will start at the next page
played by that virtual user. Therefore, you may have to wait until the first monitoring information
displays.
Note
Only one virtual user may be monitored at a time.
Virtual user monitoring may take a little time to display as the virtual user may be waiting out a
think time on an action, a delay, container pacing, or it may be waiting at a rendezvous.
Warning
The HTML rendering of pages run by the virtual user may be incomplete in some cases. This
is because certain application resources (e.g. images, CSS, JavaScript) may have been retrieved
from the previous pages before the viewing window was opened, making them unavailable for
the HTML rendering.
407
Chapter 9. Results
General Information
Selecting a Test
Use the Results drop-down list to select which test results to view within the current project. This choice
will be reflected in all subsequent result panels.
Deleting a Test
There are two ways to delete a test result:
• Use the Results Manager, accessed from the "Edit / Results Manager" menu item.
• Right-click on the Results drop-down list, then select the Delete option.
Filtering by Load Generator, Population or Virtual User
Filtering by a specific virtual user displays only that virtual user's web pages and actions (containers, loops
etc..).
Likewise, filtering by a specific population displays only that population's virtual users.
Likewise again, filtering by a specific load generator displays only that load generator's populations and
virtual users. In this case, the statistics displayed are the ones pertaining to the selected load generator.
Note
The load generator filter is disabled by default. It can be enabled in the project preferences'
"Runtime parameters" section. The change will take effect for the next test. See the section
called “Statistics”.
Virtual User, Container, Web Page and HTTP Request

Statistics
An HTTP request is a physical request made to the server. NeoLoad measures statistics for these, such
as response time, throughput etc..
A web page contains one or more HTTP requests.
A container contains one or more web pages and actions (containers, loops etc..).
408
Results
Where web pages or containers are concerned:
• The response time is the combination of the response times for the requests contained in the page or
container.
• The size is the sum of the sizes of all the requests contained in the page or container.
• A page or container is flagged as containing an error if one of its sub-requests contains an error.
Push Message Statistics

A Push message is a specific type of message sent via the Push channel during a test. See the section
called “Push Messages”.
Each time a Push message is executed, it results in a hit on that message. Several messages may be executed
from a same server response via the Push channel.
The response time is taken as the time delay between the moment the server decides to update the client
and the moment the client receives the update. In fact, when using a Push framework, the request response
time (time between sending a request and receiving its response) is virtually meaningless.
NeoLoad calculates the response time using a timestamp embedded in the server response. Depending
on the framework being used, the timestamp extraction needs to be configured manually. See the section
called “Push Messages”.
Important
For the response times for Push message to be coherent, the load generators' and application
server's system clocks need to be synchronized.
Where the server's timestamp cannot be extracted, or the calculated response time is negative (load
injectors and server have not been synchronized), NeoLoad shows a response time of 0. If all the statistics
for message response times show <0.01, make sure the machines are synchronized and check the regular
expression used to extract the timestamp in the Push request's configuration.
The Results Manager

All the test results are automatically saved after each test run. The Results Manager, accessed via the
"Edit / Results Manager" menu item, allows you to manage the results in the current project.
409
Results
The name and description of the selected test may be edited.
Select
Click "Select" to display the results of the selected test in the "Results" section of NeoLoad.
Compare
Click "Compare" to compare two tests in the "Results" section of NeoLoad.
A dialog box allows you to select the results to compare and to label them with a short label.
The label length cannot exceed 5 characters. The default labels are 'A' and 'B'.
Tip
Before clicking the Compare button, select two tests in the list (click then ctrl-click) to pre-fill
the comparison dialog box.
See the Comparing Two Test Results chapter for more details.
Filtering
Click the "Filter" button to filter a test result according to various criteria. See the chapter on Filtering
a Test Result for more information.
Test folder
Click the "Test folder..." button to open the directory containing the test results.
Generating a Report
Select the appropriate test results then click on "Generate report" to launch the Generate a Report
Wizard. This wizard allows you to generate either a simple report or a results comparison report.
Please refer to the Generating a Report chapter for further details.
Deleting a Test
Click on "Delete" to permanently delete a test result. Deleting superfluous test results is recommended
to free up disk space.
Warning
Deleting a test result deletes the files stored on the hard disk. This operation is irreversible.
410
Results
Test Summary
The test summary contains all the main statistics for the test.
The button on the top right-hand side of the tab allows you to generate a report for the selected test.
Selecting a Summary
To display a test result summary, select the test in the "Results" drop-down menu.
Content
Test summary
This tab displays basic details of the test: project and scenario name, test duration, load policy etc..
Statistics summary
Global statistics:
• Total pages - Total number of pages played.
• Total Hits - Total number of hits (requests) played.
411
Results
• Total throughput - Sum of the sizes of the responses to all the requests played. (does not include
upstream).
• Total users launched - Once a virtual user has finished its run, a new instance of the user is launched to
maintain the desired load. "Total users launched" indicates the total number of user instances
launched.
• Total hit errors - Total number of hits (requests) with errors.
• Total action errors - Total number of logical actions(e.g. JavaScript actions) with errors
• Total duration alerts - Total duration of alerts as a percentage of total test duration.
• Average pages/s - Average number of pages played per second.
• Average hits/s - Average number of hits (requests) played per second.
• Average request response time - Average response time for requests.
• Average page response time - Average response time for pages.
• Average throughput - Average throughput for server responses (downstream).
Hot spots
Focuses on significant results. The times are expressed in seconds.
Top 5 errors
The five pages having produced the most errors.
Top 5 alerts
The five longest alerts filtered by alert importance (critical alerts first, followed by warning alerts).
The duration is the duration of the different occurrences of an alert as a percentage of the total test duration.
First critical alerts

The first critical alerts occurring during the test's run.
Top 5 average response times

The five pages having produced the longest average response times.
Top 5 maximum response times

The five pages having produced the longest maximum response times
Top SQL requests

This section is available only if the appropriate performance indicators were used in the test, for example,
any indicator in the "Top SQL Statements" category for the Oracle monitor (see the section called
“Oracle DB monitor”).
Displays the results for indicators relating to SQL requests.
412
Results
Errors
Summary of errors by error type.
Alerts
This section displays the details of alerts triggered at the monitor level. The section only lists monitors that
have at least one performance counter with at least one alert threshold set.
For each monitor type: number of performance counters that triggered at least one critical alert, number
of performance counters that triggered at least one warning alert and number of counters with at least one
alert threshold set.
An icon is shown to indicate the state of each type of monitor with counters that have alert thresholds set:
• The icon indicates that the counters triggered at least one critical alert.
• The icon indicates that the counters triggered at least one warning alert but no critical alerts.
• The icon indicates that the counters triggered no critical or warning alerts.
General statistics
This section displays aggregated statistics for the virtual users, containers, pages and requests. See the
documentation on Virtual user, container, page and request results for more details on the results displayed.
Virtual user, container page and request results

The following statistics are displayed for each virtual user, container, page and HTTP request:
• Minimum response time

• Average response time
• Maximum response time
• Total hits
• Total errors
• Median
• Average 90%
• Standard deviation
Monitor results
Monitors group together performance counters and indicators. The performance counters and indicators
are grouped by monitored machine and by monitor (Tomcat, MySQL...).
The following statistics are displayed for each performance counter:
• Minimum response time

• Average response time
• Maximum response time
• Median
• Average 90%
• Standard deviation
413
Results
The indicator value (a character string) is displayed for each indicator.
Alert results
The alerts are grouped by monitored machine and by monitor (Tomcat, MySQL...).
The following statistics are displayed for each alert:
• Alert's severity level: critical or warning.

• Alert name
• Number of occurrences: number of times the alert threshold was exceeded during the test's run.
• Date of the first occurrence
• Alert duration in percentage of the total test running time
• Alert description
An icon is displayed to indicate the level of each alert:
• The icon indicates a critical alert.

• The icon indicates a warning alert.
Scenario
This section shows a summary of the test scenario's configuration, with the following information:
• Results summary
• Populations and their virtual user profiles' configuration
• Virtual user profiles and their configuration
• Rendezvous policies
Main graphs
This section includes a collection of predefined graphs:
• Average response time (pages)
• Average response time (requests)
• Hits/s
• Errors
• Throughput
• Page response time spread
• Top 10 first alerts
Graphs
Graphs allow you to see how the statistics evolve over the test's duration.
414
Results
Important
Please refer to the section called “General Information” for details on various topics affecting
this subject, such as filtering by virtual user.
Graph templates, available under the "Templates" tab, give you an immediate view of the application's
behavior during the load test. You may also define custom graph templates.
Note
The graphs in the "Results" section are saved in the current project and are restored when the
project is opened.
Working with Graphs

Selecting a graph
You can select a graph with your mouse
• A single click selects the graph.

• A double click maximizes the graph.
You may also jump to adjacent graphs using the arrow keys.
Plotting a statistic
1. Select the element to be plotted in the tree: web page, container or HTTP request. Use "All pages"
for an average of all pages (for one virtual user or for all virtual users) or "All requests" for an
average of all requests (for one virtual user or for all virtual users).
If the selected node is a child of the "Shared Containers" node, the plotted statistics represent
the aggregated statistics for all the virtual users that contain that element.
Note
For more details on shared elements, see, the section called “Shared Containers”.
415
Results
2. Select the statistic to plot: average time, maximum time, minimum time, hit rate, errors, throughput
(Kb/s)...
3. Select a location: "Create a new graph" (optional for drag-and-drop).
4. Use the ">" button or drag and drop the item or statistic onto the graph panel on the right.
5. Enter a title for the graph
Plotting a monitor
1. Click on the Monitors tab.
2. Select the monitor to plot in the tree.
3. Select a location: "Create a new graph" (optional for drag-and-drop).
4. Use the ">" button or drag and drop the item or statistic onto the graph pane on the right.
5. Enter a title for the graph
Deleting a graph
1. Select the graph to be deleted.
2. To delete the graph:
• Press the "Del" key

• Right-click and select "Delete graph"
• Click on the "X" button in the button toolbar.
Important
When a graph is deleted, it is replaced by a blank graph space. This blank graph can be deleted
if it is not the last remaining graph.
Deleting a graph curve

1. Select the graph to be modified
2. To delete the curve:
• Select the element in the caption bar and press the "Del" key.
• Select the element in the caption bar, right-click and select "Delete".
• Select the element in the caption bar and click the "<" button in the button toolbar.
• Right-click on the graph and select "Delete a curve".
Important
Deleting the last remaining curve in a graph deletes the graph.
Moving a graph
The layout of the graphs can be changed. To move a graph, drag and drop the graph to be moved to the
new position (existing graph or "Create a new graph" position).
416
Results
To select the graph, either click on the edge of the graph, or press the Shift key and click in the center
of the graph.
Maximizing/minimizing a graph
You may adjust the size of a graph to occupy all the available space, or minimize it.
To maximize or minimize a graph:
• Right-click, then select "Maximize" or "Minimize".

• Click on the "Maximize" or "Minimize" button in the button toolbar.
Graph Features
Zoom
Click and hold on the mouse button to select the rectangular area to zoom in on. The zoom takes effect
when the mouse button is released.
Press and hold the "Ctrl" key to obtain a zoom area that automatically takes in the entire vertical space.
Click on the graph to return to normal view.
Pop-up menu
Right-click on the graph for the following options:
• Save the graph as a PNG image file: "Save as image ..."

• Copy image to clipboard
• Print the graph
• Delete a graph curve
Caption bar
• View - Displays or hides the curve. This does not change the other curves or the scale factors.
417
Results
• Color - Curve color. Can be edited: double-click to display the color picker.
• Scale - Scale factor. All the curve values are multiplied by this factor before being plotted.
• Test - Name of the test associated with the curve.
• Name - Name of the element being plotted (web page, HTTP request, monitor...)
• Statistic - Statistic name. Empty if N/A. (See Filtering).
• Value - Current value pointed by the mouse cursor.
• Unit - Statistic unit. Empty if N/A.
• Virtual User - Virtual user name. Empty if N/A. (See Filtering).
• Population - Population name. Empty if N/A. (See Filtering).
• LG - Load generator name. Empty if N/A. (See Filtering).
Alerts
The icon indicates a performance counter for which one or more alert thresholds have been set.
Alerts are shown by an extra notification against the performance counter's icon: for a warning alert,
for a critical alert.
Alerts are also displayed on graphs as yellow and red zones. The alert thresholds are only shown for the
graph curve selected in the legend bar.
To hide or show the alerts and thresholds:
• Right-click, then select "Show alert zones" or "Show thresholds".
You may display a tooltip for alerts and thresholds:
• Hover the mouse pointer over the alert zone or threshold.
Features Specific to the Results Section

Exporting data
The selected graph's data may be exported using the Export button.
418
Results
The Export Wizard provides the following options:
• Export data in CSV format

• Export the image in PNG format
• Copy the image to the clipboard (for pasting into any document: mail, MS Word,...)
Note
Not all test data may be exported at one time.
Options
The Graph Options panel, accessed from the pop-up menu, allows you to modify the following items:
• Graph title,
• Graph description,
• Horizontal axis.
419
Results
Graphs may be plotted using different data for the horizontal axis:
• Time data (by default)

• User load data: the statistics are presented according to the number of virtual users running, the existing
curves being converted using the new horizontal axis. This plotted curve provides an easy way to study a
statistic's behavior under different loads. This axis data is less useful if the load is constant or varies little.
• Monitor data: a monitor may be selected among the monitors run during the test.
Here is an example of a curve showing the number of hits/sec. for a ramp-up load, using the number of
virtual users as the horizontal axis data:
Deleting all graphs

The "Remove all existing graphs" button in the button toolbar deletes all displayed graphs.
Percentile graphs
A percentile graph may be created to analyze the spread of a statistic's values during a test. This type of
graph is used to determine the percentage of a test statistic at a set value. This may reveal, for example,
that 80% of the response times for web page P were under 5 seconds.
Procedure 9.1. Creating a percentile graph

1. Click on the "New Graph" button.
420
Results
2. Use the ">" button or drag and drop the feature to create a new graph.
3. Select the "Percentile Graph" option.
Using graph templates

During the application testing process, you will frequently find yourself plotting the same graphs for the
project in order to check performance progress as the various changes are made to the application and
server settings.
The "Templates" tab allows you to save time in plotting default graphs for average page response times,
test throughput etc.
You may also create custom graph templates. To do this:
1. Create a graph in the normal way (select the statistics or monitors, colors...).
2. Click on the "Templates" tab.
3. Select a custom template group, or create a new group by right-clicking on the "Custom
templates" node.
421
Results
4. Add the current graph to the template by right-clicking on the group's node or by dragging and dropping
it.
The templates are saved to the project. When a test result cannot be traced on a graph template in its
entirety, the graph shows all the statistics and monitors that can be plotted. A case in point is where the
template includes a statistic for a page that wasn't played during the test.
Comparing test results

Follow the procedure set out below to compare two test result curves.
Procedure 9.2. Comparing two test results

1. Select the first test and plot the statistic for an element.
2. Select the second test, and plot the same statistic on the same graph
Note
The same method may be used to compare the results of several tests.
Scale factor
The scale factor can be edited for each plotted curve in the caption bar of the select graph.
Procedure 9.3. Modifying the scale factor

1. Select the curve to edit in the graph caption bar.
2. Edit the scale factor.
3. Validate the value by hitting the "Enter" key.
Values
This tab allows you to sort and plot elements quickly.
422
Results
Important
Element Types
The "type" drop-down list allows you to select the type of elements to be shown in the panel: virtual
users, containers, pages, HTTP requests, actions (loop, while etc.), performance counters or indicators.
Results Table
The results table shows the statistics for virtual users, containers, pages or HTTP requests:
Virtual user statistics

The statistics for virtual users, containers, Push messages, requests or actions are:
• Min - Minimum response time over the whole test.

• Avg - Average response time over the whole test.
• Max - Maximum response time over the whole test.
• Count - Hit count.
• Errors - Number of failed hits.
• Std Dev - Standard deviation. (Advanced statistic, '-' is displayed when not computed)
• Median - Median. (Advanced statistic, '-' is displayed when not computed)
• Avg-90% - Average 90%. (Advanced statistic, '-' is displayed when not computed). 5% of lowest values
and 5% of highest values removed.
• Min TTFB - Minimum Time To First Byte (TTFB).
• Avg TTFB - Average Time To First Byte (TTFB).
• Max TTFB - Maximum Time To First Byte (TTFB).
Tip
Right-click on an element name, such as a request or page, to switch to its definition in the virtual
user profiles.
Performance counter statistics

The statistics for performance counters are:
• Min - Minimum value for the counter over the entire test duration.
• Avg - Average value for the counter over the entire test duration.
• Max - Maximum value for the counter over the entire test duration.
• Sev - The highest severity level of triggered alerts.
• % critical - Percentage of time spent at critical alert level.
• % warning - Percentage of time spent at warning alert level.
423
Results
Tip
Filter on the Sev column to identify quickly all the counters that triggered an alert.
Advanced statistics
The advanced statistics include standard deviation, median and the average 90%. These statistics are not
computed when a filter is applied on load generators (see the section called “Filtering by Load Generator,
Population or Virtual User”) or when the "Computing statistics" step has been interrupted by the
user at the end of the test.
Advanced statistics computation can be enabled when using filters on load generators. The calculation
is performed during the "Computing statistics" step at the end of the test. The calculation time
depends on the number of load generators and can be very long.
Procedure 9.4. Enabling advanced statistics computation for filters

1. Edit the <neoload>/conf/controller.properties file
2. Change the value of the following key to true:

[Results]compute.advanced.statistics.computesAllCombinations=true
3. Save the file
4. Restart NeoLoad.
5. Launch a new test or filter a previous one on time.
If the "Computing statistics" step takes too long at the end of the test, advanced statistics
computation can be fully disabled.
Procedure 9.5. Disabling advanced statistics computation

1. Edit the <neoload>/conf/controller.properties file
2. Change the value of the following key to false:

[Results]compute.advanced.statistics=false
3. Save the file
4. Restart NeoLoad.
Plotting Curves
Select an HTTP request or web page to display the selected curves. Change the curves displayed for the
selected element by checking or clearing the statistics' check boxes. You may zoom in on the curves as
described in the the section called “Graphs” paragraph.
Right-click on a performance counter's graph to hide/un-hide the alert zones and thresholds.
Indicators
Indicators are performance counters that contain text information. For example, an indicator may contain
text giving details of a database server's version .
424
Results
Exporting Data
Data for the selected element (HTTP request, page or container) may be exported using the Export button.
The Export Wizard provides the following options:
• Export data in CSV format

• Export the image in PNG format
• Copy the image to the clipboard (for pasting into any document: mail, MS Word,...)
Note: Not all test data may be exported at one time.
Errors
This tab contains details of the HTTP request errors.
425
Results
Important
General Information
The number of errors displayed varies depending on the load injector, population and virtual user selected
during filtering. If the "Storage capacity exceeded" warning message displays, it indicates that
the actual number of errors recorded during the test exceeds the number of errors displayed. By default,
the maximum number of error details stored is 20,000.
Procedure 9.6. Changing the error detail storage capacity limit

1. Stop NeoLoad.
2. Open the <NeoLoad Home>/conf/controller.properties file in a text editor.
3. In the [Results]category, change the value of the "max.errors.store.count"key. The

default value is 20000.
4. Re-start NeoLoad and repeat the load test.
Note
Increasing the maximum number of stored errors will have an impact on NeoLoad's performance.
Detailed Error Information

Select an error to display the following information:
• Time - Time between test start and occurrence of error.

• Code - Error code: the HTTP error code as defined by the HTTP protocol or the NeoLoad error code.
• Duration - Duration of the failed request.
• Size - Size of the server response content in bytes.
• Page - Link to the definition of the page containing the request with the error.
• Load Generator - Name of the load generator that played the request containing the error.
• Population - Population within which the request containing the error originated.
• Virtual User - Virtual user within which the request containing the error originated.
• Request - Link to the definition of the request containing the error.
Selected Error Details

Request
Displays details of the HTTP request sent to the server. Check your form parameter values if need be.
Server response
Displays the server response. If the server could not be contacted, this contains an error message generated
by NeoLoad.
426
Results
Note
The details of the response are only stored and displayed for the first few errors in each request. If
the details are not available ("Response not stored" message), go back to the first requests flagged
in error to obtain more details.
Assertions
Displays the assertion results (validations) for the response. Empty if the assertion is validated.
Previous Request
Displays details of the previous request (determined by the referrer) to help find the root cause of the
current error, since an anomaly or error on a page may cause the following page to fail.
Alerts
The Alerts table displays details of the alerts that were triggered on performance counters during the test.
Each line in the table corresponds to a period of time during which the alert threshold was exceeded.
The Alerts Table
• Time. Alert start and end time, relative to the test start time.
• Severity. Alert severity level.
• Name. Alert name. The name comprises the corresponding performance counter's name plus a text
description of the alert threshold.
General Information
427
Results
Use the filter toolbar to filter the alerts by:
• Monitored machine
• Monitor
• Alert severity level
The number of alerts displayed varies depending on the filters used. If the "Storage capacity
exceeded" warning message displays, it indicates that the actual number of alerts recorded during the test
exceeds the number of alerts displayed. By default, the maximum number of alert details stored is 50,000.
Procedure 9.7. Changing the alert detail storage capacity limit

1. Stop NeoLoad.
2. Open the <NeoLoad Home>/conf/controller.properties file in a text editor.
3. In the [Results]category, change the value of the "max.alerts.store.count"key. The

default value is 50000.
4. Re-start NeoLoad and repeat the load test.
Note
Increasing the maximum number of stored alerts will have an impact on NeoLoad's performance.
Alert Information
Select an alert to display the following information:
• Monitored machine. Name of the monitored machine that triggered the alert.
• Monitor. Name of the monitor that triggered the alert.
• Duration. Alert duration.
• Description. Alert description.
• Delay trigger. Trigger delay for the threshold corresponding to the alert.
Alert Graphs
When an alert is selected in the table, the graph displays all the alerts relating to the same performance
counter: a red zone for critical alerts and a yellow zone for warning alerts. The zone corresponding
to the selected alert is shown in a slightly darker color.
The alert threshold values are represented by a horizontal dotted line.
Tip
Click on an alert zone to select the corresponding entry in the table.
Graph options
Check the following boxes to display the corresponding elements:
• User load. Displays the user load.

• Critical Alerts. Displays the thresholds and zones indicating critical-level alerts.
• Warning Alerts. Displays the thresholds and zones indicating warning-level alerts.
428
Results
Debug
The "Debug" tab is enabled when the scenario has been launched in Debug mode. See the documentation
on starting a test in Debug mode and changing the data logging level.
This tab shows the virtual users run during the test.
Important
This tab is disabled if the test has not been launched in Debug mode.
Only those virtual users fulfilling the scenario's Debug mode criteria are available. By default,
only virtual users containing errors are available.
General User Runtime Information

Selecting a virtual user displays the following information:
• Virtual user: Selected user's name.
• Page count: Number of pages executed by the user during the test.
• Request count: Number of requests executed by the user during the test.
• Size: Size of all the pages executed by the user, in bytes.
• Duration: Virtual user's total runtime.
• Error count: Total number of requests containing errors.
Validating a User's Runtime

When the scenario has been run in Debug mode, and once the test is finished, you may view the details
of each instance of a virtual user profile’s run. To do this, select the user you wish to monitor, then click
429
Results
the "Display virtual user" button (also available via the pop-up menu or by double-clicking on
the virtual user).
The virtual user's runtime is displayed in the validation window (see the section on validating a virtual
user for more information on the validation window).
Binary responses are not recorded in Debug mode for performance reasons.
Reports
NeoLoad allows you to generate reports based on test results containing predefined data, graphs and
statistics. A report may also contain custom graphs and comments.
A report may be generated from:
• The Results Manager

• The Summary Panel
• The command line
The Report Wizard

To launch the Report Wizard:
• Click the "Generate report" button in the "Results" section's "Test Summary" tab.
• Open the Results Manager, select the appropriate test and click the "Generate report" button.
Note
The report setting items are saved in the NeoLoad settings. The report settings are common to
all projects.
Report Type
430
Results
The first step in the wizard allows you to select the type of report:
• Standard Report. A report for a single test. Select the desired test results in the drop-down list.
• Comparison Report. A report that compares two sets of test results. Select the test results you want
to compare in the drop-down lists. The "label" field allows you specify the label to be used to identify
the test in the report, in particular in the table column names.
Report Contents
The second step allows you to edit the report's contents:
• Cover Page. Click on the root of the "Content" tree to add a comment to the cover page. Only
PDF and MSWord format reports have cover pages.
• Sections. Check the boxes to select which sections to include in the report. The summary box cannot
be un-checked.
• Main Graphs. Check the boxes to select which predefined graphs to include in the report.
Select the graph in the tree to edit its title and description.
• Custom Graphs. The "Main Graphs" section invites you to include in the report all the custom
graphs in the "Graphs" tab.
Check the boxes to select which custom graphs to include in the report..
Select the graph in the tree to edit its title and description.
Note
Editing the graph title and description changes these items in the graphs in the "Graphs" tab
and vice-versa. Since custom graphs are saved with the project, the titles and descriptions also
are permanent.
431
Results
Output Options
Format
The available formats are:
• Word - Generates a report in RTF format. The report is best viewed in MS Word; this format is not
recommended for OpenOffice.
• PDF - Generates a report in PDF format.
• HTML - Generates a report in HTML format with a menu.
• XML - Generates a report in XML format with its DTD and the graph images by default. This format
is useful when launched from the command line to automatically validate the results as part of the
application's validation process. The report may be customized by using a style sheet (XSL).
Presentation
Click the button to edit the report presentation options (does not apply to XML format reports).
432
Results
Choose the category to edit on the left, then modify the corresponding colors or images.
Only PDF and Word format reports have a cover page and footers. Therefore, these items cannot be edited
for an HTML format report HTML.
Colors
The color picker includes a color preview button and an editable text field that displays the color's
hexadecimal equivalent. Clicking on the colored button opens a visual color picker.
Images
The image picker includes a first button that opens a file selection dialog box. A second button opens
an image preview that displays the actual print size based on the image's print resolution and the screen
resolution.
Important
For optimum rendering, we strongly recommend using images with a high print resolution such
as 300 dpi. See the documentation supplied with Photoshop [http://livedocs.adobe.com/en_US/
Photoshop/10.0/help.html?content=WSfd1234e1c4b69f30ea53e41001031ab64-7936.html] or
Gimp [http://docs.gimp.org/en/gimp-image-print-size.html] for example.
Output
Select the file name for the report to be generated. For HTML and XML format reports, the images
directory containing the images included in the report is created in the same directory as the report file.
Open
When the "Launch generated report" option is selected, the generated report is opened
automatically using the program associated with the report's file extension (Windows only).
Test Results Comparison

Comparing Results in the GUI
NeoLoad graphical interface includes a Compare mode.
Launching a comparison
Procedure 9.8. Launching the comparison

1. Open the Results Manager from the Edit / Results Manager menu.
2. In the table, select the two results to compare.
433
Results
3. Click on the "Compare" button.
4. Edit the labels of the two tests and click "OK". The default labels are 'A' and 'B'.
Using the GUI

The Summary, Values and Graphs tabs switch to Compare mode. The "Errors" and "Debug" tabs
are superfluous and are therefore disabled.
In Compare mode, only the statistics for Avg, Max and Err are displayed, together with the value in the
first test, value in the second test, and percentage difference for each item.
Tip
You may display additional stats in the "Values" panel using the column selector in the upper
right-hand corner of the table.
Percentages color coding
The percentages are displayed in different colors depending on whether the statistic's performance has
improved or deteriorated:
• Green: percentages showing an improvement in performance.
• Red: percentages showing a deterioration in performance.
• No color code is applied to percentages which are not connected to performance.
Consequently, a positive percentage (+20%) will be color-coded differently, depending on the context: for
example, red in the case of a time delay or green in the case of Hits/sec.
Returning to Standard mode

To quit Compare mode, just call up a single test result:
• Select a result in the test result drop-down list, or
• Open the Results Manager, select a result and click on the "Select" button.
Generating a Comparison Report

NeoLoad can generate comparison reports with the same structure and in the same formats (Word, HTML,
PDF, XML) as standard reports.
In Compare mode, only the statistics for Avg, Max and Err are displayed, together with the value in the
first test, value in the second test, and percentage difference for each item.
Procedure 9.9. Generating a comparison report

1. Open the Results Manager from the Edit / Results Manager menu.
2. In the table, select the two results to compare.
3. Click on the "Generate a report" button.
4. Edit the labels of the two tests and click "OK". The default labels are 'A' and 'B'.
434
Results
Test Result Filters

Filtering in the GUI
NeoLoad allows you to filter the results of a test. Applying the filter creates a new set of results, which
can be viewed and used as if they had been produced by a test run that had just been completed.
Warning
Only results generated by NeoLoad version 3.0.0 and later can be filtered.
The GUI displaying the test results allows you to view a filtered test result in the same way as you would
any other result.
Available Filters
Several filters may be applied, either separately or jointly. Details of the filters and their effects are set
out below.
Time period filter

This filter allows you to define a time period in the test that you wish to save. The purpose of the filter is
to reduce the time span for analysis; the start and end date of the filtered test are readjusted to take into
account the filter period.
This filter has two settings:
• Start date sets the start date for the time period to be saved in "hh:mm:ss" format.
• End date sets the end date for the time period to be saved in "hh:mm:ss" format.
Note
The "hh:mm:ss" date format is detailed as follows:
• hh = hours from 00 to 23.
• mm = minutes from 00 to 59.
• ss = seconds from 00 to 59.
435
Results
The start and end dates for the filtered test results generated are calculated based on the selected time
period.
Time Period Selection Wizard

The Time Period Selection Wizard for the test to be saved is accessed in the following way:
1. If it is not already enabled, enable time period filtering by checking the appropriate "Enable" box.
2. Click the "..." button.
The wizard displays a graphic view of the test, including graphs for user load, average response times
and errors.
Set the start or end date for the filtered test as follows:
1. At the bottom of the panel, click either the "Start" or "End" radio button.
2. Place the mouse on the graph at the required start or end point, then click the left mouse button while
holding down the "Ctrl " key.
To validate the new dates, click the "OK" button.
Application example
In a test with a 'peak' load policy, you may want to concentrate on one particular load peak. This filter will
reduce the time frame to be analyzed to a single peak.
Population filter
This filter specifies which populations to save among those run during the test.
The population filter is considered to be active when at least one of the populations run during the test to
be filtered has been un-checked.
Application example
In a test containing several populations, you may want to concentrate on one particular population. It may
be interesting for example to see what buyers at an on-line store "experience" when, at the same time, a
"simply-browsing" population is browsing through the products on offer.
Load generator filter

This filter specifies which generators to save among all the generators used during the load test.
Prerequisite
The Load Generator Filter is available when the statistics have been saved for each individual load
generator during the test. This can be enabled in the project's preferences, "Runtime parameters"
section. See the section called “Statistics”.
Application example
In a test that uses several load generators located in different geographic locations, you may wish to obtain
generator-specific, and thus location-specific, statistics. This will highlight any performance glitches due
to the user's geographical location with regard to the tested web application.
436
Results
Error filter
This filter specifies whether or not errors should be taken into account in the filtered results' statistics
Application example
When a server returns errors under a high load ( HTTP 500 errors for example), the server may respond
more quickly, since it's quicker to return an HTML page with the HTTP 500 error. In these cases, the
statistics will be distorted: the response times are better than in cases where there is no error. Therefore,
the results returning an error must be excluded in order to obtain more realistic statistics.
Filtering Test Results

To apply filters to a set of test results:
1. Go to the "Test Summary" tab in the "Results" section.
2. Select the test results to be filtered in the drop-down list of results, or open the Results Manager and
select the test results to filter.
3. Click the "Filter" button. The Test Results Filter Wizard is displayed.
4. Select and configure the filters you wish to apply to the test results.
5. Check or clear the "Save filtered results" check box. When the box is checked, the filtered
results are saved; if it is cleared, the filtered results are deleted when:
• the NeoLoad application is shut down;
• the project is closed.
6. Click "OK" to generate the filtered results.
Note
The filters applied to a set of test results are displayed in the test's Results Summary.
Generating a Filtered Test Report

Generating a filtered test report is done in the same way as for a standard test report. The filters applied
to the results are also shown in the reports.
For more information, see the documentation on generating a report.
437
Part III. User guides
Table of Contents
10. Design User Guide ..................................................................................................... 441
Key Steps .............................................................................................................. 441
To Learn More ....................................................................................................... 444
11. Oracle Forms User Guide ............................................................................................ 445
Overview ............................................................................................................... 445
Prerequisites ................................................................................................... 445
Configuring NeoLoad ...................................................................................... 445
Configuring the Oracle Forms Server .................................................................. 445
Examples of Recordings ........................................................................................... 445
Preview ......................................................................................................... 445
Message Object .............................................................................................. 446
Message Structure ........................................................................................... 446
Request Naming .............................................................................................. 447
Advanced Configuration ........................................................................................... 448
General Settings .............................................................................................. 448
Project Settings ............................................................................................... 448
Advanced Design .................................................................................................... 449
Understanding the Context ................................................................................ 449
A Component's Life cycle ................................................................................ 449
Correlating Dynamic Component Names ............................................................. 450
Limitations ..................................................................................................... 451
Best Practices ......................................................................................................... 451
Design ........................................................................................................... 452
Validation ...................................................................................................... 452
Runtime ......................................................................................................... 452
Troubleshooting ...................................................................................................... 452
Design ........................................................................................................... 452
Runtime ......................................................................................................... 456
12. Best Practices ............................................................................................................ 462
Defining Objectives ................................................................................................. 462
Types of objective ........................................................................................... 462
Defining criteria for success or failure ................................................................ 462
Producing a Realistic Test ........................................................................................ 463
Defining the number of Virtual Users. ................................................................ 463
Defining several types of Virtual Users ............................................................... 463
Using different user accounts and values ............................................................. 463
Testing load balancers ...................................................................................... 463
Simulating actual user bandwidth ....................................................................... 464
Tips .............................................................................................................. 464
Making your Results Talk ........................................................................................ 464
Producing informative results ............................................................................ 464
Using results .................................................................................................. 465
13. Heavy Load Testing Guide .......................................................................................... 467
Introduction ............................................................................................................ 467
NeoLoad Scenarios .................................................................................................. 467
Minimize the Number of Validations .................................................................. 467
Avoid Validations and Extractions on Bulky Inputs ............................................... 467
Optimize Regular Expressions ........................................................................... 468
Optimize Extractions from XML Responses ......................................................... 468
Avoid Multiplication of Virtual Users ................................................................. 468
Minimize the Use of JavaScript Actions .............................................................. 469
439
User guides
NeoLoad Controller ................................................................................................. 469

Launch Scenarios with a Fixed Duration ............................................................. 469
Monitor Using a Top-down Approach ................................................................. 469
Avoid Debug Mode ......................................................................................... 469
Warm Up Your Application Server .................................................................... 469
Plan for Large Amounts of Memory for the NeoLoad Controller .............................. 469
Reduce Error Management ................................................................................ 470
Save your Projects Locally ............................................................................... 470
Adapt the Controller/Load Generator Time Limit to Your Specific Project
Requirements .................................................................................................. 470
NeoLoad Load Generators ........................................................................................ 470
Allocate Sufficient Memory to the Machines Hosting Controllers and Load Generators
..................................................................................................................... 470
Make Sure the Machines Running the Generators are Adequately Dimensioned ........... 471
Caution when using virtual environments ............................................................ 471
Network Tuning and Configuration ............................................................................ 471
Increase the Number of Simultaneously Opened Sockets ........................................ 472
Use Several Network Cards for Load Generators .................................................. 472
Distribute NeoLoad Communication Channels Over Different Networks .................... 472
Prefer a "Server" Tagged Operating System for your Application Servers ................... 472
440
Chapter 10. Design User Guide
This guide describes how to design Virtual User profiles efficiently. It is a methodological guide, the
points discussed here being detailed further on in the reference guide and in the tutorials. We strongly
recommend that you read this guide before you start your first tests, after having first acquainted yourself
with NeoLoad by reading the Quick Start Guide.
Key Steps
Load testing requires that particular attention be paid to a number of points if meaningful results are to be
obtained. It is important to reproduce the many varied ways a web application can be used and to make
sure that they are played back correctly. This involves the following key steps:
1. Recording the Virtual User. A Virtual User simulates the actions of a real user browsing the web
application. To create a Virtual User, click the "Record" button in the NeoLoad toolbar. This will
launch an Internet browser to allow you to browse the application and record the required user behavior.
NeoLoad acts as a proxy for the Internet browser and therefore records the HTTP requests exchanged
with the server. The requests are grouped into pages that generally correspond to one click in the
application.
While browsing, you may create containers representing the business transactions that are carried out.
These containers group together the requests and pages relating to a same transaction, such as a login or
the purchase of an item in an e-business application for example. You may create business transactions
in a Virtual User after finishing the recording. For more details on this, see the section called “Creating
Business Transactions”.
Once the recording is finished, NeoLoad searches for dynamic parameters, for example session id's,
and automatically manages them so that the recorded user profile can be played back correctly.
For more information on recording, see the section called “Recording a Test Scenario”.
2. Validating the Virtual User's behavior. Simulating users is not just a matter of playing back the
requests sent to the server. Even if most of the dynamic parameters are automatically handled by
NeoLoad, thanks in particular to the dynamic parameter search, some still need special attention. By
validating the Virtual User you ensure that NeoLoad plays back all these parameters correctly.
Validation involves playing out the Virtual User profile and playing the requests on the server. The
graphical interface displays all the requests and the server's responses, their HTML rendering and the
state of the variables within the scenario. This allows you to check the Virtual User's behavior and to
make sure that it does not contain any errors.
Beware, NeoLoad does not detect all errors automatically. Even if HTTP error codes are detected by
NeoLoad as a cause of a failed validation, functional errors (such as the incorrect playback of a business
transaction) can escape detection. This is because applications often return pages in error that contain
valid HTTP codes. Therefore, it is important to make sure that the content or HTML rendering does in
fact correspond to the expected result. For example, an incorrectly played-back login often produces
an HTML page stating that "the login or password is incorrect".
For more information on Virtual User validation see the section called “Checking a Virtual User”.
3. Correcting the Virtual User's behavior. When a check of the Virtual User's behavior reveals a
problem, it is important to understand the cause of the problem, which is often linked to the incorrect
playback of one or more parameters using incorrect values. To be able to correct the problem in an
441
Design User Guide
efficient manner, the parameters involved must be checked one by one, in the order they are used in
the Virtual User profile.
The main steps involved in correcting a Virtual User's behavior are:
1. Identify the first request that returns an error: typically, this is a server response containing
an HTTP error code or an unexpected HTML content.
2. Identify the parameter that requires attention: this can be any parameter in the pinpointed
request whose value may change at each playback, for example a session ID.
3. Find the request whose response contains that parameter's value: this value must be extracted
by NeoLoad. The Flags function is particularly useful for finding the request in question.
4. Decide on the appropriate method to handle the parameter: NeoLoad provides several tools
for handling dynamic parameters, each adapted to a particular situation. To choose the most
appropriate for the case in question, see the section called “Choosing a Data Extraction Method”.
5. Apply the selected method: depending on the method, the requests that appear after the request
on which the extractor has been placed must be modified to use the extracted variable instead of
inserting the recorded value.
6. Search for dynamic parameters: the error, since corrected, may have prevented the detection
of other, subsequent dynamic parameters. We recommend therefore that you start a new dynamic
parameter search (see the section called “Frameworks”).
7. Validate the Virtual User's behavior: the aim is to check to make sure that the problem in
question as been corrected.
This procedure for handling dynamic parameters is explained in detail in the "Handling an Application's
Dynamic Parameters" tutorial.
4. Changing behavior using logical actions. NeoLoad's logical actions allow you to change a Virtual
User's behavior to adapt to the simulation's requirements:
• Certain actions cause only a slight change to the behavior, for example inserting a pause, grouping
several pages as a business transaction, modifying a variable or stopping a Virtual User.
• Loops can be used to repeat typical user routines, for example a particular business transaction.
• Conditional actions can be inserted to simulate certain actions that are conditional upon feedback
from a server or an error occurrence.
• JavaScript actions can be used to carry out simple functions in order to update variables or carry
out specific tasks.
• Rendez-Vous synchronize selected Virtual Users at a single point before releasing them to complete
their scenarios.
When logical actions are introduced to modify a Virtual User's behavior, we recommend you check the
Virtual User's validity again and make any necessary corrections.
Details of the various logical actions available can be found in the section called “Logical Actions”.
5. Using different login accounts and values. Variables may be used to dynamically change key
values such as user logins or certain form parameters (for example, a productID in an e-business
application).This is useful mainly for getting around the server's use of the cache, since:
442
Design User Guide
• playing the same requests using the same values results in abnormally high performance, due to the
various caches (pre-loading into memory, connection pools, system optimization...)
• completely disabling the caches (where possible) does not give a realistic view of performance either.
As before, when variables are used to modify a Virtual User's behavior, we recommend you check the
Virtual User's validity again and make any necessary corrections.
6. Validating key pages. Under load, it's important to check that the server response is valid to make
sure the scenario is working as predicted and the high load isn't resulting in errors on the application.
NeoLoad automatically detects the requests in error by using the returned HTTP code in particular.
For example, a request that returns a '500 Internal Error' code will be flagged by NeoLoad as an error.
However, many Web applications do not return an appropriate HTTP error code as part of their error
management and NeoLoad is unable to detect the fault automatically.
These cases have to be managed individually by checking the validity of the content returned by the
server at key points in the application. For example, you may verify the presence of an expected text
string such as "The operation was successfully completed", or make sure the response does not contain
"Error".
To define a content validation:
a. In the Virtual User, click on the request whose response needs to be validated.
b. Click the Validation... button in the bottom right-hand corner.
c. Add a validation on the content.
d. Select the validation mode: search for the presence or absence of a simple text string, or use a regular
expression.
At the end of the test, select the requests flagged in error or whose validation failed in the Errors pane,
then analyze the content of the corresponding server response in order to find the cause of the problem.
Note that content validation uses up resources on the Load Generator (CPU, memory..), therefore it
can be wiser to concentrate on testing key pages only (for example pages giving access to databases
or those that are more likely to fail).
Setting up request validations is explained in more detail in the "Validating a Server Response" tutorial.
7. Defining several types of Virtual User. As not all users use a web application in the same way, it
is important to define a Virtual User for each user profile, for example "just browsing", "browsing and
editing" and "administrator". The aim is to cover the business transactions that are most common and
the most representative for the application being tested.
These Virtual User profiles must then be grouped into Populations. Populations are used to maintain
a ratio between users during the variation in load. For example, you may decide to maintain a ratio of
90% standard users and 10% administrators whatever the total simulated load.
Populations also allow you to select certain parameters such as maximum bandwidth for a Virtual User
or how the cache is managed.
For more information, see the section called “Populations” in the Reference Guide.
443
Design User Guide
To Learn More
See the Best Practices guide for more information on load testing methodology.
Once the Virtual User profiles have been set up correctly, we recommend you configure the monitors that
will allow you to monitor your server infrastructure during the load tests.
See the tutorials for assistance on specific issues related to designing Virtual Users, analysis and other
miscellaneous subjects.
In the event of a problem, refer to the Troubleshooting Guide or F.A.Q.
444
Chapter 11. Oracle Forms User Guide
Overview
This guide describes how to carry out a load test on an application using Oracle Forms under optimum
conditions. We strongly recommend that you read this guide before you start your first tests, after having
first acquainted yourself with NeoLoad by reading the Quick Start Guide and the Design User Guide.
During a test, NeoLoad records the requests and responses exchanged between the Oracle Forms applet
and the server. For these exchanges to be intercepted, both NeoLoad and the Oracle Forms server need
to be configured.
Prerequisites
NeoLoad supports Oracle Forms 9i, 10g and 11g in HTTP mode only.
Configuring NeoLoad
The Oracle Forms applet file must be copied into the <neoload>/lib/plugins/ext directory. By
default, the Oracle Forms applet file can be found in the Oracle Forms installation at: <oracle_home>/
forms/java/frmall.jar. For further information, see the documentation on configuring NeoLoad
for Oracle Forms.

NeoLoad supports the naming of Oracle Forms components. This allows NeoLoad to identify the Oracle
Forms graphical components by their name instead of by a number.
To configure the server, see the documentation on configuring the Oracle Forms server for NeoLoad
You may check to see if the Oracle Forms server is configured correctly.
Procedure 11.1. How to check that the Oracle Forms server is configured correctly
1. Make a recording.
2. In NeoLoad, find the page with the name starting with 1:initial_version.
3. Expand the page, then click on the request with the same name as the page.
4. In the XML content, find the INITIAL_CMDLINE property.
5. In the relevant value tag, find the record=names string. If the string is present, then the Oracle
Forms server is correctly configured. If the string is not present, the Oracle Forms server needs to be
configured. See the documentation on configuring the Oracle Forms server for NeoLoad.
Examples of Recordings
Preview
Preview of successfully recorded Oracle Forms requests:
445
Oracle Forms User Guide
Each virtual user may contain several pages that, in turn, may each contain several requests.
An Oracle Forms request is displayed in XML format. It comprises one or more DataMessages, with
one or more Properties.
Message Object
Oracle Forms messages only contain graphical information. The Oracle Forms applet running in the client-
side browser acts as a slave to the server, sending the user's actions and waiting for instructions on the
graphical changes to apply.
Message Structure
An Oracle Forms message is a set of graphical actions, as can be seen in this example of a request:
<Dialog>
<actionType>UPDATE</actionType>
<messages>
<DataMessage>
<actionCode>UPDATE</actionCode>
<handlerName>LOGIN_USERNAME_0</handlerName>
<handlerId>15</handlerId>
<properties>
<Property>
<id>VALUE</id>
<type>STRING</type>
<value objectClass="String">u3</value>
</Property>
<Property>
<id>SELECTION</id>
<type>POINT</type>
<value objectClass="Point">
<x>2</x>
446
<y>2</y>
</value>
</Property>
<Property>
<id>CURSOR_POSITION</id>
<type>INTEGER</type>
<value objectClass="int">2</value>
</Property>
</properties>
</DataMessage>
<TerminalMessage>
<responseCode>1</responseCode>
</TerminalMessage>
</messages>
</Dialog>
The Dialog element indicates the message's principal purpose; in this case, it's an UPDATE -type message
for the applet's graphical interface. It contains several messages, each DataMessage element describing
an action applied to one of the interface's graphical components.
Some examples of graphical components: Window, Canvas, List, TextField etc.
Each DataMessage references a graphical component by its handlerId.
A DataMessage has several attributes:
• actionCode: indicates the action applied to the graphical component. Examples: CREATE, UPDATE,
DESTROY.
• handlerId: the component's unique identifier. In requests and responses, graphical components are
referenced using a unique identifier, the handlerId. The handlerId identifier is created and
assigned to a graphical component by the server.
• handlerClassId: indicates the graphical component's type. Examples: HELP_DIALOG,

BUTTON_ITEM, CHECKBOX_ITEM, 539. A number in this field indicates that the type of the
component referenced by the DataMessage could not be identified.
• handlerName: indicates the graphical component's name within the applet.
• properties: describes the changes made to the graphical component. Each property has an id, a
type and a value.
Note
Component naming must be enabled prior to recording for the recorded requests'
DataMessages to have a handlerName.
Some Oracle Forms components do not have names. In this case, the DataMessage that
references the component will not have a handlerName.
Request Naming
Oracle Forms requests are named according to the following rule:
<handlerName>:<propertyType>=<propertyValue>
447
• handlerName: name of the graphical component. If no name is found, it is replaced by the appropriate
handlerId.
• propertyType: type of property
• propertyValue: value of the property
Example: login_username_0:value=u3 indicates that the login_username_0 graphical

component has been given the value u3.
Advanced Configuration
General Settings
During recording, NeoLoad compares the HTTP headers in the request and response with those configured.
When there is a match, the request is identified as an Oracle Forms request and the encapsulated binary
data is decoded.
By default, the HTTP headers are configured to recognize Oracle Forms 9i and 10g messages.
To change the module's general settings, see the documentation on Oracle Forms General Settings.
Project Settings
During recording, NeoLoad simultaneously uses two mechanisms to prepare the requests for execution :
• NeoLoad deletes DataMessages that reference invalid components (non-existing or previously

destroyed). These DataMessages are removed from the requests.
• NeoLoad adds the component names to the requests, enabling the handlerId's to be handled
dynamically. The component naming option must be configured on the Oracle Forms server for this
mechanism to function.
During a test run, NeoLoad plays back the recorded requests.
For each played-back request, NeoLoad searches the previous responses to find the component having the
same name and replaces the Id assigned by the server (its handlerId). This mechanism only functions
if the component has a server-assigned name.
If the component does not have a name, NeoLoad compares the played-back response with the recorded
response and updates the component's handlerId. This mechanism only functions if the response
received during the test playback contains exactly the same number of DataMessages as during
recording.
NeoLoad also checks to make sure the handlerId's used in the requests' DataMessages reference
valid Oracle Forms components. If one or more invalid components are found, an error is returned and
the virtual user is stopped.
Note
The virtual user is stopped to prevent further messages containing invalid components being sent.
To change the module's project settings, see the documentation on Oracle Forms Project Settings.
448
Advanced Design
Understanding the Context
Each Oracle Forms request references a component that has been previously created by the server. If the
request sequence changes, compared with the sequence recorded, then the components' life cycles must
be taken into account:
• The requests must always reference valid components.
• The request sequence must take into account the components' graphical state.
For further information, see the Designing an Oracle Forms Scenario with Iterations tutorial.
A Component's Life cycle

Each Oracle Forms component is created, then destroyed, by the server. These operations are carried out
within the responses returned by the server. Between the creation of a component and its destruction, its
properties are updated by the requests sent to the server.
This example shows the life cycle of a text field:
1. The server sends a response containing a message that creates a component named
LOGIN_USERNAME_0.
<DataMessage>
<actionCode>CREATE</actionCode>
<handlerClassId>257</handlerClassId>
<properties>
<Property>
<id>TITLE</id>
<type>STRING</type>
<value objectClass="String">LOGIN_USERNAME_0</value>
</Property>
<Property>
<id>MAX_LENGTH</id>
</Property>
...
</properties>
</DataMessage>
The LOGIN_USERNAME_0 component is now valid. It can be updated in the subsequent requests.
2. The client sends a request to update the LOGIN_USERNAME_0 component, containing the value u3
in the text field.
<DataMessage>
449
<properties>
<Property>
<id>VALUE</id>
<type>STRING</type>
<value objectClass="String">u3</value>
</Property>
<Property>
<id>SELECTION</id>
<type>POINT</type>
<value objectClass="Point">
<x>2</x>
<y>2</y>
</value>
</Property>
<Property>
<id>CURSOR_POSITION</id>
</Property>
</properties>
</DataMessage>
3. The server sends back a response containing a message that destroys the LOGIN_USERNAME_0
component.
<DataMessage>
<actionCode>DESTROY</actionCode>
<properties/>
</DataMessage>
The LOGIN_USERNAME_0 component is now invalid. It can no longer be updated, since it no longer
exists.
Correlating Dynamic Component Names

During recording, certain components may have a dynamic name. The following code shows a recorded
request containing a component with a dynamic name:
</Dialog>
<messages>
<DataMessage>
<handlerName>Sales Orders (Vision Operations) - 63850, Business World</handlerNa
<properties>
<Property>
<id>EVENT_MENU</id>
450
</Property>
</properties>
</DataMessage>
<TerminalMessage>
</TerminalMessage>
</messages>
</Dialog>
When played back, the virtual user fails to run correctly because the server has given the component a
different name. In the above example, the component's name ends with 63850, Business World,
which is its dynamic element. To get around this problem, simply delete the dynamic part of the
component's name to obtain the following XML:
</Dialog>
<messages>
<DataMessage>
<handlerName>Sales Orders (Vision Operations) - </handlerName>
<properties>
<Property>
<id>EVENT_MENU</id>
</Property>
</properties>
</DataMessage>
<TerminalMessage>
</TerminalMessage>
</messages>
</Dialog>
During runtime, NeoLoad will find the dynamic part of the component's name and replace it in the played
request.
Note
Correlating dynamic component names works only when the dynamic element is at the end of
the component's name.
Limitations
With advanced design, all the components' life cycles must be followed. When adding a loop in a virtual
user, it's vital for the components to be in the same state both at the start and at the end of the iteration.
Loops will only work if this guideline is adhered to. Failure to do so will result in NL-OF-PLUGIN-
ENGINE-03 -type errors when the virtual user is run.
For further information, see the Designing an Oracle Forms Scenario with Iterations HowTo
Best Practices
To get the best out of a load test on an Oracle Forms application, we recommend the following:
451
Design
• Enable the component naming option on the application server.
• Enable all the Oracle Forms options in the NeoLoad project.
• Close all browser instances before starting a new recording.
• Wherever possible, input user actions in the Oracle Forms applet using the keyboard.
• Input user actions in the applet slowly.
• Limit the number of actions carried out by a virtual user. If necessary, create several virtual user profiles
that each carry out a separate series of actions.
• Rename the pages during the recording using names that identify the relevant actions carried out in the
applet.
• Quit the Oracle Forms applet correctly before ending the recording. We recommend clicking on Action
--> Exit in the applet rather than closing the browser.
• Make sure that the Oracle Forms requests are correctly identified and decoded.
• Validate the key requests in the scenario.
• Use as few validations and variable extractors as possible, especially on large-size XML responses.
Validation
• Configure NeoLoad so that it does not error-flag the HTTP 404 response code already present in the
recording.
• Play the page think times.
• Validate all the scenario's virtual users and check that they run correctly with no errors.
Runtime
• Set the scenario's population stop policy as "Indeterminate: allow all virtual users
to end their actions".
• Warm up the server: run a few tests with a small number of simultaneous virtual users to "warm up"
the server before submitting it to a heavy load.
Troubleshooting
Design
1. When I record an Oracle Forms scenario, I get the following message: Java Oracle Forms library
missing.
452
For NeoLoad to function properly, a Java library from the Oracle Forms application server must be
copied in NeoLoad. The library must be placed in the folder specified in the message.
Note
Once the library has been copied into NeoLoad, you must re-start NeoLoad (you don't need
to re-start the machine itself) for the changes to take effect.
2. NeoLoad has not identified the Oracle Forms requests. The Oracle Forms requests in the recording
look like standard POST binary requests.
Check the following:
1. Make sure NeoLoad contains the Oracle Forms library. A pop-up window should have notified
you that the Oracle Forms library was missing. See the Oracle Forms module's general
documentation for information on adding the library to NeoLoad.
At the end of recording, if the Oracle Forms library is missing but NeoLoad has correctly
identified the requests, you should see requests that have the Oracle Forms icon, but which haven't
been decoded.
453
2. The Oracle Forms library has been added, but NeoLoad hasn't identified the Oracle Forms
requests. The Oracle Forms requests do not have the Oracle Forms icon and look like standard
POST binary requests.
Procedure 11.2. Resolving the problem
1. Make a recording with the Oracle Forms application.
2. Manually search the recording and locate the Oracle Forms requests.
A non-identified Oracle Forms request shows up as a POST binary request whose binary
content is unreadable.
3. Click on the "Advanced..." button, then select the Recorded request tab.
4. Copy the contents of the text field into a text file for future reference.
454
5. Select the Recorded response tab.
6. Copy the contents of the text field into another text file, again for future reference.
7. Exit the request's advanced parameters window.
8. Click on Edit > Preferences > General settings > Oracle Forms.
9. Compare the request's Content-type and User-Agent headers with the regular
expressions configured.
10. Compare the response's Content-type and Server headers with the regular
expressions configured.
11. If necessary, add new regular expressions by checking the headers in the recording.
12. Repeat the recording run and check to make sure the recorded requests have been decoded
into XML format..
Note
For further information on compiling regular expressions, see the appendix dedicated
to regular expressions.
3. The non-decoded requests in the recording still aren't decoded, even after correcting the HTTP
headers in the Oracle Forms general settings.
The changes are not retroactive, so you need to make further recording. It may require several
recordings until you find a functioning regular expression and the recorded requests are correctly
decoded.
4. When recording an Oracle Forms scenario, some recorded requests aren't properly decoded. Most
of the requests have been decoded normally.
Before starting a new recording, make sure you have closed all browser instances, especially if some
are still open and connected to Oracle Forms applets. Such non-decoded requests captured during
recording usually come from Oracle Forms applets open in other browser instances.
5. When recording an Oracle Forms scenario using WebUtil, the Oracle Forms applet freezes.
NeoLoad does support the WebUtil technology. If WebUtil is used to communicate with dll's, there
may be a conflict between the browser that is automatically launched by NeoLoad for the recording
and the loading of these dll's. The best way to solve this is to launch the browser manually as follows:
Procedure 11.3. Oracle Forms applet freeze workaround
1. In the NeoLoad menu, click "Record > Start recording".
2. Un-check the "Launch browser" option.
3. Manually launch the Internet browser, then manually set the proxy to the NeoLoad proxy
(default: localhost:8090). See the the section called “Manually configuring the recording
proxy settings” for more details.
4. Record the Oracle Forms scenario.
455
5. Log out of the Oracle Forms application.
6. Restore the original proxy settings in the browser, then close the browser.
7. In the NeoLoad menu, click "Record > Stop recording".
Runtime
1. When I validate a virtual user, it stops on an NL-PLUGIN-ENGINE-03 error.
Oracle Forms requests that have not been decoded correctly cannot be played back; nor can they be
repaired. See the other questions and answers in this section of the documentation and try to identify
the problem you are experiencing.
Note
Once a problem has been solved, we recommend you delete the previous recordings that
did not play back correctly.
2. I have recorded a simple Oracle Forms scenario. I've not modified the recording and have played
it back "as is", using virtual user validation. The "Automatically delete invalid components during
recording" option is disabled. The virtual user fails to execute and an NL-OF-PLUGIN-ENGINE-03
error is returned.
456
The Oracle Forms applet can sometimes send requests that contain components that are invalid at
the time of recording. The problem can be solved in two ways.
1. Manually delete the request DataMessages that reference invalid components.
2. Enable the "Automatically delete remove invalid components" option for the
Oracle Forms project and make a new recording.
Procedure 11.4. Manually deleting invalid components
1. Carry out a validation on the virtual user containing the error in question.
2. Select the request that includes the error. In the "Details" pane, click on the Response
button.
3. Note the handlerId's that are shown between square brackets [ ] and labeled as unknown.
4. Click on the blue "Request" link to automatically open the request ion the library.
5. In the XML content, delete the DataMessages whose handlerId's are reported as being
unknown.
6. Re-run the virtual user validation. Repeat steps 1 to 5 for each request showing the same error.
457
Procedure 11.5. Automatically deleting invalid components
1. Go to Edit > Preferences > Project settings > Oracle Forms.
2. Check the Automatically remove invalid components check box, then click OK.
3. Repeat the recording of the Oracle Forms application.
4. Run a virtual user validation and make sure there are no more NL-OF-PLUGIN-ENGINE-03
errors.
Note
The changes are not retroactive, so the previous recordings are not affected. Consequently,
if you wish to replay the previous recordings, they will need to be cleaned up by carrying
out the procedure for manually deleting invalid components.
3. I've recorded a simple Oracle Forms scenario and created a virtual user that loops a number of Oracle
Forms requests over n iterations. The virtual user fails to execute and returns an NL-OF-PLUGIN-
ENGINE-03 error. I noticed that the virtual user stopped on this error during the 2nd iteration of the
loop. The "Automatically remove invalid components during recording" option is enabled.
The problem is in the virtual user design. This indicates that the virtual user was not in the same
graphical state in the Oracle Forms applet in the 2nd iteration as it was in the 1st. At the start of each
iteration of the loop, the virtual user must be in the same graphical state, to the nearest click.
The graphical state of an Oracle Forms applet is defined as a set of graphical components existing
at any one time. This example shows a component created in a server response:
<DataMessage>
<actionCode>CREATE</actionCode>
<handlerClassId>259</handlerClassId>
<properties>
<Property>
<id>DRAWN_CANVASUSAGE</id>
<type>BYTE</type>
<value objectClass="byte">3</value>
</Property>
</properties>
</DataMessage>
This creates a component with the handlerId 8. The handlerId 8 can now be used in
DataMessage in all subsequent requests. When the following message is encountered in a server
response
<DataMessage>
<actionCode>DESTROY</actionCode>
<properties/>
</DataMessage>
458
The component with the handlerId 8 is destroyed. Requests sent after this response can no longer
contain DataMessages that reference the component with the handlerId 8.
Note
It is possible for a handlerId value to be re-used by a completely different type
of graphical component later in the recording. These numerical identifiers are uniquely
assigned by the server to concurrently occurring components, but may be used by several
different components whose life cycles are disjoint.
4. When I validate a virtual user, it stops on an NL-OF-PLUGIN-ENGINE-01 error. The details reveal
an ifError error.
There are several types of ifError, of which the most common are:
• ifError:3
The server indicates that the client does not handle cookies. Enable cookie handling for that virtual
user.
• ifError:4
The server could not create the Oracle Forms process. There is a problem server-side.
• ifError:5
The server could not start the Oracle Forms process. There is a problem server-side.
• ifError:6
The server process used to manage the current Oracle Forms session no longer exists. This can
happen when the server is subjected to a heavy load or if there is a design flaw in the virtual user
being played back. In the latter case, please read through the section entitled Best Practices.
• ifError:7
The server process is currently busy. Re-try the request later. This error indicates that NeoLoad
tried sending the request 5 times but did not receive a valid response from the server.
• ifError:11/xxx
The server is busy, re-try the request in xxx milliseconds. This type of error is handled
automatically by NeoLoad and should not appear during the test.
5. The troubleshooting guide has been helpful, but I still need to know more about the way NeoLoad
works during recording and runtime.
The Oracle Forms module may be used in DEBUG mode, which writes even more data to the log
files. It can be turned on for debugging a specific use case, but never in a real test runtime.
During recording, data is written to log files named plugins.log.xxxxx.
During runtime, data is written to log files named loadgenerator.log.xxxxx.
You may quickly access the NeoLoad directory containing the log files by clicking on Help >
Open logs folder.
459
Procedure 11.6. Using the Oracle Forms module in DEBUG mode
1. Close NeoLoad.
2. Open the <neoload>/conf directory, then open the files logs.xconfig and
lglogs.xconfig.
3. Replace the following line
<category name="neoload.plugins" log-level="ERROR">
with this line
<category name="neoload.plugins" log-level="DEBUG">
4. Re-start NeoLoad. The module is in DEBUG mode for both recording and runtime.
6. When a virtual user executes, I get the following error:
Message: An error occurred while reading the encrypted Oracle Forms

response.
Details: Oracle Forms request max retry count reached (5)
When the server responds with ifError:7/500, NeoLoad reproduces the Oracle Forms applet's
behavior: by default, it makes a maximum of 5 attempts to send the request to the server and receive
a valid response, with a 1000 milliseconds interval between attempts. NeoLoad's behavior may be
modified by editing the controller.properties configuration file.
Procedure 11.7. Re-configuring Oracle Forms settings in NeoLoad
1. Close NeoLoad.
2. Open the <neoload>/conf/controller.properties file.
3. If the [OracleForms] settings category does not exist, create it.
4. Underneath the category, create the

oracle.forms.session.migration.max.retry key. Here's an example:
oracle.forms.session.migration.max.retry=5
This key sets the maximum number of attempts before returning an error at 5. By default,
NeoLoad makes a maximum of 5 attempts. The key's value must be an integer more than or
equal to 1.
5. Create the oracle.forms.session.migration.retry.delay key. Here's an

example:
oracle.forms.session.migration.retry.delay=1000
This key sets the interval between attempts, in milliseconds. By default, NeoLoad applies an
interval of 1000 milliseconds. The value must be an integer more than or equal to 1000.
6. Save the configuration file.
460
7. Re-start NeoLoad.
7. After an Oracle Forms load test, several frmweb.exe processes remain on the server.
Check the following:
1. Make sure each virtual user quits the Oracle Forms application correctly. If this is the case, the
last Oracle Forms request will be named something like session_close and its HTTP header
should contain ifSession: close.
2. Make sure the stop policy for each population is set to "Indeterminate: allow all
virtual users to end their actions".
461
Chapter 12. Best Practices
Defining Objectives
Types of objective
A load test can be used to test an application's robustness and performance, as well as its hardware and
bandwidth capacities. The requirements should be clearly defined in order to set precise objectives for the
test. These objectives may be of different types:
• Check an application's stability. The number of simultaneous users of the application must be
known already. The test should answer the following questions:
# Is the server capable of handling a certain number of simultaneous users ?
# Is the average response time for pages acceptable under this set load ?
# Does the server revert to normal behavior after a load peak ?
This type of test is called a load test. The simulated load remains constant over a long period.
The meaning of acceptable response time must be defined beforehand as the notion can differ depending
on the application tested and the type of page. A simple page should display faster than a page full of
search results, which takes time and for which the user is prepared to wait.
The CPU and memory usage should be closely monitored throughout the test. The server is considered
overloaded if these usage figures regularly exceed 90%.
It is equally important to test the server's capacity to recover after a load peak. Many applications are
subjected to load peaks, for example an intranet at 8.30 a.m., resulting in a temporary stress on the
application. It is necessary, therefore, to check that no damage is done to the system as a result of these
peaks. This type of test can also pinpoint memory leakage or resource management problems.
• Establish the number of simultaneous users an application can handle. This test can be used
to validate a hardware configuration or targets set for application visits. The test should answer the
following questions:
# How many users can the application handle while maintaining an acceptable response time?
# What is the load threshold above which the server begins to generate errors and/or refuse connections?
# Does the server remain functional under high load or does it crash?
This type of test is called a stress test. The load is progressively increased to discover the different
breaking points.
Use a scenario with a ramp-up load, starting from normal and up to the maximum predicted limit, and
monitor the response times and error rates. A sudden change indicates that a threshold has been passed.
• Validate performance variations after an application or infrastructure update. The test should
answer the following questions:
# Have the implemented upgrades resulted in real performance gains?
# Which pages have seen a loss in performance?
With NeoLoad, a performance comparison may be made between two sets of test results. NeoLoad also
allows you to filter test results using different criteria.
Defining criteria for success or failure

Defining the success or failure criteria is a prerequisite to any test. Before testing an application, set the
acceptable levels for robustness and performance.
462
Best Practices
In most cases, these criteria are defined in terms of response time, error rate or number of requests per
second:
• Define an average response time per page (may be different from one page to another).
• Define a maximum response time per page (may be different from one page to another).
• Define a maximum error rate.
With NeoLoad, some of these criteria may be checked using request validations.
Producing a Realistic Test

Certain points in the load test require particular attention if informative results are to be obtained.
Simulating users does not consist of merely playing back requests to the server. Even if most of the dynamic
parameters are created by NeoLoad (cookies, sessionID), some do need special attention.
Defining the number of Virtual Users.

The number of Virtual Users must be close to the number of real users once the application is in production,
with a realistic think time applied between pages. Avoid testing with less Virtual Users with a minimized
think time. It could be assumed that the result would be the same, as the number of requests played per
second is identical. However, this is not the case, for the following reasons:
• The memory burden on the server will be different: Each user session uses a certain amount of memory.
If the number of user sessions is underestimated, the server will be running under more favorable
conditions than in real-life and the results will be distorted.
• The number of sockets open simultaneously on the server will be different. An underestimation of user
numbers means the maximum threshold for open server sockets cannot be tested.
• The resource pools (JDBC connection pools) will not be operating under realistic conditions. An
inappropriate pool size setting might not be detected during the test.
Defining several types of Virtual Users

Not all users use a web application in the same way. Define a Virtual User for each user profile: simple
browsing, browsing with modifications, system administrator...
Group these user types into a Population. Populations allow a user ratio to be maintained when the load
varies. For example, a ratio of 90% standard users and 10% system administrators may be selected.
Using different user accounts and values

Use variables to dynamically modify key values such as user account logins or certain form parameters
(such as productID in an e-business application). The main idea of this is to bypass the use of the various
server caches, for the following reasons:
• Playing the same requests with the same values produces an unrealistically high performance, due to
the use of various caches: preloading into memory cache, connection pools, system swap...
• On the other hand, completely disabling the caches (when available) will produce an unrealistically
poor performance.
Testing load balancers

Load balancers can use the client IP address to balance the load over several servers. If all Virtual Users
are using the same IP address (default setting), the total load will be sent to a single server.
463
Best Practices
To obtain a realistic load, use NeoLoad's IP spoofing function.
Simulating actual user bandwidth

A user connecting at 100Mbps through a local network and a user connecting with a dial-up modem at
56kbps do not load the server and bandwidth in the same way.
Use the Population bandwidth setting to realistically simulate the users' connection speeds.
Tips
• After a re-start, don't hesitate to "warm up" the server with a few calls before generating a sudden, high
load which, in addition to being unrealistic, may cause the server to crash. Sending a short, light load
beforehand allows certain resources, such as connection pools or thread pools, to be pre-allocated.
NeoLoad allows the user to gradually spread the initial load using a start-up policy. For example, you
can choose to start your 1000 Virtual Users over a two-minute period.
• Run the test for a significant length of time in order to iron out any outliers.
• Make sure the Load Generators are not overloaded; CPU and memory usage are displayed in real time
throughout the test.
Various settings also may be changed, such as the number of sockets a machine may simultaneously
open to the server, or the memory allocated to the Load Generator. Please see the Troubleshooting Guide.
Making your Results Talk

Producing informative results
Validating key pages
It is important to check that the server response is valid under load. This is to make sure not only that the
scenario works as expected, but also that the load imposed does not cause errors in the application
NeoLoad automatically detects requests containing errors, in particular using the HTTP response code.
For example, NeoLoad will log a request error if the response contains '500 internal error'. However, many
web applications do not return the appropriate HTTP error code when handling an error, which means that
for these, NeoLoad cannot automatically detect the fault.
These cases must be processed individually by checking the validity of the content returned by the server
at key points within the application. This may entail checking for the presence of an expected text, for
example "The operation was successful", or making sure the response does not contain "Error".
To define a container value:
1. In the Virtual User profiles, click on the request whose server response requires validating.
2. Click on the "Validation..." button underneath, to the right.
3. Add a Validation for the content.
4. Select a validation method: contains or does not contain a simple text, or use a regular expression.
Once the test is finished, select the requests containing errors, or those where the validation failed, in the
errors panel. The content of the corresponding server response may then be analyzed to determine the
cause of the problem.
464
Best Practices
Note that validation uses up resources (CPU, memory) on the Load generator, and that it is usually wiser
to restrict its use to testing key pages only (for example, those that provide access to a database, or those
more likely to produce errors).
Beginning with low volumes

Proceed step by step:
• Use the Check function to validate the scenario for a Virtual User type. This will play the Virtual User
once, displaying the details of the sent request and the server response to each HTTP request.
• Begin with a short test and a light load. Correct any application errors occurring under the light load
before carrying out tests using heavier loads.
Stopping Virtual Users containing errors

When a Virtual User receives an error, it should normally stop running. If this does not happen, it could
continue playing requests that have no meaning. For example, if the user login fails, there is little point
sending further browsing or search requests to the application as it will only distort the response time
statistics for those pages.
Each Virtual User type may be configured to stop running in case of error or failed assertion.
Using Containers
Each transaction (registration, on-line purchase...) may be composed of several web pages. Statistics may
be obtained by transaction by grouping these pages in a Container.
Configuring monitors
NeoLoad allows you to retrieve performance data from most server infrastructures using monitors.
Configure monitors on all your infrastructure's key servers to monitor: CPU, memory, hard disk and
network usage on the web, application and database servers. See Chapter 7, Monitors.
Using results
Comparing results
An efficient way to highlight the performance variations between two sets of test results is to plot the
statistics for a same item (page, request, Container) in both tests simultaneously.
This provides a visual comparison of the application's behavior under different scenarios, or further to its
modification (e.g. update or optimization).
Using filters
An efficient way to pinpoint performance problems is to filter a test's results. The aim is to limit the test
statistics to the items (request, page, container, Virtual User, Population..) that are showing the problems.
For example, you may narrow down the statistics to a specified time period during the test run; this will
display the statistics as if the test had been carried out over that time period only.
Interpreting the advanced statistics

NeoLoad provides two advanced statistics:
465
Best Practices
• Standard deviation - allows the variation in values to be measured, compared to the average. A high
standard deviation indicates that response times vary widely, whereas a low standard variation is a sign
that response times are consistent and even.
• Average 90% - calculated by removing the highest and lowest 5% of values. This eliminates any outliers
and produces values that are close to those that will be obtained by most end users.
Correlating statistics and monitors

The statistics that show anomalies, such as a significant rise in response times or the occurrence of errors,
can be correlated with the variations in the readings obtained by certain performance monitors.
These correlations will usually provide an explanation for the performance slowdown and give a clue to
the main cause of the problem, be it merely a server setting or the overload of one of the main resources
(memory for example).
Managing test results

After multiple test runs, the volume of data can become difficult to manage. It is important therefore to
add a short description to each test prior to its running. This description is included in each test summary
and the reports generated.
The Results Manager allows the user to delete the results of a previous test session or use them to generate
a report (XML, HTML, PDF).
466
Chapter 13. Heavy Load Testing Guide
Introduction
NeoLoad assists you in building quality Web applications that offer high performance and scalability and
that are far more likely to be used and appreciated than applications that are buggy and slow. However,
building even the best software still requires that your application be tested under heavy loads (regardless
of the specific goals you are pursuing for your application - load tests or stress tests). A heavy load is
generally considered as simulating more than 1,000 users.
The following sections cover the best practices and recommendations for simulating heavy loads on the
application being load tested. Heavy load testing means that you will be putting stress on your testing
environment, so the load level attainable depends on how capable and how well tuned your testing
environment is. Obviously, the testing environment includes NeoLoad, but it also includes network and
other resources such as memory and CPU. The better your testing environment and tools are optimized,
the heavier the load you will be able to simulate.
Most importantly, keep in mind that testing your application under a heavy load only makes sense if all
basic scenarios are effective and your application works under a "normal" load, or at least a light load.
The main tuning and configuration points involved in improving your testing environment's capacity
are divided into the four following topics: NeoLoad scenarios, NeoLoad load generators, the NeoLoad
controller and finally the network.
The first two sections (NeoLoad scenarios and NeoLoad load generators) include best practices and
guidance that mostly refer to elements of NeoLoad's internal configuration. The latter two on the other
hand, pertain more to environment elements.
NeoLoad Scenarios
NeoLoad scenarios are the first place to look for time-consuming mechanisms that can interfere in
achieving heavy loads.
Minimize the Number of Validations

The validations you have defined in your scenarios not only make sure that scenarios work as expected,
but also that the load imposed by your test does not cause errors in the application. Therefore, scenario
validation is definitely something you do not want to overlook when testing your application with heavy
loads. However, validation is resource-hungry (for both CPU and memory), so you need to find a trade off
between comprehensive results validation and excessive resource consumption. To achieve this balance,
we recommend that, for heavy load testing, you restrict validation to key pages only (for example, those
that provide access to a database, or those more likely to produce errors).
A good practice includes setting up numerous, fine-grained validations during the first phase of your testing
process. Once you have acquired reasonable confidence in your application, and during the heavy load test
phase, you can restrict validations to those strictly necessary.
Avoid Validations and Extractions on Bulky Inputs

This recommendation complements the previous, more general recommendation on minimizing
validations. Both validation and variable extraction mechanisms are greedy resource consumers. This is
all the more true when the response or header they work on is bulky (a response that is larger than 100K).
467
Heavy Load Testing Guide
Avoid, therefore, including validations and variable extractions, particularly when they use bulky inputs.
In some situations, either validation or variable extraction is inevitable, so in that case at least make sure
the technique you are using is optimized. Refer to the following sections to get an idea of applicable
optimizations.
Optimize Regular Expressions

Optimizing regular expression is a subject on its own. This section will not deal with the art of optimizing
regular expressions but will rather emphasize the fact that, if regular expressions are powerful tools,
they are often the cause of performance issues. Most of the time, regular slowly-running expressions can
be dramatically improved when optimized for efficiency. Optimizing regular expression centers around
controlling/minimizing backtracking and the number of steps it takes the regex engine to match or fail.
At its heart, the regex engine uses backtracking. Usually, there isn't just one way to apply a regular
expression on a given string, so the pattern-matching engine will try to exhaust all possibilities until
it declares failure. To better understand backtracking, consider the following example: The regular
expression is "sc(ored|ared|oring)x" The input string is "scared". First, the engine will look for "sc" and
find it immediately as the first two characters in the input string. It will then try to match "ored" starting
from the third character in the input string. That won't match, so it will go back to the third character and
try "ared". This will match, so it will go forward and try to match "x". Finding no match there, it will go
back again to the third character and search for "oring". This won't match either, and so it will go back to
the second character in the input string and try to search for another "sc". Upon reaching the end of the
input string, it will declare failure. An important part of optimizing a regular expression is minimizing the
amount of backtracking it does.
Due to backtracking, regular expressions encountered in real-world application scenarios can sometimes
take a long time to completely match. Worse, it takes much longer for the engine to declare that a regular
expression did not match an input string than it does to find a successful match. This is an important fact
to remember.
Understanding and optimizing greedy and reluctant quantifiers in a regular expression are essential. A
greedy quantifier such as "*" or "+" will first try to match as many characters as possible from an input
string, even if this means that the input string will not have sufficient characters left in it to match the rest
of the regular expression. If this happens, the greedy quantifier will backtrack, returning characters until
an overall match is found or until there are no more characters. A reluctant (or lazy) quantifier on the other
hand will first try to match as few characters in the input string as possible.
So, for example, say you want to optimize a sub-expression like ".*a". If the character a is located near
the end of the input string it is better to use the greedy quantifier "*". If the character is located near the
beginning of the input string it would be better to use the reluctant quantifier "*?" and change the sub-
expression to ".*?a".
For more details on how to write regular expressions, you can have a look at our quick reference guide
on regular expressions.
Optimize Extractions from XML Responses

Extracting data from XML responses is a CPU-intensive operation, particularly when working on large
amounts of data. Favor conventional variable extractors whenever possible.
Avoid Multiplication of Virtual Users

During load simulation, virtual user creation is a rather costly operation. Scenarios that include many short-
lived virtual users (accessing a single page for instance) will tend to spend more time creating virtual users
468
than actually simulating them. It is therefore preferable to artificially lengthen a virtual user's behavior (by
including a few loops for example) to minimize the overhead of virtual user creation.
Minimize the Use of JavaScript Actions

JavaScript actions included in virtual user behavior are CPU-intensive for the load generators. Minimizing
these actions, and in some cases altogether removing them (particularly for logging code), will make heavy
load tests all the more efficient. We also advise you to pay particular attention to the JavaScript code itself:
avoid nested loops, make sure code is optimized...
NeoLoad Controller
The NeoLoad controller orchestrates your test scenarios and is in charge of communicating with the load
generators and aggregating test results. Therefore, the controller needs a certain amount of memory and
CPU resources to carry out its duties. The following paragraphs detail specific points that should be taken
into account prior to heavy load testing.
Launch Scenarios with a Fixed Duration

During the testing phase, NeoLoad continuously aggregates and computes results. Defining tests with an
unlimited duration forces NeoLoad to store intermediate results during the test. This consumes both time
and resources; all the more so for heavy load tests. For these reasons, do not start your heavy load tests using
scenarios of unlimited duration. Instead, specify limited durations and use an iterative and incremental
approach in which you augment the total duration in several steps.
Monitor Using a Top-down Approach

Rather than monitoring the whole of your infrastructure at once, prefer a top-down approach by targeting
general metrics at first and then by refining those metrics when you have more precisely identified the
source of the problem. This will avoid NeoLoad having to manage large amounts of non-significant
monitoring data. For a first run targeting a heavy load, the default monitor configuration defined by
NeoLoad is usually adequate .
Avoid Debug Mode

NeoLoad version 3.0 (and upward) also provides a debug mode that should be avoided for heavy load
testing.
Warm Up Your Application Server

Heavy loads are best achieved by gradually increasing user load. Rather than applying a sudden, large load
(which, other than being unrealistic, will probably cause your server to crash), sending a short, light load
at the beginning of the scenario allows certain resources, such as connection pools or thread pools, to be
allocated for the first time. A good idea, therefore, is to start the virtual users of a population over a defined
period of time rather than starting all the users simultaneously. This setting is accessible in Runtime view,
by clicking the Advanced button for the selected population in the runtime policy settings dialog box.
Plan for Large Amounts of Memory for the NeoLoad

Controller
Aggregating results is a memory-consuming task for the NeoLoad controller, so plan for a JVM that will
provide the controller with a large enough memory allocation.
469
Defining memory size, specifically the heap size of the Java Virtual Machine, is done by
modifying the two files <NeoLoad>/bin/NeoLoadGUI.vmoptions and <NeoLoad>/bin/
NeoLoadCmd.vmoptions, increasing the number of Mb in a VM argument. For example, to set the
heap size to 1024MB, define a VM argument with -Xmx1024m.
Reduce Error Management

In some situations, increasing memory as described in the previous point is still not sufficient. In these
cases, reducing memory consumption on both the controller and the load generators can be achieved by
tuning a property.
From NeoLoad version 3.0 and up, you can disable NeoLoad's default storing of the previous requests
of the requests that return errors. Once disabled, test results will only show the details of the request that
failed and not the request before. However, this will make it more difficult for you to diagnose problems.
Disabling this default behavior is best done once you have reasonable confidence in your application.
To change NeoLoad's default behavior, select the Preferences/Project Settings/Runtime
parameters menu item and disable the "Store previous response data on error" option.
Save your Projects Locally

The NeoLoad controller stores and keeps track of all the results of your tests using files stored on disk.
Load testing, particularly heavy load testing, can generate very large files. Minimize network traffic by
keeping those files on local disks rather than on network drives.
Adapt the Controller/Load Generator Time Limit to Your

Specific Project Requirements
When starting a load test, the NeoLoad controller sends data to each load generator you have defined.
This transmission time is limited to one minute, but can be configured to last longer if the size of your
test data requires more.
This is achieved by adding the value (in milliseconds) to the loadGenerator.init.touch.delay

property in the Runtime category of the <Controller>/conf/controller.properties
file. So for example, using loadGenerator.init.touch.delay=120000 , a maximum of two
minutes is allowed for sending the project.
NeoLoad Load Generators

The NeoLoad load generators are the components doing most of the hard work of simulating users.
Achieving heavy loads requires an execution environment that favors intensive computing.
Allocate Sufficient Memory to the Machines Hosting

Controllers and Load Generators
Heavy load tests, particularly those that include numerous virtual users, complex scenarios using regular
expressions and validation, will usually require the available memory to be increased on both the load
generators and the controller.
• For the controller, you will find the details of how to increase available memory in the section called
“Plan for Large Amounts of Memory for the NeoLoad Controller”.
• For the load generators, the procedure is as follows:
470
1. Edit the <loadgenerator>/conf/agent.properties file
2. Edit the lg.launcher.vm.parameters property in the LoadGenerator category to set the

new limit in Mb.
3. For example: lg.launcher.vm.parameters=-Xmx512m sets the limit at 512Mb.
4. If you are working on a stand-alone load generator, restart the load generator process or service. If
it's a load generator integrated into the controller, stop and then re-start NeoLoad.
You must make sure that physical memory on the machines hosting controllers and load generators are
always large enough for the JVM memory never to be swapped by the operating system. This means that
the physical memory of your machine must be larger than the heap size defined for your JVM. For certain
specific environments (LG for instance) setting large values for the -Xmx option interferes with the space
allocated to threads, so the size of the heap must leave enough space for thread allocation.
Generally, prefer 64-bit multiprocessor environments. Neotys provides 64-bit versions of its load generator
and load generator code is optimal on multi-core processors. It all depends of course on how heavy your
test loads need to be. Keep in mind that a 32-bit application cannot use more than 1.5 Gb of memory. If your
tests requires more than 2 Gb you'll need a 64-bit machine. Also keep in mind that a 64-bit load generator
will consume roughly 25% more memory than a 32-bit configuration to manage the address space.
In rare cases where memory problems persist even after having increased the allocated memory, the Neotys
support teams will help you fine-tune specific configuration items. This will usually include defining the
native stack size (-Xss JVM argument) and the garbage collector settings.
Make Sure the Machines Running the Generators are

Adequately Dimensioned
The NeoLoad generator's code is optimized for multi-core and multiprocessor environments. For
example, if you have a machine with four cores, it's vital to make sure the rest of the machine is adequately
dimensioned in order to properly use the available CPU capacity. Regarding memory, 1 Gb per core is a
good compromise; therefore in our case, 4 Gb of allocated memory would be ideal. We need to add to that
a 64-bit operating system (to be able to use more than 1.5 Gb of memory), which makes 6 Gb of physical
memory. In the case of network adapters, a good compromise is to have one adapter for two cores
For a four-core machine therefore, an appropriate set-up would be 6 Gb physical memory, a 64-bit
operating system, 4 Gb memory allocated to the NeoLoad generator and two network adapters.
Caution when using virtual environments

When testing under heavy loads, CPU, memory and network resources may be severely tested. We strongly
advise that a platform administrator be present during these tests to modify the load generators virtual
machines' configuration if required. We also advise you to apply all patches available for the virtualization
software prior to testing.
Network Tuning and Configuration

The following section enumerates rules that you should follow when deploying and organizing your heavy
load test infrastructure. They all refer to an ideal situation that, depending on your means and objectives,
is not always realistic. But the closest you are to that situation, the more effective your heavy load testing
will be.
471
Increase the Number of Simultaneously Opened Sockets

For heavy load testing, the NeoLoad generators will need to open a large number of sockets. Make sure
that the number of sockets allowed by your operating system is adequate. Refer to our troubleshooting
guide for more details.
Use Several Network Cards for Load Generators

An efficient way to increase the load generators' performance is to distribute the generated requests over
several network adapters. Once the adapters have been installed on the machine hosting the load generator,
you simply need to select the adapters in the associated load generator's advanced setting to complete
their configuration. The NeoLoad load generator distributes the load evenly across the installed network
adapters.
Distribute NeoLoad Communication Channels Over

Different Networks
During the test phase NeoLoad conveys three distinct types of information: Scenarios are dispatched from
the controller to the load generators (scenario distribution), scenarios are actually played to the application
servers (load generation) and finally, monitoring information is sent back to the controller. Separating those
three information channels on distinct networks achieves the most efficient network setup. The following
figure shows this ideal network configuration.
To obtain a good trade-off between infrastructure costs and efficiency, you can at least separate the load
generation network from the monitoring network.
As seen in the above figure, keeping load generators physically close to the application servers will
improve network performance. For the same reasons, it's a good idea to keep the controller close to the
load generators. Also avoid having a firewall between load generators and your application servers.
Prefer a "Server" Tagged Operating System for your

Application Servers
Server tagged operating systems are designed and configured to efficiently manage server-oriented tasks.
They should be the preferred choice for your application servers.
472
Part IV. Tutorials, F.A.Q
and Troubleshooting Guide
Table of Contents
14. F.A.Q ...................................................................................................................... 475
General .................................................................................................................. 475
Design ................................................................................................................... 479
Runtime ................................................................................................................. 482
Analysis ................................................................................................................ 485
Errors .................................................................................................................... 485
15. Troubleshooting Guide ................................................................................................ 487
16. Tutorials ................................................................................................................... 490
Introduction ............................................................................................................ 490
Design - General ..................................................................................................... 490
Creating Business Transactions .......................................................................... 490
Logging in With Multiple Accounts Using a CSV File ........................................... 496
Creating Realistic Populations ........................................................................... 513
Validating a Server Response ............................................................................ 514
Executing Java Code ....................................................................................... 522
Design - Dynamic Parameters ................................................................................... 526
Choosing a Data Extraction Method ................................................................... 526
Handling an Application's Dynamic Parameters .................................................... 528
Creating a Variable Extractor ............................................................................ 544
Submit a Form from the Previous Request ........................................................... 557
Follow a link from the previous request .............................................................. 563
Using Framework Parameters to Automatically Search for Dynamic Parameters .......... 570
Design - Technologies ............................................................................................. 576
SOAP: Testing Web Services ............................................................................ 576
Adobe Flex/AMF: Handling External Libraries ..................................................... 601
Adobe Flex/AMF: Handling Polling and Streaming ............................................... 607
Adobe RTMP : Handling External Libraries ......................................................... 623
Google Web Toolkit: Managing External Libraries ................................................ 628
Java Serialization: Handling External Libraries ..................................................... 634
Oracle Forms: Designing a Scenario with Iterations ............................................... 639
Analysis ................................................................................................................ 648
Analyzing Errors in the Errors Panel .................................................................. 648
Comparing Several Test Results ........................................................................ 656
Miscellaneous Items ................................................................................................ 657
Monitoring an Application Server or Database ...................................................... 657
Using Additional Load Generators ..................................................................... 662
Scheduling a Test ............................................................................................ 666
474
Chapter 14. F.A.Q
General
General Questions
Q: Can NeoLoad carry out functional tests?
A: Although NeoLoad is not a tool for functional testing, it can carry out checks on content returned
by the server. Validations using regular expression-based content assertions allow you to perform
basic functional tests.
Q: Is NeoLoad an Open Source project?
A: No, NeoLoad is commercial software.
Q: How do NeoLoad licenses work?
A: Neotys offers different types of NeoLoad software license to suit the customer's specific usage
requirements. Each license key gives access to the controller and defines the number of simulated
users and monitors allowed. Load generators are not covered by the license, so you can install as
many of these as you wish.
The standard NeoLoad license allows the controller to be installed on one single machine. The end
user may purchase either a permanent license or a leased license.
There is also the floating license option, which allows you to use the same license for several
machines using a license server (one simultaneous user per license). The license server can manage
several license keys, thereby allowing several simultaneous users.
A service provider's license is also available.
Contact <sales@neotys.com> for more details on available licenses.
Q: Can I use NeoLoad on more than one workstation?
A: The standard NeoLoad license allows you to install a single controller and as many load generators
as you wish to generate the required load. You may not use more than one controller with each
standard license.
A floating license allows you to install several controllers on different machines and to launch one
controller for each floating license.
Q: How do I install a license key?
A: Install a standard NeoLoad license key as follows:
Installing a license key
1. Open the license management panel via the "Help / License management" menu item.
2. Select the "Use a license file" option in the "License configuration" section.
3. Click the "Enter a license key" button.
Q: How do I transfer a license between workstations?
475
F.A.Q
A: A standard license may be transferred from one workstation to another. This operation de-activates
the key on the first machine, making NeoLoad inoperative with that key on that machine.
The procedure is as follows:
Transferring a license key
1. Launch the License Key Activation Wizard via the "Help / Activate license
key..." menu item.
2. Select "Transfer key to another machine"
3. NeoLoad generates a de-activation file named "license-inactivation.req".
4. This file must be e-mailed to Neotys at <<activation@neotys.com>>.
5. You will receive a confirmation e-mail from Neotys to say that the key has been de-activated
for that machine.
6. You may now use your license on another machine.
See the section called “License Key Management”.
Q: How many virtual users can a load generator generate?
A: This will depend on the application tested, the scenario and its parameters, particularly the think
time between pages: a load generator can generate approximately twice as heavy a load with a think
time of two seconds than with a think time of one second.
Likewise, generating a load using HTTPS (SSL) and using modules such as Flex, GWT, Oracle
Forms, Java Serialization and RTMP use up more machine resources than with HTTP.
As an example, a Pentium IV 2.4GHz can generate up to 1500 Hits/sec. A load generator typically
can generate between 500 and 1500 users on a standard application.
It should be noted that the NeoLoad controller can use as many load generators as is required to
generate the number of users specified in the license, at no additional cost.
Q: How do I install extra load generators?
A: To carry out tests using heavy loads, it may be necessary to install a load generator on another
machine.
The license does not limit you in the number of load generators you can install.
The installation may be carried out using the special load generator installer. Several versions are
available according to the machine's platform.
The program may be downloaded from the Neotys web site.
This dedicated version of the load generator does not require a license key to be installed. The
program installs automatically via the NeoLoad agent, which detects and controls the load generator
from a NeoLoad controller.
Q: Can I use the controller and load generators with a firewall?
A: Yes. See the section called “Using a Firewall Between the Controller and Load Generator” for further
information.
476
F.A.Q
Q: Which web servers is NeoLoad compatible with?
A: It doesn't matter which web or application server is used. NeoLoad lets you test any HTTP
application: ASP, .Net, J2EE, PHP etc.
Q: Does NeoLoad support Ajax?
A: Yes. NeoLoad records all HTTP requests.
Applications using Ajax send HTTP requests to the web servers; NeoLoad will create an HTTP page
containing the request for each action.
You will then be able to vary this request just like any other request and to verify the server response.
Q: Which authentication methods are supported?
A: NeoLoad supports Basic, Digest, NTLM, Kerberos and form-based authentication.
Q: Does NeoLoad support SSL?
A: Yes. NeoLoad can record HTTPS requests and play them back.
What's more, NeoLoad also supports client certificate authentication. It should be noted that the
browser generates a security alert on recording an SSL site. This is normal; ignore the alerts and
continue browsing normally.
Q: Does NeoLoad support ActiveX components?
A: NeoLoad records and plays back all HTTP traffic between the browser and web server.
NeoLoad therefore can simulate client-side component activity, such as an ActiveX component, as
long as communication with the server is via the HTTP protocol.
If the component send binary data, NeoLoad will only be able to play back what has been recorded,
unmodified. If this data contains session ID data or other parameters requiring dynamic replacement,
the test will not work.
Q: How do I use NeoLoad with a proxy server?
A: NeoLoad can connect to a server via a proxy. To configure a proxy :
1. Select the "Edit / Preferences" menu item.
2. Go to the Proxy section
The configuration will be used for both recording and playback.
Do not confuse this proxy with NeoLoad's internal recording proxy. During the recording, the
browser sends the requests to the NeoLoad recording proxy; NeoLoad then redirects these requests
to the server, either directly or via a proxy, depending on the above settings.
For further details, see the section called “Recording a Test Scenario”
Q: Which monitors are available in NeoLoad?
A: NeoLoad can monitor system information servers without having to install any agents. The protocols
used are: JMX for Java application servers, Telnet/SSH for Unix systems, Perfmon for Windows
servers etc.
477
F.A.Q
Here is a non-exhaustive list of available monitors:
• HTTP. Apache or other HTTP server
• IIS. Supports all versions all Microsoft IIS. Uses Windows Perfmon.
• .Net. Supports .Net and ASP applications.
• BEA WebLogic. Supports BEA WebLogic 8.x, 9.x and 10.x
• IBM WebSphere. Supports WebSphere 6.0, 6.1 and 7.0
• JBOSS. From JBOSS version 4.0 up
• Jonas. From version 3.2 up
• Tomcat. Supports Tomcat 5.5 / 6.0
• Oracle Application Server. From versions 9.x up
• GlassFish. Supports all versions. Certain counters may not be available for versions 2.x and
earlier.
• SAP NetWeaver. From version 7.1.x up
• LiveCycle Data Services. From version 2.6 up
• RSTAT. Allows monitoring of Unix and Linux systems
• Linux. Uses Telnet or SSH
• Solaris. Uses Telnet or SSH
• HP-UX. Uses Telnet or SSH
• AIX. Uses Telnet or SSH
• Windows. Uses Windows Perfmon
• MySQL. Uses a JDBC connection. Supported versions: 4.0, 4.1, 5.x and 6.0
• SQL Server. Uses Windows Perfmon. All versions are supported.
• Oracle. Uses a JDBC connection. Supported versions: 8i, 9i and 10g
• DB2. From version 8.1 up
• PostgreSQL. From version 6 up
For further details, see Chapter 7, Monitors
Q: What language does NeoLoad use for its scripts, and are they user-accessible?
A: NeoLoad "scripts" can only be designed via the GUI, which provides conditions, loops and
other programming structures. JavaScript may be inserted for more advanced uses, such as password
encryption.
478
F.A.Q
Design
Designing a test
Q: How do I configure a scenario?
A: When recording one of your application's features, NeoLoad creates a virtual user containing all
the recorded actions.
You may change the virtual user's behavior by adding, editing or deleting actions.
You may also build up your virtual user by adding requests from various other recordings. NeoLoad
allows you to add actions, such as loops, delays, condition sets etc. easily.
Once your virtual users have been created, you need to create a population of virtual users. You may
have several types of virtual user in a same population.
Next, in the "Runtime" tab, you need to define a test scenario, which will include the populations
to use, the load policy (constant, ramp-up or peak) and other options such as the think time and the
various monitors.
It only remains to run the test.
For further details, see Chapter 10, Design User Guide
Q: Why doesn't the virtual user behave as expected?
A: If, during playback, the virtual user behaves in an unexpected manner (no record created in the
database) or contains errors, it's more than likely that some requests are being replayed with faulty
parameters.
1. Find the faulty request:
NeoLoad detects an error when the response contains an HTTP error code. If the page returned
by the server contains the code 200, NeoLoad will not detect the error. To be able to detect it,
you must add assertions or manually check which pages are returned during the virtual user
validation process (use the "Open in browser" button). For more details on using assertions,
see the section called “Validating a Server Response”.
2. Find the parameter that needs changing
Usually, the parameters to be changed are ID's. You can repeat the recording, for example, and
compare the requests to see which ID's differ.
3. Replace the appropriate value
To retrieve a variable, use a variable extractor. Next, replace the parameter with the variable
created.
Failure to handle a dynamic parameter causes errors. See the section called “Handling an
Application's Dynamic Parameters”.
Generally speaking, you may need to extract and replace some data. See the section called “Creating
a Variable Extractor”.
Q: Why does my transaction replay incorrectly or contains errors?
479
F.A.Q
A: See the question "Why doesn't the virtual user behave as expected?".
Q: How does NeoLoad manage cookies?
A: NeoLoad automatically manages any cookies returned by the server during the test.
Cookies may also be defined when configuring the request settings.
Cookies generated by the browser using script must be managed manually (extraction/replacement
of variables or JavaScript code).
Q: How can I have different simulated actions with several virtual users?
A: NeoLoad allows you to design complex Scenarios in which different users simulate different actions
(for example, one user will browse a web site, while another carries out on-line purchases on the
same site).
All you need to do this is to create several types of virtual user and to group them within a population,
specifying the percentage of each type of user.
You'll find a more detailed explanation in the documentation
Q: How can I vary the users?
A: NeoLoad uses variables to simulate this type of behavior. To use a .csv file containing different login
accounts, see the the section called “Logging in With Multiple Accounts Using a CSV File” section
You may also download the Flash demo [http://www.neotys.com/load-testing-tool/demo.html] from

our website
Q: How do I validate the result of a request?
A: NeoLoad automatically detects requests containing errors using the HTTP return code notably.
For example, a request that returns '500 Internal Error' will be marked as an error by NeoLoad.
However, many web applications do not return an appropriate HTTP error code when managing
their errors, which means that NeoLoad cannot automatically detect the problem . Consequently,
management is on a case by case basis, verifying the validity of the content returned by the server at
key points in the application. For example, you might want to check for the presence of an expected
text "The operation was successfully completed" or check that the response does not contain the
word "Error".
To validate the content of a server response:
1. In the "Virtual Users" tab, click on the request whose response needs to be validated.
2. Click on the "Validation..." button bottom right.
3. Add a validation for the content.
4. Select a validation mode: search for presence or absence of a simple text, or use a regular
expression.
At the end of the test, select the requests containing errors or for which the validation failed in the
Errors panel, then analyze the content of the corresponding server's response to work out the reason
for the problem. You can add other validation types, such as size of the response or its duration.
480
F.A.Q
For further details, see the the section called “Validating a Server Response” section
Q: Why use a variable extractor?
A: Certain applications use dynamic parameters to manage sessions.
The parameter is created by the server and it changes each time the scenario is run. To be able to
simulate this behavior perfectly, the dynamic parameter returned by the server needs to be extracted
(usually within a hidden form field or a link) and replaced in the following requests.
The extraction is done using a variable extractor. Select the request, click on the "Advanced" button,
then select "Variable extractor".
See the section called “Advanced Parameters” for more details on defining variable extractors.
See the section called “Creating a Variable Extractor”.
Q: How do I add a prefix or suffix to a random variable?
A: Create a random variable that corresponds to the variable part of the string to be generated. Then
use the following string structure: "product_${productID}".
Q: How do I transfer a project from one controller to another?
A: Just change the project's directory (<NeoLoad projects>/<Your Project>).
Q: How do I change the server for all the requests?
A: In the "Design" tab, change server by selecting it in the "Servers" section in virtual user profiles.
You need to edit the "Machine name" and, if need be, the "Port" fields for all the requests to
be redirected to the new address at the next runtime. You may also use the search/replace function.
For more details, see the section called “Search for a server in request definitions”.
Q: How do I carry out IP spoofing with NeoLoad?
A: For IP spoofing (using multiple IP addresses), you need to access an agent's configuration in the
"Runtime/Scenarios" tab and select the IP addresses to use during the test.
You must define the IP addresses on that load generator's network interface.
See the section called “Configure IP spoofing”
Q: Why doesn't my Internet connection work after recording with NeoLoad?
A: During recording, NeoLoad changes the browser's proxy parameters for the duration of the
recording. It's possible that a problem occurred at the end of the recording due to NeoLoad not
restoring the browser's initial settings. If this is the case, restore the proxy parameters in the browser's
options.
Q: Why does an NTLM authentication window appear during recording?
A: This pop-up window appears whenever the server uses NTLM authentication.
When navigating in the application normally (outside NeoLoad), the browser sends the encrypted
authentication information to the server transparently. The account used is the Windows account of
the logged-on user. When recording, NeoLoad asks for an account name so that it can record and
play back the authentication.
481
F.A.Q
Q: Why do I get an NL-LINKEXTRACTOR-02 error when using a link extractor?
A: NeoLoad's link extractor function allows you to extract a link from the last page played before the
extraction's definition. The NL-LINKEXTRACTOR-02 error signifies that the link or form could
not be extracted from the previous request. This generally indicates that there is a page inserted in
your scenario between the link to be extracted and the link extraction request. This can be the case
if, for example, your application includes frames. To make the link extractor work properly, you
must make sure that the request containing the link to be extracted is the one played immediately
before the extraction request. If the requests do not follow each other, you can either move them
within the virtual user, or use the variable extractor to find the dynamic value and insert it in the
request parameter (for details on advanced request configuration, see the section called “Advanced
Parameters”)
Q: How do I enable/disable the screenshots?
A: You need to change a key in the controller's configuration file.

The recorder.screenshot.enabled key in the GUI section of the
controller.properties file may have the value true or false. This feature is only
available if the controller is installed under Windows.
Q: How do I set up a test if my loading criteria is based on transactions per hour?
A: In this case, you still need to decide how many users you want to simulate. Then, you can set the
pace at which the transactions are executed by using the pacing function.
Let's say you want to generate 3000 "Login" transactions per hour using 1000 simultaneous virtual
users. This means that each virtual user must carry out 3 "Logins" every hour. That is to say, each
virtual user must execute a "Login" transaction every 20 minutes. To do this, just set a pacing of
20 minutes for the "Login" container.
See the section called “Containers” for more details on pacing.
Q: How do I specify the character encoding for the parameters in the query string?
A: The query string of requests contains only ASCII characters. Other characters are encoded using the
%XX notation, where XX is the character code for a given character encoding. For example, the
character LATIN CAPITAL LETTER A WITH GRAVE 'À' would be represented as "%C3%80"
using the 'utf-8' encoding or "%C0" using 'iso-8859-1'.
NeoLoad uses 'UTF-8' by default as specified by the RFC 3986. Nevertheless, the server may
expect a different encoding, typically 'iso-8859-1'. The encoding used by NeoLoad may be
changed in the <NeoLoad>/conf/controller.properties file by editing (or creating)
the [Runtime]http.querystring.encoding=UTF-8 key.
Runtime
Running a test
Q: How do I monitor a remote machine?
A: NeoLoad allows you to monitor different types of remote machine or server during a test.
To add monitors, see the section called “Creating and Configuring a Monitored Machine”.
Q: What are the errors in the global monitoring graph?
482
F.A.Q
A: NeoLoad displays the number of errors detected during the test in real time and at a set interval.
An error is detected whenever the HTTP code of a request response indicates an error or when an
assertion fails. In both cases, the request at the root of the problem will not be replayed. If several
assertions fail in the same request, only one error is counted.
Q: What is the total number of users launched?
A: During a test under a constant load using n virtual users, NeoLoad starts n virtual users. Each user
replays the pages and requests defined in the scenario and then "dies". NeoLoad then launches a
new virtual user in order to maintain the desired load. The total number of users launched is the
total number of users that ran the scenario during the test's duration. For example, for a 5 minute
test with a constant load of 10 users, supposing each iteration lasts for 1 minute, the total number
of users launched would be 50.
Q: Where are the log files stored?
A: NeoLoad stores its log files in a directory in the user profile. The user profile used is that of the
user who launched the program.
See the documentation for the location of log files.
Q: What does hit/sec mean?
A: The "hits/ sec" indicator shows the number of requests per second sent to the server. This
indicator allows you to find a system's limits. Usually, it should increase with the number of users.
If this indicator stops increasing, or decreases even though the number of users is increasing, it
probably means that the tested application's limits have been reached.
Q: What does TTFB mean?
A: This is an abbreviation of "Time To First Byte", the time in seconds before receiving the first byte
of the response. This is the time taken by the server to start sending its response, excluding the
download time. This indicator is sometimes useful in detecting network bottlenecks. If the TTFB is
short, but the response time long, it would indicate a network delay problem.
Q: Why can't the controller use one of the load generators?
A: The main cause of communication problems between the controller and a load generator is the
firewall. The the section called “Using a Firewall Between the Controller and Load Generator”
section details how to open the appropriate ports. Don't forget Windows XP/Vista/Seven's built-in
firewall.
If you can't resolve the problem, contact Neotys Support and include both the controller's and load
generator's log files. See the section called “Log Files”
Q: Why do I get a "BindException" error when starting a load generator or NeoLoad?
A: This error means that the load generator could not start because the TCP/IP communication port is
already in use. Another agent, or another instance of NeoLoad, is probably in the course of being
launched. If this is not the case, it means that another program is using the communication ports.
You must therefore change the NeoLoad ports by editing the following configuration files (in the
<Install_dir>/conf directory):
• controller.properties: [Network]agent.port
• agent.properties: [Network]agent.server.port
483
F.A.Q
To stop the agent, use the <NeoLoad>/bin/Agent -stop command. You may also use the Start
menu's "Shut down Agent" item.
Q: How do I configure a load generator when using a firewall?
A: If you're unable to connect a new load generator, either using auto-detect or by defining it manually,
the problem is usually a firewall.
Instructions on configuring NeoLoad to pass through firewalls can be found in the the section called
“Using a Firewall Between the Controller and Load Generator” section
Q: How do I configure a load generator's available memory?
A: If the load generator frequently uses more than 90% of the available memory during a test, it can
lead to errors such as NL-RUNTIME-XX in the test results. The details of these errors are shown
as "java.lang.OutOfMemoryError: Java heap space". The load generator is a Java program which,
by default, is configured to use a maximum of 384 Mb of memory. For extreme load tests, this limit
may be raised to 512 Mb or even 1024 Mb.
See the section called “Increasing Available Memory for Load Generators”
Q: Why is the CPU usage so high?
A: If you notice a very high CPU usage even though the number of virtual users remains small, it may be
that one of the regular expressions used in a variable extractor is too demanding. To find out which
regular expression is causing the problem, you can replay the scenario several times, taking out a
different regexp on each run until a normal CPU usage is restored. A very simple, downloadable
freeware program exists that can help you construct your regular expressions (http://www.weitz.de/
regex-coach/).
Q: How do I insert timeouts in the server responses?
A: You can define 2 types of timeout in NeoLoad :
1. Connection Timeout: waiting time when establishing a connection
2. Socket Timeout: waiting time when receiving data
These settings may be edited in the <NeoLoad>/conf/controller.properties, file in

the Runtime section.
You simply need to change the values for the runtime.connection.timeout and
runtime.so.timeout keys. The values are expressed in milliseconds (for example, 30000 for
30 sec.). Settings these key values to 0 will create infinite timeouts (default behavior if no values
inserted).
Q: How can I obtain more details on ASP.NET errors?
A: NeoLoad plays a request that causes an error on the server.
The error message will probably give the main cause of the problem (bad argument for example).
For security reasons, the ASP.NET default settings do not allow errors to be displayed.
To change the settings, you have to disable the "customErrors" mode, by editing the
Web.config configuration file thus:
484
F.A.Q
<configuration> <system.web> <customErrors mode="Off"/> </

system.web> </configuration>.
Then re-start the application server.
Analysis
Analyzing and reporting
Q: How do I analyze the results? (beginners)
A: NeoLoad allows you to measure your web application's performance levels. To check the
application's proper behavior under load, you might want to begin by:
1. Checking the response times for all pages and making sure they meet your performance
requirements
2. Checking that the number of errors is acceptable at the target loading
The following documents will help you better understand test performance results: the section called
“Making your Results Talk”, the section called “Producing a Realistic Test”, the section called
“Defining Objectives”
Q: How do I export a graph curve in image format?
A: Right-click on the curve to be exported, then select "Save as image..." to save the curve
in .png format.
Q: How do I export the raw test results?
A: NeoLoad can export the raw test results in .csv format. You may export the statistics for a URL,
page or container by clicking on the Export button in the Values tab. You may also export all the
raw data for several curves in a graph by clicking on the Export button in the Graphs tab. Not all
the test data may be exported.
Errors
Understanding errors
Q: Why doesn't my test stop when the "Stop user run when assertions fail" option is selected?
A: This option stops the virtual user, not the test currently being run. The halted user will be replaced
by a new user that will start the scenario from the beginning, in order to maintain the required load.
Q: My system has memory available, so why does NeoLoad say that all available memory is used?
A: The memory displayed in the Runtime panel refers to the Java heap, not to system memory.
To generate heavy loads, increase the memory available to the load generator (see the section called
“Increasing Available Memory for Load Generators”)
Q: When checking my virtual users, why do I get an NL-NETWORK-03 error?
A: The virtual user activity has been recorded correctly and you get an NL-NETWORK-03 error with
the message "Failed to connect to the server". This indicates that NeoLoad couldn't connect to the
485
F.A.Q
server when playing the scenario. If the error details are "java.net.ConnectException: Connection
timed out: connect", it probably means that the load generator is using an inappropriate network
interface. Check the load generator's settings in the "Runtime/Scenario" section to make sure that
the selected network interface allows connection to the web server. The most common causes of
other errors are:
• The server hasn't been launched or is running on a different port.
• A firewall or anti-spyware program is preventing NeoLoad accessing the server.
• Wrong proxy settings in NeoLoad: check the proxy parameters used to connect to the web server
in the NeoLoad preferences' "Proxy" section.
If the error is not due to one of these points, please carry out a short recording on a public Internet
web site, such as http://www.google.com, create a virtual user and check its validity with NeoLoad.
Then send the log files to Neotys Support (all the files in the <NeoLoad>/logs directory).
Q: Why do some requests return a 404 error?
A: If, during the test, you get 404 errors on images or JavaScript or CSS files, it indicates that the files
are referenced and used in the HTML page, but are missing on the server.
The final user usually doesn't notice that these files are missing because the browser ignores this
type of error. Either make corrections to the application (add the missing files or delete the reference
to them in the web page), delete the request from the virtual user or set the option to smart-ignore
404 error codes: see the section called “Error handling”.
Q: What is an NL-REDIRECT-03?
A: This means that NeoLoad couldn't follow the redirect directive in the previous request (302 Moved
Temporarily). The previous request did not issue a redirect (not 302 status).
The request is an "HTTP Redirect" type within NeoLoad. This indicates that the request must follow
the redirect directive in the previous request.
The redirect is valid if the previous request contains HTTP return code 301, 302, 303 or 307, and
also contains a response header named "Location".
The NL-REDIRECT-03 error indicates that the previous request (the "referrer") did not contain
HTTP return code 301, 302, 303 or 307.
To begin with, check the validity of the request's referrer: Click on the request's "Advanced..."
button, then on the "Advanced parameters" tab.
Then investigate the reason(s) why the referrer didn't return the expected HTTP code.
Typically, the reason is that the request was played with an invalid parameter and generated an
HTTP 200 error code or generated an unexpected HTML content. See the question "Why doesn't
the virtual user behave as expected?".
Q: Why do my pages return "java.net.NoRouteToHostException"?
A: The "java.net.NoRouteToHostException: No route to host:connect" probably means that an

inappropriate network interface is being used.
Check the load generator's network parameters (see the section called “Load Generator Hosts”)
486
Chapter 15. Troubleshooting Guide
15.1. NeoLoad cannot connect to a load generator running on a Windows XP or Windows Vista host
From Service Pack 2 onwards, Windows XP features a firewall which is enabled by default. If the
load generator is run as a Windows service, Windows Firewall does not prompt the user to add the
program to the exceptions list. In this case, configure the firewall manually.
Another possible issue can be a controller-load generator connection timeout caused by an antivirus.
If the load generator machine's antivirus is scanning all NeoLoad's JAR files, this operation can
take a minute or more to complete. To resolve the problem, add JAR files (.jar extension) to the
antivirus's exclusion list.
15.2. When recording with SSL , I get a "Server Certificate Invalid" message
This is quite normal, since the recording proxy is placed between the browser and the web server.
Consequently, the recorder issues its own server certificate, which may trigger security alerts. Accept
the certificate and continue recording.
15.3. I'm getting a lot of NL-NETWORK-02 "BindException" errors.
This is usually because the load generator cannot create any more sockets on the system. The
system's TCP/IP settings therefore need to be modified. This is often the case with Windows
machines as the default settings do not allow large numbers of sockets to be created.
• Windows NT/2000/2003/XP/Vista
Add the following values to the \HKEY_LOCAL_MACHINE\SYSTEM

\CurrentControlSet\Services\Tcpip\Parameters key using regedit. Then re-
boot the machine hosting the load generator:
Name Value Type

MaxUserPort 65534 (REG_DWORD, decimal)
TcpTimedWaitDelay 30 (REG_DWORD, decimal)
You may also apply these changes to the registry automatically by running the
"WindowsNetworkTuning.reg" file in the <NeoLoad Home>/bin directory.
• Unix
Normally, this problem doesn't occur with Unix machines. However, you may check the
maximum number of files and network connections available per process with the ulimit -n
command. If this number is not high enough for the tests you wish to run, you may change the
value by using the ulimit -n <number> command. We recommend a value of 65534.
15.4. My pages return a java.net.NoRouteToHostException
The java.net.NoRouteToHostException: No route to host: connect error

is probably due to an incorrect network interface. Check your load generator's advanced network
settings.
15.5. The Internet URLs return an NL-HTTPERROR-02 error.
Your company's system may require a proxy to connect to the Internet. Please check the NeoLoad
proxy parameters in the "Proxy" section, "Edit/Preferences" panel.
487
Troubleshooting Guide
15.6. The load generator returns memory errors (java.lang.OutOfMemoryError)
Refer to the "Installation" chapter for details on increasing available memory for load generators.
15.7. The controller returns memory errors (java.lang.OutOfMemoryError)
Refer to the "Installation" chapter for details on increasing available memory for the controller.
15.8. The statistics calculation takes too long.
At the end of a test, NeoLoad displays a progress bar for the statistics calculation, indicating that the
standard deviation and average 90% are currently being calculated. These calculations are carried
out for each request and each page, which can be time consuming in the case of long tests.
• To stop the calculations immediately, click on the "Stop" button. Any values not calculated due
to the interruption are set to -1 and the results are displayed.
• To avoid this wait, these statistic calculations may be disabled: Edit the
controller.properties file in the conf directory. In the Results section, change the
compute.advanced.statistics key value from true to false. Then re-start NeoLoad for
the changes to take effect. The advanced statistics will now show a value of 0.
15.9. When checking a virtual user's validity, I get an NL-NETWORK-03 error.
The virtual user's activity has been correctly recorded and you get an NL-NETWORK-03 error with
the message: "Failed to connect to the server". This indicates that NeoLoad cannot
connect to the server when the scenario is played.
If the error details are "java.net.ConnectException: Connection timed out:

connect" for all the requests, then it would suggest that the load generator is using an incorrect
network interface. Edit the load generator's settings in the "Runtime/Scenario" section to
make sure the selected network interface allows access to the web server.
For other error details, typical causes are:
• The server is not running or is running on another port.
• A firewall or anti-spyware programmer is blocking NeoLoad's access to the server.
• Incorrect proxy settings within NeoLoad. In the "Proxy" section of the NeoLoad Preferences,
check the proxy settings used by NeoLoad to connect to the web server.
If the error is not caused by the above, please carry out a short recording on a public Internet site
such as www.google.com, then create a virtual user and check its validity using NeoLoad. Once
finished, please send all log files (all files in the <neoload>/logs directory) to the NeoLoad
support team.
15.10.The JBoss Application Server monitor test button always fails with the message "Please check
the host and port configuration" or returns an exception containing "Connection
refused to host: 127.0.0.1" with a JBoss Application Server running on a Linux box.
This is a well-known issue on some Linux distributions. Edit the /etc/hosts file.
If the file content looks like "127.0.0.1 myserver.server.com myserver

localhost localhost.localdomain", please update it using the following sample.
127.0.0.1 localhost localhost.localdomain
myipserver myserver.server.com myserver
488
Troubleshooting Guide
Restart your JBoss Application Server and try again.
15.11.When I configure the Windows server monitoring, the remote connection to my server is refused.
To access a remote machine, you need either to have authorized rights or to modify the remote
machine configuration. Authorized rights are provided to administrators and members of the
"Performance Monitor Users" Windows Server group.
Refer to the Reference guide for detailed information.
15.12.My Java applet recording is not working. It uses HTTPS to communicate with the web server.
To allow NeoLoad to capture the HTTPS requests, the browser's Java plug-in must be configured
to use the NeoLoad recording proxy as proxy server.
To configure this setting:
• In the configuration panel, open the Java settings

• Click on the General tab, then on the Network settings button.
• Choose Use the proxy server and configure localhost as the host name and the
NeoLoad proxy port (default is 8090).
• Validate this setting and restart your browser before recording your scenario.
15.13.I use Ubuntu Linux 8.10 and some windows in NeoLoad don't display properly or are empty.
Edit the bin/NeoLoadGUI file, adding the line "export AWT_TOOLKIT=MToolkit" to the
end of the other "export" commands towards the end of the file.
489
Chapter 16. Tutorials
Introduction
The NeoLoad tutorials provide you with a detailed look at specific topics. For more general help on broader
subjects, such as designing a virtual user, see Part III, “User guides”.
Design - General
Table of contents
Creating Business Transactions

Logging in With Multiple Accounts Using a CSV File
Creating Realistic Populations
Validating a Server Response
Executing Java Code
Creating Business Transactions

The main objectives when load testing your application are to obtain an accurate evaluation of performance
and to precisely identifying performance bottlenecks. To achieve these objectives, creating scenarios that
define realistic populations and realistically-behaving virtual users is essential. In addition, one technique
that will greatly help you to in refining your benchmarks is to use what are known in NeoLoad as Business
Transactions (or put more technically, Containers).
A business transaction is a set of related pages that achieve a consistent business interaction. A typical
example is the set of pages a user goes through to login to an application. The idea is to assemble those
pages into a container so that NeoLoad can produce precise time consumptions and statistics on those
pages as a whole. These containers will appear separately in test results making analysis easier. In our
login example, you would obtain statistics on the response times users experience from the moment they
start connecting to the application to the moment they're actually logged in.
The first step in using business transactions is to identify recurring behavior, especially behavior that
represents an important functionality in your application. Once this behavior pattern has been identified,
the corresponding pages must be assembled in a container, a Virtual User Container in NeoLoad parlance.
This tutorial details the steps involved in building these containers.
Virtual users are one of the main building blocks NeoLoad provides to create load test scenarios. Virtual
users assemble recorded HTML pages, populations group virtual users and, finally, a load test scenario
assembles populations. This tutorial will briefly describe the steps involved in building a virtual user that
has a container. It will also show the types of results obtained using this technique. For more details on
creating populations and running scenarios, see the reference guide.
Example Overview
We'll base our example on the JPetStore application, an on-line pet store web application.
The application provides typical merchant web site functionalities : creating an account, signing in,
browsing through pets, adding pets to a shopping cart, and finally checking out and purchasing what's
been added to the cart. We identify the purchasing phase as critical because it is resource greedy and time
consuming. We need and want detailed statistics on this phase.
490
Tutorials
We ignore the interactions concerning the actual choice of pets and their quantity, we are only interested
in the pages in which the client confirms and checks out what he or she has purchased. The following
screen shots depict those pages:
1. Whatever the client has ordered, the following page submits a form containing payment and billing
address information (/jpetstore/shop/newOrderForm.shtml):
2. The second step is a page prompting the client for confirmation of previously entered billing address
information (/jpetstore/shop/newOrder.shtml):
491
Tutorials
3. The final step is a page summing up payment, address and order details (/jpetstore/shop/
newOrder.shtml_1):
Building the Business Transaction when Recording

During the recording, the Recording Bar allows you to define business transactions (or containers).
Procedure 16.1. Creating a business transaction during the recording
1. Start the recording.
2. To begin a new business transaction, enter its name in the "Container" text field.
3. Carry out the actions relating to the business transaction in the browser.
4. To finish the business transaction, delete or replace the name in the "Container" text field.
5. To stop the recording, close the browser or click on the "Stop" button in the NeoLoad Recording
Toolbar.
492
Tutorials
Note
Only those business transactions at the virtual user root may be created using the Recording
Toolbar.
Building the Business Transaction after Recording

This section details the steps involved in creating a container (business transaction) relating to the above
pages.
1. Select Design mode
Click on the button.
2. Select the "Virtual Users" tab
3. Add a virtual user container
a. Adding a container to a virtual user
In the "Virtual Users" pane, select the last page in the virtual user (/jpetstore/shop/
newOrder.shtml_1) then right-click on the page. In the pop-up menu, select "Insert
after", then "Container".
Next, select the new container and rename it "Checkout".
b. Select the pages to add to the container
Select the pages to add to the container, then drag and drop the pages in the container.
Tip
You can select multiple pages by using a left click while holding the CONTROL or
SHIFT keys down.
493
Tutorials
In our example we have added the container as the last element of the virtual user. We have added to
the contents of the container the three HTML pages included in the order interaction:
1. /jpetstore/shop/newOrderForm.shtml : contains the payment details and the billing

address information,
2. /jpetstore/shop/newOrder.shtml: sums up order information and prompts the user for

the confirmation,
3. /jpetstore/shop/newOrder.shtml_1: presents the order confirmation.
We know that the interaction involved by these three pages includes possibly time consuming
processing such as account verification and order submission. This is where having fine grained
results on a particular container will become useful.
Building a Population and a Scenario

In our example we have created a population called Buyers containing the PetStore user. The
population as a whole represents a realistic projection of how the Pet Store application will be used.
The following screen shot shows how the population is configured using the PetStore virtual user in
Design mode:
In Runtime mode, a scenario called Scenario1 has been created and configured so that it only contains
the Buyers population:
494
Tutorials
Analyzing Business Transaction Results

This section describes where to analyze business transactions. The whole point of creating business
transactions is that NeoLoad explicitly identifies them and provides distinct results for each one.
Results Summary
After having launched the scenario in "Runtime" mode, the first place you will see results specific to
the container is in the "Results Summary" tab, which can be viewed in "Results" mode. A section
called "Containers" summarizes the statistics for all the containers used in the scenario. The summary
provides an overall view of a particular business transaction's (container's) behavior:
Results Values
The "Values" tab in "Results" mode gives more details on the business transaction. Select a particular
virtual user and choose the "Logical Actions" item in the "Filter" list. You can then select
the container representing the business transaction, in our case the Checkout container, as seen in
the following screen shot. You may now work with the various statistical elements to deepen your
understanding of the business transaction's behavior.
495
Tutorials
Results Graph
The "Graph" tab in "Results" mode also provides details on the business transaction. You can select
a particular virtual user and then select the container representing the business transaction, in our case the
Checkout container, as seen in the following screen shot.
Related Links
For more information on how to create realistic populations see the section called “Creating Realistic
Populations”.
For more information on how to analyze results, see the Reference Guide
Logging in With Multiple Accounts Using a CSV File

Using different accounts to login will let you achieve and simulate realistic behavior. This technique
ensures that no caching mechanisms are distorting load results. Multiple logins will also help you improve
the functional validation of your application.
Multiple logins can be set up:
496
Tutorials
1. manually, see the section called “Creating and Linking a CSV Variable to Login Information”, or
2. using a wizard, see the section called “Multiple Accounts Using the Post-Recording Wizard and a CSV
file”.
Both techniques are described here, the easiest and preferred one being the second, but understanding the
"manual way" will help you fully understand the "wizard way".
Creating and Linking a CSV Variable to Login Information

This procedure involves two distinct steps:
1. Creating and correctly configuring a variable that will take its values from a .CSV file.
2. Linking the variable to NeoLoad configuration elements so that the variable is used when logging in
is required.
When working "manually" with variables in NeoLoad, you must always first declare and define the
variable and then link it to the configuration elements.
Creating and Defining a CSV Variable
Declaring and using variables is the usual way of achieving dynamic behavior with NeoLoad. A variable
can be used in place of constant or static values for many configuration elements. In this example we will
use a File Variable, a variable that takes its values from a .CSV (Comma Separated Values) file. An
alternative would be to use a List Variable and explicitly define the values in the Variables dialog
box. We will leave this alternative aside in this example.
1. Open the Variable Edition dialog
Select the "Variables" item in the "Edit" menu.
2. Open the Variable Creation dialog
Click on the "New variable" button in the Variable Edition dialog.
3. Select the type of variable to create
Choose the File type.
497
Tutorials
4. Enter a name for the variable
Use a meaningful name for the variable. In our example we have decided to call our variable
account.
5. Browse and select a .CSV file
The dialog displays the first lines of the file so that you can check its contents. Our example supposes
that the file has been created beforehand and contains consistent values.
Our file, called accounts.csv, defines two columns: the first contains the login values, the second
contains the associated passwords. The account variable has therefore two values automatically
named account.col_0 and account.col_1. When access to the login values of the account
variable is required, we will use the ${account.col_0} expression. Similarly, when access to
the password values of the account variable is required, we will use the ${account.col_1}
expression.
Tip
Renaming column names . NeoLoad assigns default names to the columns of the CSV file.
In this case the names of the columns are col_0 and col_1 . Columns can be renamed by
clicking on the column header and entering a custom name.
6. Check the column separator
You can specify a column separator other than the default ";" character.
7. Define in what order the values of the variable will be used
Order can be sequential or random. Using random order can be relevant if, for instance, your
application's behavior varies depending on the access rights of the logged in user. Using random
order, in this case, will better approach a realistic situation. We choose to "Take the values
randomly".
Whether in sequential or random order, once all possible values of a variable have been used, NeoLoad
will repeatedly go through all the values again.
8. Define when a new value will be used
In our case, we want a new value to be used each time a virtual user logs in so we select the "For
each virtual user" option.
9. Close the Variables Creation dialog and test your variable
Once you have closed the Variables Creation dialog you can test the behavior of the
accounts variable by selecting the "Test" button in the Variables Edition dialog.
498
Tutorials
Testing is achieved by choosing different Actions and evaluating the current expression,
${account.col_0} in this case, by selecting the "Apply Action and Evaluate button".
In our example, choosing the "Change Virtual User" action will result in a new value for the
login column. The value is randomly chosen among the values of the login column. This is consistent
with the way we have defined the accounts variable: we want a new login value each time the
virtual user changes in the scenario. Testing with other actions, such as the "Change Page action",
will not change the value of the variable.
If you wanted to test the password value of the account variable, you would change the expression
to ${account.col_1}.
At this stage, the account variable is ready to be used and tested.
Link the CSV Variable to Login Information

This step involves different procedures depending on the type of authentication your server is using: Basic
authentication, NTLM authentication or Form based authentication.
Important
Required steps to link the CSV variable to login information are similar for the first two types
of authentication: basic and NTLM authentication both involve changing configuration elements
related to the server (The following section covers this topic). The third however, form based
authentication, involves changing configuration elements related to a particular form: See the
section called “Link the CSV Variable for Form Based Authentication” .
Link the CSV Variable for Basic and NTLM Authentication
1. Select NeoLoad's Design mode
Go to the "Design" part.
2. Select the server
Choose the "Virtual Users" tab and select the appropriate server element in the servers tree.
499
Tutorials
3. Link the account variable to the Login configuration element
a. In the "Authorizations" panel, click twice on the login column:
b. Select the "..." button to access the Variable Picker dialog.
c. Choose the ${account.col_0} expression. The first column of the account variable
contains login values.
500
Tutorials
Tip
Rather than using the Variable Picker, a faster alternative, once you have selected
the login column, is to delete the value and start typing ${. NeoLoad displays a pop
up listing all available variable values:
Using the down and up arrow keys and the ENTER key, you can select the appropriate
variable value.
In our example we suppose having already configured our server for Basic or NTLM
authentication. If this had not been the case, we would have added, prior to linking the
account variable, an authorization scheme by selecting the Add ... button and specifying a
Type and a Realm/Domain.
4. Link the account variable to the Password configuration element
This involves the same steps as linking to the Login configuration element: Selecting the
password column and changing the value to the ${account.col_1} expression.
Link the CSV Variable for Form Based Authentication
1. Select NeoLoad's Design mode
Go to the "Design" part.
2. Select the HTTP request in which the login takes place
In the "Virtual Users" tab, choose the virtual user, HTML page and HTTP request where the
actual login and Form based authentication takes place.
In our example:
• the record is VirtualUser,

• the HTTP page is /jpetstore/shop/signon.shtml,
501
Tutorials
• and the HTTP request is /jpetstore/shop/signon.shtml.
3. Link the account variable to the Login configuration element
The HTTP request, in our example, defines several request parameters. In this case, the two of interest
are the username and password request parameters. In your case, these request parameters are
probably named differently.
a. In the Definition panel, click twice on the Value column for the username request
parameter.
b. Select the "..." button to access the Variable Picker dialog.
c. Choose the ${account.col_0} expression. The first column of the account variable
contains login values.
502
Tutorials
Tip
Rather than using the Variable Picker, a faster alternative, once you have selected
the Value column, is to delete the value and start typing ${. NeoLoad displays a pop up
listing all available variable values:
Using the down and up arrow keys and the ENTER key, you can select the appropriate
variable value.
4. Link the account variable to the password configuration element
This involves the same steps as linking to the username request parameter element: Selecting
the Value column and, for the password request parameter, changing the value to the
${account.col_1} expression.
Multiple Accounts Using the Post-Recording Wizard and a CSV file

This section of the tutorial describes the steps you'll need to take to use multiple accounts based on a CSV
file for your load scenario. The steps described here are those you will take after having gone through the
Post-recording Wizard.
The Wizard does most of the job so these steps are simple and few. This is all the more true in comparison
to the "manual" procedure which entails declaring a variable and linking it to login elements in the
configuration. Refer to the first section of this How To to fully understand how using multiple accounts can
be achieved without using the Post-recording Wizard: the section called “Creating and Linking
a CSV Variable to Login Information”.
The steps you need to take boil down to correctly defining the contents of a CSV file. This section will
however precisely show you the login related elements that the wizard creates and configures. It will also
detail how these elements relate to each other. If you want detailed information or a better understanding
of the Post-recording Wizard itself refer to the section called “Post-Recording Wizard”.
Each time you record a set of interactions with your application, the Post-recording Wizard is
launched at the end of the recording. This wizard analyzes and pre-configures login elements for you.
Depending on the type of authentication your server is using, the wizard will create and configure different
elements:
503
Tutorials
1. For Basic authentication or NTLM authentication: the wizard automatically detects these authentication
policies and configures Authorization elements related to the server you are connecting to.
2. For Form based authentication: the wizard automatically detects the HTTP request that
authenticates to your server and configures elements related to that particular request.
Multiple Accounts with Basic or NTLM Authentication
The first part of this section goes through the steps of the Post-recording Wizard and describes
the elements related to Basic and NTLM authentication. In most situations the Wizard does the whole job
on its own and you just have to confirm what the Wizard has detected and decided. The second part of
this section details the configuration elements the Wizard has created and the information you will need
to provide.
We skip the first two steps of the Post-recording Wizard and concentrate on step 3. This is
where Basic and NTLM authentication information is used and can be configured through the Wizard.
Our example is based on Basic authentication but the NTLM authentication procedure is identical.
1. Post-recording WizardStep 3: Basic Authentication
The Wizard automatically detects that Basic authentication has been used. We indicate that multiple
accounts should be used by checking the "Use multiple accounts" option.
504
Tutorials
2. Post-recording Wizard: Defining the type of variable to use
The wizard needs to determine the type of variable used to store the multiple accounts. We choose
the CSV alternative by checking the "Use the accounts from a CSV file" option.
3. Post-recording Wizard: Defining the variable
To be able to replace the recorded parameters with dynamic values, we need to define the file-type
variable that will be used. This step in the wizard allows us to select the variable's parameters. Select
the CSV file to use by clicking on the "..." button. The first few values are displayed to check the
file's content.
Double-click on the column headers to change the names to more meaningful names.
505
Tutorials
The Value change policy selected by the wizard is for Each virtual user. This is
consistent with the behavior we are looking to create, since we want a new value to be used each time
a virtual user connects to the application.
4. Post-recording Wizard: Login configuration
In this last step, the wizard prompts us to specify which column to use for the login, which column
to use for the password and then recaps the created configuration. Here, it has created an Accounts
variable that has been assigned to the login and password authentication parameters. The
Accounts variable has two columns: the first column, ${Accounts.login}, must contain login
values; the second, ${Accounts.password}, must contain password values.
During the recording phase NeoLoad automatically detects Basic or NTLM Authentication and correctly
configures the Authorization elements of the server. As detailed previously, the Post-recording
Wizard configures and links Authorization elements to a variable. The following figure depicts such
a configuration:
In our example, our server uses Basic authentication. The wizard has detected this and has configured
the Authorization panel accordingly by adding a line with type, Realm/Domain, login and
password information. The login and password are both linked to values of a variable called
506
Tutorials
Accounts. More precisely, the login is linked to the ${Accounts.login} expression and the
password to the ${Accounts.password} expression.
Multiple Accounts with Form-Based Authentication
The first part of this section goes through the steps of the Post-recording Wizard and describes the
elements related to Form based authentication. In most situations the Wizard does the whole job on its own
and you just have to confirm what the Wizard has detected and decided. The second part of this section
details the configuration elements the Wizard has created and the information you will need to provide.
We skip the first two steps of the Post-recording Wizard and concentrate on step 3. This is where
form based authentication information is used and can be configured through the Wizard.
1. Post-recording WizardStep 3: Form Based Authentication
In our example, we check the accountBean form as being used for authentication. This basically
tells the wizard to look for HTTP authentication related parameters in the associated HTTP request.
507
Tutorials
2. Post-recording Wizard Defining the login field
The wizard automatically detects and identifies the username HTTP parameter as the login field
for the form based authentication.
3. Post-recording Wizard Defining the password field
508
Tutorials
The wizard automatically detects and identifies the password HTTP parameter as the password
field for the form based authentication.
4. Post-recording Wizard Defining multiple accounts
At this stage the wizard needs to determine whether you want to use multiple accounts to login. We
select the Use multiple accounts option accordingly.
509
Tutorials
5. Post-recording Wizard Selecting a CSV file based variable
The wizard now wants to determine if account information (login and password) should be read from
a CSV file, or be entered explicitly in the project configuration. We choose the Use the accounts
from a CSV file option.
510
Tutorials
6. Post-recording Wizard: Defining the CSV file-type variable
To be able to replace the recorded parameters with dynamic values, we need to define the file-type
variable that will be used. This step in the wizard allows us to select the variable's parameters. Select
the CSV file to use by clicking on the "..." button. The first few values are displayed to check the
file's content.
Double-click on the column headers to change the names to more meaningful names:
Accounts.login and Accounts.password.
The Value change policy selected by the wizard is for Each virtual user. This is
consistent with the behavior we are looking to create, since we want a new value to be used each time
a virtual user connects to the application.
511
Tutorials
7. Post-recording Wizard Step 4: Login configuration
In this last step, the wizard prompts us to specify which column to use for the login, which column
to use for the password and then recaps the created configuration. Here, it has created an Accounts
variable that has been assigned to the login and password HTTP parameters. The Accounts
variable has two columns: the first column, ${Accounts.login}, must contain login values; the
second, ${Accounts.password}, must contain password values.
The Post-recording Wizard has also configured the HTTP request doing the authentication. In our example,
the configuration of the HTTP request associated with the accountBean form is as follows:
The username parameter is associated with the ${Accounts.login} expression and the password
parameter associated with the ${Accounts.password} expression. The Accounts variable is
automatically created and configured by the Post-recording Wizard. The ${Accounts.login} value
will be read from a CSV file and is expected to contain a login value. The ${Accounts.password}
value will be read from the same CSV file and is expected to contain a password value.
512
Tutorials
Creating Realistic Populations

To achieve realistic load scenarios and therefore relevant test results, populations must closely simulate
a set of real users connecting to your application. Including Virtual users that behave differently in a
population and finely tuning that population are therefore essential.
1. Define Virtual Users having different behaviors
Users connecting to your application will necessarily have different profiles each behaving
differently. The first step in achieving realistic scenarios is therefore to create different types of Virtual
Users and to include them in a population.
In the previous screen shot, our example population called RegularPopulation includes three
distinct types of users:
RegularUser. Represents a user that often uses our application but spends most of his or her time
just browsing through our catalog.
RegularBuyer. Represents a user that does some browsing too but actually places orders and
payments.
Administrator. Represents in house staff who can remotely administrate our application.
2. Finely tune your populations
a. Consistently Distribute Virtual Users
RegularUser. In our example, we have decided that this type of user represents 85% (55%
+ 30%) of the users of our application. This is usually based on statistics or at least consistent
forecasts of user distributions. We also split this type of user into two sets based on the type
of access they use. We estimate that 55% of the users will have a broadband access to our
application and that 30 % will only have limited access (512kbps download and 64kbps upload).
513
Tutorials
Important
The percentage used to define a distribution of Virtual Users in a population will be
interpreted when launching a load scenario using that population. For example, if the
load scenario defines a constant load policy with 100 users then 85 RegularUsers
will be launched, 55 of which will have broadband access and 30 of which will have
limited access.
RegularBuyer. This type of user represents 10% (5% + 5%) of the users accessing our
application : 5% of which have broadband access and another 5% that have limited access
Administrator. Finally we estimate that administrators represent 5% of the users of our

application.
b. Tune other settings
NeoLoad provides additional elements that can be configured per user. These include browser,
cookies and the number of HTTP connections that the browser will use to interact with the server.
Refer to the reference guide for further details.
Validating a Server Response

Problems or errors occurring during the execution of a test scenario will bias your results making them
partially or at worst completely unusable. It is therefore fundamental to make sure that errors occurring
during a scenario be clearly identified and traced. NeoLoad automatically identifies and reports HTTP
related errors or severe errors due to networking or application failures. However NeoLoad cannot identify
errors due to application logic, but provides a powerful validating mechanism that will let you locate
unexpected or erroneous behaviors. An application logic error can trigger chain reactions that could, in
the end, cause an HTTP error : catching application errors as soon as they appear will make it much easier
to understand and analyze the problem. The sooner an erroneous behavior is identified and traced, the
quicker the resolution will be. Because NeoLoad provides mechanisms to validate application behavior,
this technique can, to some extent, be used to achieve functional testing.
Finally, from a purely load testing point of view, it is also important to identify pages that are time costly,
we will see in this section how to define HTTP response that exceed a certain amount of time. This is
consistent with non functional requirements that are often expressed by users or clients and that you must
ensure.
NeoLoad's validations are expressed on a per HTTP response basis. The validation mechanism provides
the means to express conditions that must be met by the HTTP response resulting from a particular HTTP
request. NeoLoad provides three types of criteria with which validations can be expressed: time based
criteria, content size based criteria and finally criteria based an the contents of the response. This tutorial
describes how these criteria can be added and configured. It also points out how to test your validations
and where to configure NeoLoad's behavior when validations fail.
Adding Validations to an HTTP response

As an example, we will base this HowTo on the very simple HTML source code that follows
<HTML>
<BODY>
514
Tutorials
<H1>Order references</H1>
<P>
Thank you, your order has
been successfully submitted :
<B>#I45-020206-45RT347</B>
</P>
<BODY>
</HTML>
We want our validation to apply to the contents of the HTTP response making sure that an order identifier
has been correctly returned and also checking that the format of the order identifier is correct. Our second
validation will apply to a non functional requirement: confirming and placing the order is a resource greedy
and time consuming operation, we want to make sure the response time does not exceed 2 seconds.
The following procedure details the steps entailed in defining these validations:
1. Select the HTTP request for which the response will be validated
a.
Go to "Design" Mode by selecting the button.
b. Select the "Virtual Users" tab.
c. Unfold the appropriate HTML page node.
d. Select the HTTP request for which the response will be validated. In our case we choose the /
loadtest/validation request:
Note
An HTML page is most of the time composed of several HTTP requests (images, .css
files, etc). In our example the page only has one request and we will be validating the
response of that request.
e. Take a glance at the response
At this stage, and before going to the validation steps, it usually is a good idea to take a look at
the contents of the response we are intending to validate:
515
Tutorials
i.
Select the button.
ii. Select the "Response Contents:" tab. In our example, the following screen shot
depicts the contents of the HTTP response we want to validate:
As mentioned previously, we want to apply our validation to the presence and correctness
of the order identifier.
Tip
Searching through the contents: In our example the contents of the response is
simple and short but a realistic response could be much longer. You can search
for some particular text by right clicking in the contents panel and selecting the
"Search..." option or using the CONTROL + F shortcut keys. This will open
a search panel at the bottom of the dialog in which you can enter target text and
search for occurrences of that text.
We close the advanced dialog.
2. Open the Validation dialog
Select the button.
The Validation dialog present three panels, each defining one of the types of validation NeoLoad
provides: assertions on the duration, the length of the content and assertions on the content itself:
516
Tutorials
As described earlier these are the three criteria that NeoLoad provides to validate a response. In our
case we will leave the size criteria aside. This could be used to validate image contents for instance,
making sure the image returned has the required size.
At this stage we define the Duration criteria and enter 2000 ms. This is consistent with our
requirement.
Note
Duration is the amount of time between the moment the HTTP request is sent and the moment
the whole of the HTTP response is received.
The following steps involve adding contents validation:
a. Adding an assertion
Select the button in the "Reply Content" panel.
NeoLoad automatically adds an assertion, called assertion_1 in this case. An assertion

expresses a condition that must be met by the HTTP response.
Important
As we will see later we can tell NeoLoad to stop when this assertion fails. This behavior
is configured on the virtual user containing this HTTP request. NeoLoad will stop
executing those virtual users. In all cases, NeoLoad indicates, during the execution of
a load test, where and why an assertion has failed.
b. Defining the assertion
Choose the "contains the regexp:" option.
517
Tutorials
An assertion expresses a condition that must be met by the HTTP response. In our case the
contents we want to validate is dynamic: an order identifier generated for each order that has
been confirmed. We therefore choose the "contains the regexp:" option. The default
option "contains:" would have been sufficient had we looked for some constant text.
We will use a regular expression to identify the order identifier and make sure the identifier
is correctly constructed. Using regular expressions is NeoLoad's basic technique to match and
extract dynamic content.
c. Defining a regular expression
Select the button.
This opens the RegExp picker dialog. The dialog is divided into two parts, the first one
contains the contents of the HTTP response and the second part the regular expression you will
be defining to match part of the contents. While you enter the regular expression or part of
it, NeoLoad dynamically tries to match the expression you've type in with the contents of the
response. This makes it easy to test the regular expression you are defining.
518
Tutorials
In our example we want to match the order id. This identifier is made of three distinct parts:
1. A prefix, such as #I45, always starting with the character "#" sign and followed by a
sequence of exactly three letters or digits.
We use the #(.{3}) regular expression to match this part.
The parenthesis are used for grouping an expression. The dot character matches any character
other than the new line character. The {3} expression indicates that there are exactly three
characters other than the new line character.
2. A middle part, such as -020206, starting with a dash and followed by a sequence of exactly
six digits.
We use the -(\d{6}) regular expression to match this part.
The \d matches any digit and the {6} says there are exactly 6 digits. We could have refined
this expression to match a date and constrain the month and day parts to match only consistent
values.
3. A suffix, such as -45RT347, starting with a dash and followed by a sequence of exactly
seven letters or digits.
We use the -(.{7}) regular expression to match this part.
We could obviously improve this regular expression by being much more precise and
constraining our expression to match a set of uppercase characters or digits. In this case
we would use the following expression ([A-Z|0-9]{7}), where the A-Z sub expression
matches any character from A to Z, 0-9 matches all the digits from 0 to 9 and the | between
519
Tutorials
the two sub expressions indicates that one of the sub expression must match. Finally the
square brackets define a character range. For this example we will keep to the simpler form.
As depicted in the previous screen shot NeoLoad has highlighted the contents that matches the
regular expression we have defined.
Tip
Searching through the contents. In our example the contents of response is simple and
short but a realistic response could be much longer. You can search for some particular
text by right clicking in the contents panel and selecting the "Search..." option or
using the CONTROL + F shortcut keys. This will open a search panel at the bottom of
the dialog in which you can enter target text and search for occurrences of that text.
Validation configuration is now complete.
Tip
To quickly and easily spot requests that have associated validations, select your virtual user,
right click on this node and select the "Flag requests..." item.
NeoLoad adds a tick to all the nodes (records, HTML pages and HTTP requests) of the
virtual user profiles using validations:
3. Testing your validation!
Erroneous or incorrectly stated validations will generate as much inconvenience as no validations

at all, so it is important to make sure validations are consistent. It is not always an easy goal to
achieve especially for complex scenarios. Most of the time though, a straightforward technique to
test your validations is to test the virtual user containing the requests that have response validations.
The following procedure quickly goes through this technique:
a. Open the "Check Virtual User" dialog using the button.
b. Test the virtual user using the "Start Checking" button.
520
Tutorials
NeoLoad displays all the pages and requests that have been replayed during the test. In this
case all has gone well and no assertions have failed. This doesn't completely guarantee that our
validations have been correctly configured but does give us a good indication.
The following screen shot depicts a situation where we have voluntarily changed our example
application code so that the validations we have defined both fail:
When selecting the failed response and selecting the "Assertion" option NeoLoad displays
the assertions that have failed and the reasons for which they have failed.
521
Tutorials
4. Defining NeoLoad's behavior when assertions fail
Although this final step is not about configuring validations, it is directly related to this subject
because it details how and where you configure NeoLoad's behavior when assertions fail.
Virtual Users assemble recorded pages and their associated HTTP requests in the Virtual User
profiles. In turn, Virtual Users are used to build populations and finally, load scenarios are achieved
using populations. Virtual Users are the building blocks on which you can define how NeoLoad
will behave when an assertion fails. You can either tell NeoLoad to ignore the failure and continue
executing the virtual user or force NeoLoad to abort the Virtual User when such a failure occurs. The
second alternative is definitely encouraged. It will ensure that load tests won't run uselessly and will
make it much easier for you to identify and determine the reasons of assertion failures.
In the following example we have decided to abort virtual user execution when both errors
and assertion failures occur. Errors are HTTP errors, such as Page Not Found errors. They are
automatically detected by NeoLoad.
Related Links
For more information on creating virtual users refer to reference guide Virtual Users
For more information on regular expressions refer to the regular expression appendix
Executing Java Code

Introduction
During a load test, it is possible to execute Java code that is external to the Virtual users. This feature allows
NeoLoad's functional range to be extended in order to create Virtual Users with a very complex behavior.
This tutorial takes as its example RMI (Remote Method Invocation) calls to a remote Java server. The
server provides two services: one gives the dollar value of a stock on the US Stock Exchange, the other
provides for the conversion of one currency to another. We are going to string together the call to these
two services to obtain a stock price in Euro.
522
Tutorials
Operation and Syntax

In NeoLoad, Java code may be invoked from JavaScript code, as part of the "JavaScript" logical action.
For Java classes to be used in JavaScript, the class names must be fully qualified (even for Java classes
such as java.util.List) and preceded by "Packages.".
For example:
var myObj = new Packages.com.company.MyClass();

var result = myObj.compute(myArg);
var result2 = Packages.com.company.MyClass.someStaticMethod(result);
Writing the Java Code

Depending on the case, it may be useful to hide part of the complexity of a call to an API behind a "business"
layer.
In our present example, we'll choose to handle the intermediate result, namely the dollar stock price,
transparently. The aim of this is to simplify as far as possible the succeeding JavaScript calls.
public class SampleClient {

private StockProvider remoteStockProvider;
private CurrencyConverter remoteCurrencyConverter;
private float usdStockQuote=-1;
public void connect() throws NotBoundException, IOException {
this.remoteStockProvider = (StockProvider) Naming.lookup(
"//fooserver/StockProvider"
);
this.remoteCurrencyConverter = (CurrencyConverter) Naming.lookup(
"//fooserver/CurrencyConverter"
);
}
public boolean isConnected() {

return this.remoteStockProvider != null && remoteCurrencyConverter != null;
}
public void getStockQuoteUSD(String stockSymbol) throws RemoteException {

if (!isConnected()) {
throw new IllegalStateException("Not connected to server");
}
this.usdStockQuote = this.remoteStockProvider.getStockQuote(stockSymbol);
}
public float getStockQuoteEur() throws RemoteException {

if (this.usdStockQuote < 0) {
throw new IllegalStateException(
"The method getStockQuoteUSD() has not been called."
);
}
return this.remoteCurrencyConverter.currencyConvert(
"USD", "EUR", this.usdStockQuote
);
}
523
Tutorials
The connect() method is used to connect to the remote object, getStockQuoteUSD() retrieves
the specified stock price and stores it internally, and getStockQuoteEur() returns the stock price
converted into Euro.
Configuring NeoLoad
Generally speaking, NeoLoad must have access to the Java classes used.
Copy the code to be called, and the libraries used, into the <neoload-project>/lib/jslib/. You
may place either JAR files or .class files in the directory.
For our example, copy the SampleClient class compiled in <neoload-project>/lib/jslib/,

as well as the JARs containing the interfaces for the remote objects to be used, namely StockProvider
and CurrencyConverter.
Preparing the Data

Our RMI calls require entry data, in this case the symbols for the stocks whose price we want to retrieve.
Create the "stockSymbols" File - type variable with the required values:
Create the stockQuotes.csv file
symbol;description
IBM;IBM
MSFT;Microsoft
AAPL;Apple
ORCL;Oracle
JAVA;Sun
GOOG;Google
Procedure 16.2. Create the "stockSymbols" variable

1. Use the "Edit / Variables" menu item.
2. Click the "Create a variable" button.
3. Select "File" type.
4. Name the variable, "stockSymbols".
5. Use the file previously created.
6. Select the "Use first line as header" option.
7. Leave the value change policies to their default setting: each line of the file corresponds to a Virtual
User instance.
8. Click "Ok".
Designing the Virtual User

Create a new Virtual User in the current project. We are going to create one action for each RMI call, as
this will allow us to retrieve access time statistics for each call:
1. Place three "JavaScript" logical actions in the Virtual User. Let's name them
"connect" ,"getStockQuoteUSD" and "getStockQuoteEur".
524
Tutorials
2. Place a "Delay" action in between each JavaScript action.
3. Modify the wait time for each delay. This must correspond to the time between the two calls in the
simulated application.
4. Replace the default code for each action with the following.
The JavaScript code for the three actions is as follows:
connect
var sampleClient = Packages.com.neotys.test.rmi.client.SampleClient();

sampleClient.connect();
context.currentVU.put("sampleClient",sampleClient);
logger.debug("sampleClient connected");
The script creates an instance of the SampleClient class described above and makes the connection to the
server. The sampleClient instance is stored within the Virtual User instance, for use by the subsequent
requests. Thus, we have one instance of SampleClient per Virtual User instance throughout the test.
getStockQuoteUSD
var sampleClient = context.currentVU.get("sampleClient");

var stockSymbol = context.variableManager.getValue("stockSymbols.symbol");
logger.debug("stockSymbol=" + stockSymbol);
sampleClient.getStockQuoteUSD(stockSymbol);
The script retrieves the sampleClient instance stored by the previous script, then interprets the
"stockSymbols" variable created previously. The getStockQuoteUSD method makes the RMI call
that retrieves the price for the stock whose symbol is taken from the CSV file. The dollar value is stored
within the SampleClient, to be used as an argument in the following call.
getStockQuoteEuro
var sampleClient=context.currentVU.get("sampleClient");
var stockValueEuro = sampleClient.getStockQuoteEUR();
logger.debug("Stock price €" + stockValueEuro);
context.variableManager.setValue("stockPriceEUR",stockValueEuro);
The script retrieves the sampleClient instance stored by the first script, then makes the call to the
RMI method that allows the previously-stored dollar value to be converted into Euro. The call to the
VariableManager allows the value retrieved by RMI to be injected into a NeoLoad variable. This
value may then be used in NeoLoad, for example as a classic HTTP request parameter. This is outside
the scope of this example however.
Validating the Virtual User

As with a standard Virtual User, the Virtual User must be validated in order to verify its proper execution.
525
Tutorials
1. Open the validation pane via the "Run / Start checking" menu item.
2. Select the appropriate user in the drop-down list ("RMIUser").
3. Click the "Start Checking" button.
Error Handling
The "JS-OK" return code denotes that the JavaScript code was correctly executed. In the case of a
JavaScript error, or if the Java code produces an exception, the "JavaScript" action is flagged as containing
an error, accompanied by the JS-ERROR-EVAL or JS-FAIL error code.
The logger.debug() method provides for the logging of useful information for checking that the
scenario runs correctly during the validation. In our example, we're displaying the result of the last RMI
call. By default, DEBUG-level logs are only displayed during the validation process. See the Reference
Guide for more information on logs.
Tests and Results

Once the Virtual User has been created and checked, create a population and configure your scenario as
for a normal test.
In NeoLoad, the "JavaScript" logical action is not considered a request. Therefore, most of the NeoLoad
statistics, such as average pages/sec, average hits/sec, average request response times... all return zero.
This is true during test monitoring, in the test summary and in the generated reports.
Thus, the only place the JavaScript statistics can be found is in NeoLoad's "Values" and "Graphs" tabs.
The information available in these tabs is the same as for an HTTP request.
Related Links
For more information about using JavaScript in NeoLoad, see the section called “JavaScript”.
See NeoLoad's JavaScript API .
Design - Dynamic Parameters

Table of contents
Choosing a Data Extraction Method

Handling an Application's Dynamic Parameters
Creating a Variable Extractor
Submit a Form from the Previous Request
Using Framework Parameters to Automatically Search for Dynamic Parameters
Choosing a Data Extraction Method

Introduction
Dynamic parameters are link or form parameters that are generated by the server. Normally invisible to
the end-user, these parameters are inserted into submitted links and forms.
526
Tutorials
Unless the test designer decides otherwise, during the test run the recorded values are submitted "as is".
Therefore, these values need to be re-worked using a process of data extraction and re-insertion. The
Search for dynamic parameters function, included in the Post-recording Wizard, allows you to
identify the dynamic parameters and automatically configures the virtual user profile to allow the extraction
and insertion of the appropriate data.
The Search for dynamic parameters function automatically handles dynamic parameters in
the vast majority of cases. For more complex cases, the parameter must be managed manually using one
of the extraction methods described below.
Extraction Methods
NeoLoad provides various data extraction methods to extract and insert link or form parameters. The
methods are used automatically by the Search for dynamic parameters function and can be
used explicitly for manual extraction.
The following section briefly outlines each method and provides guidance on choosing the appropriate
method for each particular case.
• Link extractors. To use a link extractor, select the "Follow a link from the previous
request" request type.
In this mode, NeoLoad searches for a link in the previous response according to the criteria entered in
the request definition pane and submits the link it finds.
The advantages of using a link extractor are:
# it can search for a link using its "id" or "name" attribute, its label or its path. For example, you can
search for a link whose id attribute is "search-tab" or whose (text) is "Next";
# because it extracts the link as a whole, there is no risk of extracting in error a parameter from one link
and another parameter from another link or from another part of the HTML page.
This type of extractor only works with standard links declared in HTML code and cannot be used where
the link is created dynamically using JavaScript calls.
For more information, see the section called “Follow a link from the previous request” in the Reference
Guide, or the "Follow a link from the previous request" tutorial.
• Form extractors. To use a link extractor, select the "Submit a form in the previous
request" request type.
In this mode, NeoLoad searches for a form in the previous response according to the criteria entered in
the request definition pane and submits the form it finds. Custom values can be inserted in the extracted
form.
The advantages of using a form extractor are:
# it can search for a form using its "id" or "name" attribute, its label or its path. For example, you can
search for a form whose id attribute is "search-form";
# it can search for a form according to its occurrence within a page. For example, you can search for
the first form in a page without being more specific;
# because it extracts the form as a whole, there is no risk of extracting in error a parameter from one
form and another parameter from another form or from another part of the HTML page.
527
Tutorials
For more information, see the section called “Submit a form from the previous request” in the Reference
Guide, or the "Submit a Form from the Previous Request" tutorial.
• Variable extractors on parameters. To use a variable extractor defined on a parameter, select the
"Manually define the request" request type. Edit the parameter and select the "Use an
extracted value" option.
In this mode, NeoLoad extracts the data using a regular expression. You may fine-tune the extraction
for extracting multiple values.
The advantages of a using variable extractor on a parameter are:
# it can extract data from the entire response body, it is not limited to links and forms;
# the extraction is automatically configured.

For more information, see the section called “Use a manual definition” in the Reference Guide, or the
"Handling an Application's Dynamic Parameters" tutorial.
• Variable extractors on requests. To define a variable extractor on a request, first select the request
whose response contains the data to be extracted. Next, click on the "Advanced..." button, select
the "Variable Extractors" tab and click on the '+' button.
In this mode, NeoLoad extracts the data using a regular expression. You may fine-tune the extraction
for extracting multiple values.
The advantages of using a variable extractor on a request are:
# it can extract data from the entire response body, it is not limited to links and forms;
# the value may be changed prior to its use. As the extractor is placed on a request that precedes the
request that inserts the value, you may use JavaScript to format the value, do a calculation and re-
insert the modified value.
For more information, see the section called “Variable Extractors” in the Reference Guide.
Framework Parameters
Thanks to its "Search for Dynamic Parameters" function, NeoLoad can detect and automatically configure
dynamic parameters.
The "Search for Generic Parameters" section allows you to automatically detect an application's custom
dynamic parameters without having to declare them in advance. When this detection fails, the parameter
needs to be handled using a variable extractor. NeoLoad allows you to add this variable extractor to a
list of pre-defined rules so that the search for framework dynamic parameters automatically handles this
custom parameter at each new recording.
For more information, see the section called “Framework Dynamic Parameter Handling” in the Reference
Guide.
Handling an Application's Dynamic Parameters

Understanding the Problem
The HTML pages generated by the applications usually contain dynamic elements, that is to say elements
whose values vary from one call to the next. Typically, these include unique identifiers that cannot be
replayed "as is", and which must be handled individually.
528
Tutorials
When a dynamic parameter is not handled correctly:
• requests may return an error (typically, Error 500) when validating the Virtual User;
• the Virtual User displays an unexpected behavior (entries not created in the database for example).
NeoLoad automatically handles the most common parameters, such as the framework .Net
__VIEWSTATE parameter. However, NeoLoad cannot automatically handle some parameters that are
specific to an application. These need to be handled individually, that is to say by placing an extractor on
the value returned by the server and injecting the extracted value into the appropriate requests.
This tutorial will show how search for, and handle, a dynamic parameter. The steps are as follows:
1. Identify the request returning the error
2. Identify the parameter to be handled
3. Search for the request whose response contains the value to be extracted.
4. Place the Variable Extractor.
5. Inject the variable in the appropriate requests.
6. Validate the changes.
The example used throughout this tutorial is taken from an e-commerce demo application. The recorded
scenario concerns the purchasing of an animal on the website.
Running the Virtual User Validation

Validation allows you to check a virtual user's behavior. In the event of a problem, the information required
to correct the problem, namely details of all the requests sent to the server and their responses, are displayed
in the validation window.
Procedure 16.3. Validating a Virtual User
1. Select the "Run / Start checking" menu item.
2. Select the appropriate Virtual User in the list.
3. Click the "Start checking" button.
529
Tutorials
Identifying the Request Containing the Error

Depending on the application tested, requests return the HTTP '500 Internal Error' code. In this
case, NeoLoad automatically flags the request as containing an error.
In many cases however, the error is handled at the application level and the page returned by the server
shows a '200 OK' error code. In this case, NeoLoad cannot detect the error automatically, and the error
must be searched for manually.
Procedure 16.4. Manually searching for an error

1. Run the Virtual User validation (See the section called “Running the Virtual User Validation”)
2. Scan all the requests with HTML responses. Typically, these will be the first or second response in
each page.
3. Check the response content for each HTML request:
a. Click on the request
b. Make sure the "Response" radio button is checked in the "Details" section.
c. Examine the server response displayed in the text area for any error message or inappropriate
content. Click on "Open in browser" to display the response in a more readable format, then
click on "Compare with recording" to highlight the discrepancies between the replayed
request and the response received during the recording.
In our example, the '500 Internal Error' code clearly identifies the request containing the error.
530
Tutorials
Important
When an error occurs, it usually triggers a cascade of subsequent errors. To correct the problem
therefore, it's important to work on the first request containing an error. Once this has been fixed,
run the Virtual User validation again and correct any other errors that may be flagged.
Identifying the Parameter to be Handled

Click on the link in the validation window to be taken automatically to the
definition of the request containing the error in the scenario's Virtual User profiles.
We can see that the request contains two parameters:
1. categoryID. This parameter provides the category of animal selected during the scenario recording
(in our case a dog). The "categoryId" field is not generated by the server, but is a direct result of the
user's choice. Consequently, it can be safely assumed that this parameter is not the source of the error.
2. id. The id parameter is a suspect, however, due both to its name and its value. We can assume that
the value is generated by the server and that this parameter is the source of the error reported during
validation.
If in doubt over a parameter, continue the process for each parameter. The next step will allow you to check
whether the parameter should be processed, or whether the recorded value can be submitted unaltered.
Making the Parameter Dynamic Automatically

NeoLoad includes a search engine that allows it to configure automatically the extractor to be used. The
search is based on regular expressions that take into account the all the various methods applications use
to allocate values.
531
Tutorials
1. Select the "/jpetstore/shop/viewcategory.shtml" request.
2. Double-click on the value of the id parameter.
3. Select the "Use an extracted value" option.
4. Click on the "Automatic Configuration" button (NeoLoad will then configure the extractor
to be used for you).
5. If you get the message "NeoLoad could not find the parameter", you will have to
configure the extractor manually (see the section called “Making the Parameter Dynamic Manually”).
Globally Replacing a Parameter in a Recording

Once the extraction has been configured, the request should work correctly. However, it is a good idea
to check to see if this same value is used in other requests in the scenario and to replace the static value
with the new variable.
Start the wizard using the "Edit / Search and replace" menu item:
532
Tutorials
The wizard allows you to automate the replacement of the "id" parameter's value with the
"nl_extracted_param" variable. Select the first option "Search request parameters", then
click "Next" to go to the next step.
533
Tutorials
Select "Search names and values and replace", then click "Next" to enter the search criteria.
534
Tutorials
In the first field, we'll enter the value for the "id" parameter, that is to say "1241078526424",
which was previously non-editable. In the second field, we'll enter the replacement value
"${nl_extracted_param}". If necessary, we can use the variable picker :
Once the variable has been selected, click "Next", then "Finish". A dialog box allows you to replace
each occurrence of the value "1241078526424". When all of the replacements have been made in the
scenario, the dynamic parameter's management is finished.
Re-checking the Virtual User

To successfully conclude the procedure, we need to check the validity of the newly-modified virtual user.
Click the button to display the validation window. Run the validation to show the following result:
535
Tutorials
The request that was previously flagged as containing an error is now correctly handled. The HTTP code
returned is 200, proof that the client-server transaction has been successfully completed.
Making the Parameter Dynamic Manually

If automatic configuration fails, you will need to define the variable extractor manually.
Searching for the Request whose Response Contains the Value to be Extracted
We have already found the parameter whose replayed value is invalid. We now have to find the request
whose response contains the server-generated value to be extracted.
In our example, the id parameter was submitted with a value of "1193061773021" during the recording.
Let's search for the request whose response contains this value.
Procedure 16.5. Searching for the value to be extracted
1. In the Virtual User profiles tab, click on the node that corresponds to the virtual user profile.
2. In the "Flags" section, select the last option "whose recorded response contains:"
and enter the value: 1193061773021.
3. NeoLoad places a check mark against the requests whose responses contain the entered value, in our
example it's the request /jpetstore/shop/index.html : .
536
Tutorials
We have now located the request whose response contains the value for the parameter to be processed.
Let's check to make sure it's the value we want and whether the parameter really needs to be processed.
Procedure 16.6. Checking the parameter

1. Open the validation window and select the identified request (/jpetstore/shop/
index.html).
Tip
Right-click on the request in the Virtual User profile, and use the "Select in
validation window" menu item to automatically open the validation window with the
selected request displayed.
2. Compare the response obtained during the validation with the one obtained during the recording:
537
Tutorials
a. Make sure the "Response" radio button is checked in the "Details" section.
b. Click the "Compare with recording" button.
The comparison tool reveals that the id parameter's value is generated in this response and that
the value has changed. Therefore, this parameter must be handled individually.
Extracting the Parameter Value
We now need to extract the value of the "id" parameter from the "/jpetstore/shop/
index.shtml" request. To do this, we'll need to use a variable extractor.
Procedure 16.7. Creating a variable extractor
1. Select the "/jpetstore/shop/index.shtml" request.
2. Click on the "Advanced Parameters.." button.
3. Click on the "Variable Extractor" tab.
4. Click "+".
In our example, let's extract the "myId" variable from the server response body. Extract the content starting
with "id=" and ending with "" shape":
538
Tutorials
Note
See the tutorial Extracting Data from an HTTP Request and Using it Later in the Scenario for
more information on extracting and injecting variables.
Globally Replacing the Parameter in the Recording
Once we've completed the extraction and placed the parameter value in a variable, named "myId" for
example, we'll then look at how to replace the value recorded in the scenario with the created variable.
Run the wizard using NeoLoad's "Edit / Search and replace" menu item:
539
Tutorials
This wizard allows you to automatically replace the value of the "id" parameter with the "myId" variable.
Select the first option "Search in request parameters", then click "Next" to go to the next step.
540
Tutorials
Select "Search names and values and replace", then click "Next" to enter the search
parameters.
Fill in the first field with the value previously used for the "id" parameter, "1193061773021". Put the
replacement value "${myId}" in the second field. Use the variable picker if necessary :
541
Tutorials
Once you've selected the variable, click "Next", then "Finish". A dialog box allows you to replace each
occurrence of the value "1193061773021". The replacement process looks like this:
542
Tutorials
The window in the top left-hand corner allows you to navigate through each occurrence and indicate
whether or not the replacement should apply. The pages containing the parameter in question are marked
in the scenario tree. Moreover, the parameter found is highlighted in yellow in the request's parameters.
Click the "Replace" or "Replace all" buttons to replace the value:
543
Tutorials
You can see that the "id" parameter's value has been replaced by the "myId" variable. Replace each
occurrence of the "id" parameter to make the entire scenario dynamic.
Re-checking the Virtual User
To successfully conclude the procedure, we need to check the validity of the newly-modified Virtual User.
Click the button to display the validation window. Run the validation to show the following result:
The request that was previously flagged as containing an error is now correctly handled. The HTTP code
returned is 200, proof that the client-server transaction has been successfully completed.
Additional Links
To follow up this subject, you may want to read the tutorial "Using Framework Parameters to
Automatically Search for Dynamic Parameters."
For more information on extracting dynamic values from an HTML page, see the tutorial "Extracting Data
from an HTTP Request and Using it Later in the Scenario".
Creating a Variable Extractor

This tutorial describes in detail the various steps involved in creating a variable extractor. It explains in
which context a variable extractor should be used and provides an actual example.
To ensure that this tutorial applies to your case, we recommend that you first read and understand Choosing
a Data Extraction Method. See the Chapter 10, Design User Guide for an overview of creating a virtual
user.
544
Tutorials

The contents of HTML pages generated by your application contain dynamic elements. Typical examples
of dynamic content are elements such as HTTP request parameters or links with generated URLs. But in
some situations these elements are neither parameters nor links, they are plain HTML elements belonging
to the page. Nevertheless you might need to extract these dynamic elements to obtain more realistic
scenarios and more thorough test results. Let's look at the following excerpt from an HTTP response,
containing the result of an account registration feature:
<HTML>
<BODY>
<H2>Create an account</H2>
<P>
<B>Error registering account:</B>
<I>The user name you have chosen is already in use.</I>
</P>
<P>The following suggestions are available:</P>
<UL>
<LI>Suggestion 1: <I>WBrown</I>
<LI>Suggestion 2: <I>WilliamBrown_1</I>
</UL>
<P>Enter another user name and retry</P>
<FORM action="index.jsp" method="post">
<INPUT type="text" name="username" /><BR/>
<INPUT type="submit" value="Send">
</FORM>
</BODY>
</HTML>
The HTML page contains text explaining that account registration has failed because the user name
provided by the user already existed. The page then suggests alternative user names that the user could
use. It finally provides an HTML form for the user to retry creating an account using a different user name,
possibly one of the suggested alternatives. If we wanted to define a scenario where the Virtual User selects
one of the suggested alternatives, let's say the first one in the list for instance, we need to extract WBrown
to re-inject it into the request that submits the form.
In our case, we are going to use a mechanism called the Variable Extractor which extracts arbitrary
contents from an HTTP response and assigns the contents to a variable.The variable can then be used
anywhere NeoLoad accepts variable values. The extracting mechanism and the way to use the extracted
value are the subjects this tutorial mainly addresses.
545
Tutorials
Extracting Contents and Assigning it to a Variable

The following screen shot depicts the simple HTML page described in the previous section. We have
recorded pages that enter the account information, including an already existing user name. Our example
application has then returned the following form and we have recorded the submission using one of the
suggested user names. The one we choose during the recording phase has no importance because we will
be using the one we decide to extract.
The following procedure describes the steps involved in creating a variable extractor to extract the first
name proposed.
1. Select the HTTP request containing the content to be extracted
a. Go to "Design" mode.
b. Select the "Virtual users" tab.
546
Tutorials
c. Unfold the appropriate HTML page node.
d. Select the HTTP request whose response contains the content to be extracted:
2. Go to the Variable Extractor settings
a.
Click on the button to open the "Advanced" settings dialog box.
b. Select the "Variable extractors" tab:
547
Tutorials
3. Add and define a variable
a. Adding the variable
Click on the "+" button to add a new variable. This opens the "Variables Extractor"
dialog box:
548
Tutorials
This dialog box helps you define how to extract the value that will be assigned to the variable.
Extracting the value will be based on regular expressions. Most of the time this task will be
greatly eased by the "Variables Extractor" dialog.
Note
In some situations it might be necessary for you to manually work with regular
expressions to extract the contents of the variable. In this case, NeoLoad provides an
advanced mode.
You can switch to the advanced mode by selecting the "Switch to advanced
mode" button.
The advanced mode involves manually manipulating and defining regular expressions,
for more information refer to the Reference Guide and the regular expression appendix.
b. Naming the variable
Enter the name of the variable in the Variable Name text box, in our example we call it
SuggestedUsername.
c. Entering the Starting with: text
Enter the text that will unambiguously identify where the content you want to extract starts.
This step is important because the extracting mechanism depends on it to succeed in correctly
extracting the value of the variable.
549
Tutorials
i.
Select the button associated with the Starting with: text box. This opens a
"Response Text Picker" dialog. The dialog presents the contents of the HTTP
response from which the contents of the variable will be extracted.
ii. Select in the response the text that will always be placed before the text you want to extract.
This portion of text must unambiguously identify the starting position of the text you are
targeting. In our example we select the following sentence <LI>Suggestion 1: <I>.
Selecting only <LI> would have been insufficient because in the response, there already
is an <LI> preceding the text we want to identify.
iii. Select the "Pick Selected Text" button to confirm the text you have selected.
d. Define the matching expression
Define the expression that will match the contents you want to extract. The "Followed by"
panel displays a set of expressions that the text we are targeting should meet. A default expression
is provided: it matches "Any character" that occurs "Zero or more times".
Important
Any character matches all characters except newline characters.
550
Tutorials
In our case this suits us perfectly, we want to extract any text following the <LI>Suggestion
1: <I> sentence. There are no particular constraints on the text we are targeting. Another way
of seeing the configuration at this stage is to state that we are extracting a value that matches
the following regular expression <LI>Suggestion 1: <I>(.*). The (.*) means any
number of characters except the newline character.
Tip
The "Test" panel at the bottom of the Variable Extractor Dialog displays the text that
will be extracted according to the current state of your configuration. This is handy to
get an idea of what the result will be while configuring the extraction.
In our case the dialog displays WBrown</I>. This is consistent with the fact that the
expression any number of characters except new line matches all the text including </
I>. The "Define Ending with:" step will finalize the configuration so that </
I> is not included in the text we want to extract.
Had we wanted to define additional constraints on the text to extract, we could have added other
expressions and configured them using the "Followed by" and "Occurs" elements. For
example, if we had wanted to identify the suggested user name value more precisely and more
robustly (making sure there really are no ambiguities on the identification) we could define the
following elements:
551
Tutorials
The "Starting with" text is no longer <LI>Suggestion 1: <I>, but is now reduced
to <LI>Suggestion. The first expression we define is a "Numeric Character" "Zero
or more times". The second is a literal sentence, : <I>, that occurs only once, the third
is "Any character" "Zero or more times".
The contents to extract has not changed: the extracted value in the Test panel is still
WBrown</I>. This configuration is equivalent to matching the following regular expression
<LI>Suggestion (\d*)(: <I>)(.*) and extracting the text that only matches the
third expression (.*). These expressions are called "value templates". Advanced mode,
reserved for users who are at ease working with regular expressions, allows you to view and edit
the regular expression generated in standard mode.
An important point to understand in this alternative configuration is the "Extract" column

which defines, among the listed expressions, the ones that must actually be extracted and used
to assign the variable. The only one of interest to us here is the last one, this is why it is the only
one checked in the "Extract" column.
For the rest of the tutorial we will keep to our first and simpler configuration.
e. Define Ending with:
Define the text that will unambiguously identify where the contents you want to extract ends.
You can use the "Response text" picker as previously detailed for the "Starting
with:" item if you want to select the text from the HTTP response. In our case the ending text
is quite simple, we know the suggested user name ends with the </I> HTML element. This is
what we enter in the "Ending with:" item.
552
Tutorials
4. Test the variable
Select the Test tab to test your variable.
The "Test"tab provides an easy to use feature to test the variable you've configured in the previous
steps. It allows us to test the variable extractor on the recorded HTTP response. If required, the HTTP
response may be edited.
The screen shot that follows depicts a situation where we have changed the first suggested value to
Will Brown, we want to make sure extraction correctly takes white spaces into account:
553
Tutorials
5. Define the behavior when the extracting mechanism fails
Select the Error tab to configure NeoLoad's behavior when the extracting process fails to find the
value for the variable. NeoLoad provides two items to configure its behavior, the value to assign to
the variable if the extraction fails, an error value, and the fact that an assertion error is thrown if the
extraction fails. For more details on assertions refer to the reference guide.
Depending on your application, several strategies are possible. If it makes no sense for your scenario
to not find the extracted value then throwing an assertion error is important. On the other hand, if in
some situations it is acceptable and consistent not to find the extracted value, an error value can be
assigned to the variable. In this case, Virtual User actions such as the if ... then ... else
construct can be used to adapt the behavior of the scenario to this situation.
6. Confirm variable creation
Close the Variable Extractor dialog by selection the OK button: the creation and configuration steps
are completed. The "Variable extractors" tab of the "Advanced" panel displays all the
defined variables. It presents variable names, the associated regular expression and the template
expression that will be used to extract the value and assign it to the variable.
In our case the first template value, $1$, of the <LI>Suggestion 1: <I>(.*) regular
expression will be assigned to the SuggestedUsername variable. The $1$ template value
corresponds to the (.*) of the regular expression.
554
Tutorials
Tip
To quickly and easily spot requests that use Variable Extractors, select any node in the
virtual user profiles, right click on this node and select the "Flag requests...", then
"Variables extractors defined on".
NeoLoad adds a tick to all the nodes (virtual users, HTML pages and HTTP requests) of the
virtual user profiles using Variable extractors:
Using the Variable

At this stage the variable extractor has been used to define the SuggestedUsername variable. This
procedure entails defining where to use the variable, in other words defining where the extracted value
will be re-injected. We have decided to retry creating an account using the first suggested user name, so
we want to re-inject the value when submitting the form.
1. Select the HTML page that follows the one receiving the form.
NeoLoad has automatically identified and listed the form parameters: in our case the username
parameter.
555
Tutorials
2. Set the value of the form parameter with the extracted variable.
Double-click on the Value cell and set the value to the SuggestedUsername variable, either by
using the variable picker or by manually entering the expression ${SuggestedUsername}, in
the "Expression"field. Click "OK" to validate.
3. Test the Variable Extractor with a Virtual User
Once extracted variables have been defined, it is a good idea to test them before using them in
operational scenarios. Checking the validity of the virtual user created is an easy way to test their
behavior and check the contents of the requests and related HTTP responses. See the procedure
detailed in the section Validating a Virtual User.
556
Tutorials
Related Links
For more information on regular expressions, refer to the regular expression appendix.
Submit a Form from the Previous Request

This tutorial looks at the case where the request type "Submit a form from the previous
request" is used. This is one of the methods provided by NeoLoad for extracting data from an HTML
page returned by the server. See the section called “Choosing a Data Extraction Method” for more
information on the various methods of extracting data.
The tutorial describes one of the steps in the methodology relating to designing a virtual user. See the
Chapter 10, Design User Guide for an overview of designing a virtual user.

An HTML form that is submitted to your application contains control elements (text boxes, radio buttons,
checkboxes etc.) that have been filled in or modified by the user. When NeoLoad plays back the recorded
HTML form, submitting it to the application, it must be able to re-generate all the form's control values.
In most cases, simply submitting the control values entered during the recording phase is sufficient. In the
following example, the text entered in the HTML form's lastname text box can be played back using
the recorded value as many times as desired:
<FORM action="doit.jsp" method="post">

<P>
Last name: <INPUT type="text" name="lastname"><BR/>
</P>
</FORM>
In certain situations however, the control elements contain values generated by your application each
time the HTML form is called. These dynamic values are sent back to the application when the form is
submitted. The dynamic values may be hidden, to prevent them being modified by the user. In the example
below, we can see that the dynamicID element contains a value generated by the application that varies
each time the form is called:
<FORM action="doit.jsp" method="post">

<P>
Last name: <INPUT type="text" name="lastname"><BR/>
<INPUT type="hidden" name="dynamicID" value="7885">
</P>
</FORM>
In this type of situation, simply playing back what was recorded will not work, since the dynamic value
sent to the application will not be the expected value. Here, the HTML value needs to be extracted in order
to inject the appropriate value. This is what we'll be looking at in this tutorial.
To deal with dynamic values, NeoLoad provides a mechanism called a form extractor , which extracts the
dynamic value from the preceding HTTP response and re-injects it in the request containing the HTML
form.
557
Tutorials
Note
To be precise, the value is not extracted from the preceding HTTP request, but from the
referrer of the HTTP request that contains the form's parameters.
Extracting and Re-injecting a Hidden Dynamic Value

We'll use the following HTML form as a example:
The screenshot below shows the source code for the form used in our example (the HTTP response's
content). The response sets out a text box control lastname, a hidden control dynamicID and a select
control country. We have recorded the pages that call the form and have completed and submitted the
form during the recording.
558
Tutorials
This screenshot was obtained by selecting the page preceding the page that submits the form. We selected
the HTTP request , clicked on the button and selected the "Recorded Response" tab.
The following procedure explains the steps required to tell NeoLoad how the dynamicID parameter
should be extracted and injected in the played-back form.
1. Select the HTTP request containing the HTML form
a. Go into Design mode.
b. Select the Virtual Users tab.
c. Unfold the nodes of the HTML page and the appropriate recording; this is the HTML page that
follows the page that calls the form.
d. Select the HTTP request containing the HTML form's parameters, the request that will submit
the form:
559
Tutorials
During the recording phases, NeoLoad identifies the fields in the HTML form and therefore the
parameters of the HTTP request that will be sent when the form is submitted. In our example,
these parameters are lastname, dynamicID and country.
Tip
To identify those HTTP requests that submit forms, select the current request's or virtual
user's node, right-click on the node and select "Flag requests...". Select the
"POST form type" option.
2. Change the HTTP request type
In the "Type"drop-down list, change the HTTP request type from "Manually define the
request" to "Submit a form from the previous request".
3. Check the form extraction criteria
In the "Form to extract" section, click on the "..." button to display the form's extraction
criteria.
560
Tutorials
This dialog box is used to specify how NeoLoad should search the preceding HTML response for the
form whose values are to be extracted. The default settings are usually OK to use. Use other, more
appropriate criteria if necessary. In our case, the criteria are appropriate.
4. Use the extracted value
In our example, double-click on the dynamicID parameter to display the parameter's editing pane.
561
Tutorials
Select the "Use value from extracted form" option. This way, when a virtual user that
uses this request is played back, NeoLoad will submit the form with the value extracted from the
server's preceding HTML response instead of submitting the recorded value.
As with all parameters that use extracted values, the dynamicID parameter is displayed with a
distinctive icon and label.
562
Tutorials
Learning More about Form Extractors

In the above example, the HTML form contains a select control that allows you to choose a country
among several values in a country list. If you configure the country parameter using the same procedure
as for the dynamicID parameter, NeoLoad will randomly select one of the possible country values and
re-inject it.
You could have used a variable listing all the country options to obtain a similar behavior by setting the
parameter's value field to a variable. However, by using data extraction, you avoid having to keep variables
synchronized with your application. Also, if other country options are added, you do not have to change
the configuration or definition.
The Reference Guide gives more details of the various options and panes shown here. See the section
called “Submit a form from the previous request”.
Related Links
Just as you an extract dynamic data from a form, you can also follow a dynamic link. See the "Follow a
link from the previous request" tutorial.
For more information on extracting arbitrary content, see the section on the variable extractor in the
Reference Guide and the "Creating a Variable Extractor" tutorial.

This tutorial looks at the case where the request type "Follow a link from the previous request" is used.
This is one of the methods provided by NeoLoad for extracting data from an HTML page returned by the
server. See the section called “Choosing a Data Extraction Method” for more information on the various
methods of extracting data.
563
Tutorials
This extraction method can be used when a request is the result of a standard HTML link of the type <a
href=""...>. The aim is to play back a link and its parameters as returned by the server during the
test instead of playing back the recorded link. This tutorial will show you two ways of telling NeoLoad
how to follow the link: either to search for an attribute containing a specific value, or to search for one
or more values in the link's parameters.
The tutorial describes one of the steps in the methodology relating to designing a virtual user. See the
Chapter 10, Design User Guide for an overview of designing a virtual user.

An HTML page often contains dynamic elements generated by your application. Typical examples of such
dynamic elements are request parameters used to determine a context, a search context for instance. The
following code is an extract from an HTTP response containing such dynamic elements.
<HTML>
<BODY>
...
<A href="index.jsp?searchID=24257622&page=2">Next Page</A>
</BODY>
</HTML>
The HTML page displays a link called Next Page that refers to the index.jsp page with two dynamic
parameters: searchID and page. If this link is followed during the recording phase and replayed in a
scenario, NeoLoad will use the recorded values. This is definitely not the desired behavior and this tutorial
mainly addresses this issue.
To deal with dynamic URLs, NeoLoad provides a mechanism that automatically finds a URL in the
previous HTTP response and injects it in the following HTTP request.
564
Tutorials
Ensure this Tutorial Applies to your Case

For the purposes of this tutorial, we've recorded a scenario in which we start on a search page, enter our
search criteria, then browse the results going from one page to the next. The following illustration shows
a very simple page of results. The search criteria have been entered beforehand and the user is browsing
the results from page to page:
The screenshot below shows the content of the HTTP response for this HTML page. As explained above, it
contains a link that refers to the page index.jsp, with two dynamic parameters: searchID and page.
We obtained this screenshot by selecting the page containing the Next page link. We then selected the
HTTP request, clicked on the button and selected the "Recorded response" tab.
This tutorial will show you several ways of telling NeoLoad how to find and follow the HTML link "Next
Page".
Following a Link Using an Attribute's Value

The following procedure describes how to find the link identified by the text "Next Page" in the response
referred to earlier. It will also allow us to dynamically play back all the link parameters' values during
playback.
565
Tutorials
1. Select the HTTP request containing the URL with dynamic parameters
a. Go into "Design" mode.
c. Open out the corresponding virtual user and HTML page.
d. Select the HTTP request containing the dynamic URL; this request belongs to the HTML page
that that follows the page containing the HTTP request described earlier.
During the recording phases, NeoLoad identifies the URL parameters that will be sent when the
link is followed. In our example, these parameters are searchID and page.
request" to "Follow a link from the previous request".
3. Make sure the referrer is the preceding request
In the "Extract and follow a link from" field, make sure that the request shown is the
one containing the href HTML tag. If this is not the case, click on the "Change the referrer"
button and select the correct referrer.
4. Select the link attribute
Click on the "Link whose" radio button, then select the attribute to search for. For our example,
select "link text" to tell NeoLoad to search for a link content of the type
<a href=..>[content_to_be_searched_for]</a>.
5. Enter the attributes value
566
Tutorials
In the "is" field, enter the attribute value to search for, in our case "Next Page". This tells NeoLoad
to search for a link whose form is:
<a href=..>Next Page</a>.
The following screenshot shows what your screen should look like at this stage:
This will instruct NeoLoad to extract any link whose label is "Next Page" and dynamically inject it
during the test.
Following a Link Using the Definition

The following procedure describes how to find the link defined by the searchID and page parameters in
the above response. It will also allow us to dynamically play back the searchID's value during playback.
567
Tutorials
1. Select the HTTP request containing the URL with dynamic parameters
a.
Click on the button to go into "Design" mode.
c. Open out the corresponding virtual user and HTML page.
d. Select the HTTP request containing the dynamic URL; this request belongs to the HTML page
that that follows the page containing the HTTP request described earlier.
During the recording phases, NeoLoad identifies the URL parameters that will be sent when the
link is followed. In our example, these parameters are searchID and page.
request" to "Follow a link from the previous request".
3. Make sure the referrer is the preceding request
In the "Extract and follow a link from" field, make sure that the request shown is the
one containing the href HTML tag. If this is not the case, click on the "Change the referrer"
button and select the correct referrer.
4. Enter the link's definition
Make sure that the "Server" and "Path" combination points to the link in question.
Here, we're telling NeoLoad to search for a link whose URL points to the selected server and specified
path, such as:
<a href="http://jack:9090/loadtest/simple-search/index.jsp"..>..</
a>.
568
Tutorials
5. Select the attributes to be dynamically extracted
In the "Request Parameters"section, double-click on the attribute to be dynamically extracted

from the server response, in our case "searchID". Next, click on the radio button "The
parameter must be present, whatever its value".
Here, we're telling NeoLoad to refine its search for the link , such as:
<a href="http://jack:9090/loadtest/simple-search/index.jsp?
page=2&searchID=.."..>..</a>.
The following screenshot shows what your screen should look like at this stage:
This will instruct NeoLoad to extract any link whose URL starts with "http://<jack>/
loadtest/simple-search/index.jsp", whose "page" attribute is "2" and having a
"searchID" attribute (whatever its value), and dynamically inject it during the test.
Tip
Dynamic path value: The Path expression, /loadtest/simple-search/
index.jsp in our example, also may be dynamic, its value being generated by your
application each time the link is requested. In this case, you must tell NeoLoad to extract
the value from the response and re-inject it before requesting the URL. If the link path is
dynamic, click on "Regular expression" and use the appropriate regular expression
to indicate which path to extract. This may simply be .* if there are no other links with
the same parameters.
Dynamic server value: The Server used by the request may also be dynamically
generated by your application. In this case you must create a server manually, configuring
the server host name with a regular expression that matches the server's name. Then, you
must set the server for this request to the server you have just created.
569
Tutorials
Using Framework Parameters to Automatically Search

for Dynamic Parameters
This tutorial will show you how to automate dynamic parameter handling using framework parameters.
To get the most out of this tutorial, it is recommended to have read the following tutorials beforehand :
• Creating a Variable Extractor.
• Handling an Application's Dynamic Parameters, in order to understand the steps involved in defining
a variable extractor.
Understanding the problem

The HTML pages generated by applications usually contain dynamic elements, that is to say components
whose values vary from one call to the next. Typically, these include unique identifiers that cannot be
replayed "as is", and which must be managed individually.
When dynamic parameter handling fails:
• requests may show an error (typically, Error 500) when checking the virtual user's validity;
• the Virtual User displays an unexpected behavior (entries not created in the database for example).
NeoLoad automatically handles the most common parameters, such as the framework .Net
__VIEWSTATE parameter. However, NeoLoad cannot automatically handle parameters that are specific
to an application. These need to be handled individually, that is to say by placing an extractor on the value
returned by the server and injecting the extracted value into the appropriate requests.
NeoLoad provides the necessary tools to handle a dynamic parameter manually. See the section called
“Handling an Application's Dynamic Parameters”.
Example
Handling a dynamic parameter manually involves extracting the value from the server response using a
variable extractor and replacing it in the appropriate requests. In our example, we'll use the extractor to
declare a framework parameter.
Here, we can use the variable extractor to extract the "id" parameter from the server response.
570
Tutorials
The parameter we're looking for appears in numerous requests, which is why the search must be
systematized. The multiple occurrences of the "id" parameter in the scenario (identified by the blue flags
) can be seen in the following screenshot.
571
Tutorials
How a framework parameter works

By adding a rule to the framework parameter, we can handle all the occurrences of a parameter
automatically.
When searching for dynamic parameters NeoLoad uses the rules defined for the framework parameter to
automatically create variable extractors in the appropriate requests. Furthermore, NeoLoad automatically
injects the corresponding variables into the parameters of the requests that require the variables.
The dynamic parameter search is carried out:
• at the end of the recording, using the Post-Recording Wizard;
• using the virtual user's Dynamic Parameter Search Wizard. Select the appropriate virtual user in the
"Design / Virtual Users" tab, then click on the "Search" button to launch the wizard.
Creating a framework parameter

There are three ways to create a framework parameter: manually, using a variable extractor set on a request,
or using a variable extractor set on a parameter.
In this example, we'll explain how to create a framework parameter using a variable extractor set on a
request.
1. Create and validate a variable extractor for the parameter to be handled. Then go to the list of variable
extractors for the request by clicking on the "Advanced..." button and selecting the "Variable
extractors" tab.
2. Click the "Move as framework parameter" button to launch the Framework Parameter
Creation Wizard.
572
Tutorials
3. Enter the name of the framework parameter ("id" in this example) and select the framework name
(existing or specify a new framework name). Click "Next".
4. Set the dynamic parameter's replacement policy (automatically preconfigured by default). In our
example, NeoLoad has detected that the extracted dynamic parameter is used later on only for the
value of the "id" parameter. Click "Next".
5. This window allows you to apply the parameters to the requests in the current recording. Click
"Finish" to validate and start the search. The result of the scenario analysis is displayed after the
search step shown below.
573
Tutorials
6. Apply the changes (default option): this will set the variable extractors and inject the variables into
the parameters of the appropriate requests
Accessing framework parameters

The framework parameters can be accessed via NeoLoad's "Edit\Preferences\Dynamic
Parameters" menu item.
You can see here the list of existing parameters containing the default .NET framework parameters and
the recently-created "id" parameter.
574
Tutorials
Changes Implemented in the scenario

To conclude our case study, we just need to check that the changes have been implemented in the virtual
user's requests. In the next window, you can see that the values of the requests' "id" parameters no longer
contain the numerical values recorded, but the variables created using the framework.
In place of the value "1251988153222", we now have "${id}".
575
Tutorials
Remember that you may start a new automatic dynamic parameter search by clicking on the "Search"
button in the "Virtual Users" tab. Select the virtual user in the virtual user profiles tree. This makes
NeoLoad carry out a new search, including the new framework parameters.
Design - Technologies
Table of contents
SOAP: Testing Web Services

Adobe Flex/AMF: Handling External Libraries
Adobe Flex/AMF: Handling Polling and Streaming
Google Web Toolkit: Managing External Libraries
Java Serialization: Handling External Libraries
Oracle Forms: Designing a Scenario with Iterations
SOAP: Testing Web Services

This tutorial describes how to design a virtual user containing SOAP requests. It will show you three
different ways of creating SOAP requests in NeoLoad: from a WSDL file, from scratch, or from a recording
sequence.
To gain the most from this tutorial, it is recommended to have read the section on section "SOAP requests"
beforehand.

In the same way NeoLoad let's you define and load test HTTP interactions, NeoLoad provides the means to
load test SOAP requests. SOAP requests are in many ways similar to pure HTTP requests. This means that
all the features NeoLoad provides for HTTP requests will be available for SOAP. This includes, among
others, using variables, defining validation expressions and of course obtaining load test results. However
it is worthy to note that SOAP requests differ from HTTP request in several ways:
1. SOAP requests may not be associated to an HTML page the way HTTP requests are. If you record an
HTML page containing SOAP requests, these requests will be recorded and associated to the page. On
the other hand, if you record only SOAP requests, they will appear as standalone requests. More on this
subject in the section called “Recording a SOAP Request”.
2. Not belonging to an HTML page, independent SOAP requests have no associated Think Time. If you
want to test a sequence of SOAP calls, it is up to you to define delay actions to simulate latencies. For
more details on delay actions see the reference guide.
3. The way NeoLoad displays results differ from HTML pages and HTTP requests. More on this subject
in the section called “A Quick Tour on Analyzing SOAP Results”.
NeoLoad provides three ways of defining a SOAP request and are covered by one of the following sections:
1. the section called “Manually Defining a SOAP Request Based on a WSDL Definition”
2. the section called “Manually Defining a SOAP Request From Ground up”
3. the section called “Recording a SOAP Request”
Manually Defining a SOAP Request Based on a WSDL Definition

Our first example will use a web service provided by StrikeIron [http://www.strikeiron.com/sample/
CAPTCHA/Captcha.aspx], this service is a Text Disguise CAPTCHA-Image service. Provided you
576
Tutorials
register your email you'll be allowed to freely test the service. The WSDL is available at http://
ws.strikeiron.com/textdisguise/CaptchaService?WSDL.
A CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a
program that can generate images that most humans can see, but current computer programs can't. Many
applications need the security of knowing that the "thing" interacting with them is, in fact, a real live
person capable of thinking who is responsible for the interaction. Text Disguise solves this problem by
embedding a word into an image, distorted and is then shown to the user. The user has to confirm the value
entered into the box to continue.
The Text Disguise CAPTCHA-Image service defines two basic methods called GetNewWord and
ValidateImageWord. The first method, GetNewWord, expects no direct arguments. It returns a
captcha image identifier and a link to that image. The image can be displayed and the user prompted to
enter the text he or she sees in the image.
The second method, ValidateImageWord, expects two arguments, the text entered by the user and
the image identifier. The method returns true if the text is consistent with the image identifier and false
otherwise.
The HTTP request containing a call to the GetNewWord method looks like the following:
POST http://ws.strikeiron.com/textdisguise/CaptchaService
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.textdisguise.com/TextDisguise/CaptchaService/GetNewWord"
User-Agent: Jakarta Commons-HttpClient/3.0
Host: ws.strikeiron.com
Content-Length: 723
<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<ns1:LicenseInfo
xmlns:ns1="http://ws.strikeiron.com"
soapenv:actor="" soapenv:mustUnderstand="0">
<ns1:UnregisteredUser>
<ns1:EmailAddress>john.doe@dot.com</ns1:EmailAddress>
</ns1:UnregisteredUser>
<ns1:RegisteredUser>
<ns1:UserID/>
<ns1:Password/>
</ns1:RegisteredUser>
</ns1:LicenseInfo>
</soapenv:Header>
<soapenv:Body>
<GetNewWord
577
Tutorials
xmlns="http://www.textdisguise.com/TextDisguise/CaptchaService/">
<GetNewWord/>
</GetNewWord>
</soapenv:Body>
</soapenv:Envelope>
Several points are worth noticing:
• The HTTP request header defines the end point of the method, the address where the service resides, in
our example this is http://ws.strikeiron.com/textdisguise/CaptchaService.
• The HTTP request header contains a SOAPAction item.
• The HTTP request defines a text/xml content type.
• The SOAP header, soapenv:Header element, expects an nsl:unregisteredUser element that
must contain your email address.
• The SOAP body, soapenv:Body element only contains a reference to the invoked method
GetNewWord and has no parameters.
The previous points are noteworthy because most of these elements are generated by NeoLoad and based
on the WSDL definition, but as detailed in the following section, NeoLoad's user interface will let you
customize and configure all of them.
The following procedure describes the steps involved in creating a new SOAP request:
1. Creating and defining the SOAP request based on WSDL definition

2. Configuring the request (parameters)
3. Testing the request
1. Creating a SOAP Request
a. Select Design mode
b. Create a new virtual user
Right-click on the Virtual User profiles node and select New Virtual User.
Enter "VirtualUser", then click "OK".
c. Add a new SOAP request
Right-click on the virtual user just created and select "Insert into", then "SOAP
request".
d. Create the request from a WSDL definition
Check the Generate request using a WSDL file option and enter the URL of
that file. In our example the URL is: http://ws.strikeiron.com/textdisguise/
CaptchaService?WSDL. NeoLoad analyzes the WSDL and extracts the methods that can
be called.
578
Tutorials
Click Next.
e. Select the method to call
Based on the WSDL's definition, NeoLoad lists the methods that you can choose from. Here,
we'll select the CaptchaServiceSoap.GetNewWord method.
Click Next.
f. Define a request name
579
Tutorials
NeoLoad provides a default request name which it usually derives from the method name defined
in the WSDL. Most of the time you won't need to change this name. You might want to change
it if you use this call several times with different parameter and configuration values.
Click Next.
g. Define the service end point
This steps lets you define the address for invoking the specified service. The WSDL includes
this URL and most of the time you won't need to change this address. You might want to change
the endpoint to switch from a test environment to a production one.
Click Finish.
h. Check the main configuration elements
At this point, the SOAP request is added to the virtual user.
580
Tutorials
NeoLoad's right panel displays the main configuration elements of the SOAP request. This
includes the end point URL which is defined by both the Server and Path elements. These
elements, as mentioned earlier, have been extracted from the WSDL but can be changed to
custom values. As with HTTP requests, the Path element can been defined using NeoLoad
variables.
The WSDL element can equally be changed or reloaded. Reloading is particularly useful when
the SOAP request and it's associated WSDL are out of sync.
Warning
Reloading WSDL will re-initialize all previous configuration elements. All previously
defined parameters will be lost.
i. Check the HTTP headers
Most SOAP request require at least two HTTP header elements when SOAP is tunneled through
HTTP. Always make sure that these elements are correctly set. They are available in the
Advanced parameters dialog and are accessed by selecting the button:
In our example these elements are ContentType and SOAPAction. If your web service
framework requires additional HTTP header elements you can set them in the Advanced
parameters dialog.
2. Configuring the SOAP request
581
Tutorials
Before actually testing the SOAP request, additional elements including parameter values and
encoding types must be configured. Select the button to access the SOAP
configuration dialog.
a. Define the main parameters of the SOAP body
The Parameters tab let's you define the structure of the SOAP body. The tree structure in
the left most panel of the SOAP Parameters dialog displays the structure and content of
the SOAP body.
As mentioned earlier, the GetNewWord method expects no parameters or an empty so the tree
only has one root element called GetNewWord (an empty element as defined in the WSDL).
Had there been several elements or several possible elements, NeoLoad would have displayed
them in the tree. In our example no further configuration for the body is necessary.
b. Define the SOAP header
Select the Headers tab to define and configure elements related to the SOAP header. The
SOAP header elements are presented in exactly the same way as the SOAP body elements are.
The left most panel contains an XML tree displaying the structure and contents of the header of
the SOAP envelope. Adding and removing elements is achieved using the and, buttons.
Moving elements around is achieved using the and buttons
The structure contains either container elements, such as UnregisteredUser in our case, or
leaf elements such as EmailAddress. Container elements are meant to contain other elements.
Right clicking on them will pop up a menu from which you can choose to move the selected
element or add and remove child elements. NeoLoad will only suggest child elements that are
consistent with the WSDL definition.
Leaf elements on the other hand cannot contain other elements but have an associated value. In
our example you must enter a valid email address for the EmailAddress element.
582
Tutorials
For both container and leaf elements, you can define attribute names and attribute values. Again
attributes must be consistent with WSDL definition. Encoding allows special characters such
as '>', '<' or '&' to be encoded.
c. Configure advanced settings
The Advanced Settings panel let's you configure the binding styles of the SOAP request
and the format of attachments. This information has been extracted from the WSDL and you
should definitely be familiar with the types of bindings if you decide to change this setting.
d. View XML
The last tab of the SOAP Parameters dialog displays the actual XML content that will be
sent. NeoLoad generates its content on the fly using the XML elements and attributes you have
defined. Right clicking on the XML and selecting the Format as Pretty XML item will
display a neatly indented XML.
583
Tutorials
Tip
You can search the generated XML for a particular expression by right clicking on the
XML and selecting the Search ... item (or using the CONTROL + F shortcut keys).
3. Testing the SOAP request
By creating a temporary virtual user, NeoLoad provides an easy and quick method to check your
SOAP request. Select the button to open the Check Virtual User dialog.
• Start checking
If you have already tested Virtual Users using NeoLoad you will be familiar with the following
dialog. By selecting the Start checking button, NeoLoad will generate the SOAP request
and send it to the specified end point. NeoLoad displays the associated response code and the
number of failed assertions for the sent request. When the line associated to the request is selected
the dialog displays further details in the lower part of the dialog. You can choose to display the
SOAP request that was sent or the XML response.
584
Tutorials
Tip
You can search the SOAP request or the XML response for a particular expression by
right clicking on the XML and selecting the Search ... item (or using the CONTROL
+ F shortcut keys).
Tip
You can neatly format SOAP request or the XML response by right clicking on the
XML and selecting the Format as pretty XML item.
If you are following our example and testing it, the first time you'll send the request the response
will look like the following (the HTTP header has been omitted):
<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header/>
<soap:Body>
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>
Thank you for your attempt to try this Web service. Before the
free trial can occur,
you must first validate your email address.
Simply click on the link in the email that was just sent to you,
and you will then be able to invoke every Web service
within the StrikeIron Web Services Marketplace, including this one.
</faultstring>
585
Tutorials
<faultactor/>
</soap:Fault>
</soap:Body>
</soap:Envelope>
As indicated in the faultstring element, all you need to do to use the service a limited
amount of times is to validate the email address you sent by following the link that StrikeIron
has sent to you. Once your address is validated invoking the service should get you a response
such as the one that follows (the HTML header has been omitted):
<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
<Header xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<SubscriptionInfo xmlns="http://ws.strikeiron.com">
<LicenseStatusCode>1</LicenseStatusCode>
<LicenseStatus>Valid key</LicenseStatus>
<LicenseActionCode>0</LicenseActionCode>
<LicenseAction>Decremented hit count</LicenseAction>
<RemainingHits>4</RemainingHits>
<Amount>0</Amount>
</SubscriptionInfo>
</Header>
<soap:Body>
<GetNewWordResponse
<GetNewWordResult>
<CaptchaImageGuid>
82e16912-14c1-4253-bbcb-699585e3ba63
</CaptchaImageGuid>
<Url>
http://www.textdisguise.com/TextDisguise/CaptchaService/
CaptchaImage.aspx?
guid=82e16912-14c1-4253-bbcb-699585e3ba63
</Url>
</GetNewWordResult>
</GetNewWordResponse>
</soap:Body>
</soap:Envelope>
From this point on you can use the link defined by the URL element in an HTML page. As
detailed in the following section you can then use the ValidateImageWord method and the
CaptchaImageGuid to validate a text entered by the user.
Manually Defining a SOAP Request From Ground up

This section describes how to define a SOAP request based on some XML rather than starting on a WSDL
definition.
This will be illustrated by continuing our previous example and by invoking the ValidateImageWord
method. This method expects two parameters, an image identifier, the CaptchaImageGuid, returned
by the GetNewWord method and the text entered by a user. The ValidateImageWord method will
586
Tutorials
return true if the text entered by the user and the captcha image are consistent. The XML we will be
building our SOAP request on follows:
<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header>
<ns1:LicenseInfo
xmlns:ns1="http://ws.strikeiron.com"
soapenv:mustUnderstand="0">
<ns1:UnregisteredUser>
<ns1:EmailAddress>john.doe@dot.com</ns1:EmailAddress>
</ns1:UnregisteredUser>
<ns1:RegisteredUser>
<ns1:UserID/>
<ns1:Password/>
</ns1:RegisteredUser>
</ns1:LicenseInfo>
</soapenv:Header>
<soapenv:Body>
<ValidateImageWord
<captchaImageGuid>53fd3b31-1089-455b-a1b6-d78bc73f80b9</captchaImageGuid>
<word>SUBPRIMATE</word>
</ValidateImageWord>
</soapenv:Body>
</soapenv:Envelope>
1. Manually creating a SOAP Request
a. Select Design mode
b. Create a new virtual user
Right-click on the Virtual User profiles node and select New Virtual User.
Enter "VirtualUser", then click "OK".
c. Add a new SOAP request
Right-click on the virtual user just created and select "Insert into", then "SOAP
request".
d. Specify a manually-generated request
Check the Generate request manually option.
587
Tutorials
Click Next.
e. Enter a name for the request
Enter a name for the manually-defined request.
In our example we'll name the request ValidateImageWord.
Click Next.
f. Define the end-point of the request
This is the URL where the service is located. You can also change this later on. In our
example the service end point is http://ws.strikeiron.com:80/textdisguise/
CaptchaService.
588
Tutorials
Click Finish.
g. Check main configuration elements
At this stage the SOAP request is added to the virtual user. You can rename this node to your
convenience. In our example a ValidateImageWord node has been added at the end of the
existing SOAP requests.
NeoLoad's right panel displays the main configuration elements of the SOAP request. This
includes the end point URL which is defined by both the Server and Path elements. These
elements can be changed to custom values. As with HTTP requests, the Path element can been
defined using NeoLoad variables.
h. Check the HTTP headers
Most SOAP request require at least two HTTP header elements when SOAP is tunneled through
HTTP. Always make sure that these elements are correctly set. They are available in the
Advanced parameters dialog and are accessed by selecting the button:
589
Tutorials
In our example these elements are ContentType and SOAPAction.
2. Configuring the XML content
To configure the XML content, select the Edit XML Content button.
At this stage you must define the XML request either by copying and pasting a request you have
tested or by manually defining each element and attribute of the request. We will be using the first
method in our example.
Copying and pasting an existing XML request using the Flat XML panel is the easiest way to define
the XML content of the request. In our example we have copied and pasted the XML containing the
call to the ValidateImageWord method:
You could also use the XML Tree panel to manually define or to edit the XML using elements and
attributes. NeoLoad automatically constructs one view from the other (the XML tree view from the
flat view and vice versa). Selecting the XML Tree tab would look like the following:
590
Tutorials
At this stage the request is completely defined and configured, you can immediately start testing it.
3. Testing the SOAP request
By creating a temporary virtual user, NeoLoad provides an easy and quick method to check your
SOAP request. Select the button to open the Check Virtual User dialog.
• Start checking
If you have already tested Virtual Users using NeoLoad you will be familiar with the following
dialog. By selecting the Start checking button, NeoLoad will send the SOAP request to
the specified end point. NeoLoad displays the associated response code and the number of failed
assertions for the sent request. When the line associated to the request is selected the dialog
displays further details in the lower part of the dialog. You can choose to display the SOAP
request that was sent or the XML response.
591
Tutorials
Tip
You can search the SOAP request or the XML response for a particular expression by
right clicking on the XML and selecting the Search ... item (or using the CONTROL
+ F shortcut keys).
Tip
You can neatly format SOAP request or the XML response by right clicking on the
XML and selecting the Format as pretty XML item.
Using the Variable Extractor

Based on the two previous examples, this section briefly shows you how, just as for HTML
requests, NeoLoad's variable extractor mechanism can be used with SOAP requests. The objective
is to be able to record a series of invocations on the GetNewWord and ValidateImageWord
requests. Each GetNewWord invocation will return a new image identifier, the corresponding call to
ValidateImageWord will contain the associated identifier.
592
Tutorials
The basic idea is to
1. extract into a variable the image identifier, in other words the CaptchaImageGuid, from
GetNewWord's response
2. and then, re-inject the value of the variable when invoking the ValidateImageWord request.
1. Extracting the image identifier CaptchaImageGuid from GetNewWord's response
a.
Go to Design Mode by selecting the button
b. Select the Virtual users tab
c. Unfold the appropriate virtual user node
d. Select the GetNewWord request from which the image identifier value will be extracted:
e. Go to the Variable extractors tab
i.
Open the Advanced settings dialog by selecting the button.
ii. Select the Variable extractors tab:
593
Tutorials
f. Define a new variable
Select the button to add a new variable. This opens a Variables Extractor dialog.
In our example we will define the captchaImageGuid variable . The way the value is
identified and extracted is quite straightforward since the XML response is simple. We want
to extract anything appearing between the starting <captchaImageGuid> and ending </
captchaImageGuid> XML tags. The following screen shot reflects these decisions:
594
Tutorials
At this stage the extraction part of the process is complete. Each time the GetNewWord
is invoked NeoLoad will extract the value of the image identifier and set the
captchaImageGuid variable with it.
For more details on extracting variables refer to the section called “Creating a Variable
Extractor” and to the reference guide.
2. Re-injecting the value into the ValidateImageWord request using a variable
a. Select the ValidateImageWord request in which the image identifier value will be injected.
b. Select the Edit XML Content button to configure the XML content.
c. Select the XML Tree tab
d. Select the captchaImageGuid element in the XML panel
e. Select the Variable Picker dialog using the ... button. You can also start typing
something like ${c and NeoLoad will suggest variable name completions.
f. Choose the captchaImageGuid variable
The XML Content dialog should look like the following:
595
Tutorials
With such a configuration NeoLoad will extract the image identifier from the GetNewWord
response and inject it in the ValidateImageWord request. This sequence can be replayed
multiple times.
Recording a SOAP Request

This section illustrates another means of defining SOAP request. Of all the techniques we have detailed
up to now, it is the one that resembles the most what you usually do with HTTP requests: acting as a user
and letting NeoLoad do the job of recording requests and responses. Our example uses the Google search
API, so if you want to play around with this API you'll need to create an account and obtain a license key,
you can go to the following URL Google APIs [http://www.google.com/apis/].
Example Description
The example is basic and really simple so that the underlying mechanisms are made clear:
596
Tutorials
The HTML page we will be recording consists of a Test button and a textarea containing the request
to send. Hitting the Test button sends the request to the correct end point, the response is then displayed
in the textarea. The request contains an invocation to the Google search API. The body of the request
contains among others, an XML key element which you will have to obtain from Google. The XML q
element is the text we are actually searching for. In our very basic interface we can change this by editing
the textarea content before invoking the request.
The JavaScript code that manages the request opens the service end point, consistently sets the HTTP
headers and sends the content of the textarea. When the response is received it's content is copied to
the textarea. Note the code only works with Microsoft Internet Explorer. Other browsers will in any
case refuse to connect to a URL not belonging to the same domain as the test page.
The following listing contains the SOAPTest.html code and the code of the function called when the Test
button is hit:
<html>
<body>
<h1>Google</h1>
<script type="text/javascript">
function doIEGoogle() {
textarea = document.getElementById("debugbox");
xhr = new ActiveXObject("Microsoft.XMLHTTP");
xhr.open('POST', "http://api.google.com/search/beta2");
xhr.setRequestHeader("SOAPAction", "urn:GoogleSearchAction");
xhr.setRequestHeader("Content-Type", "text/xml; charset=utf-8");
xhr.onreadystatechange =
function() {
if(xhr.readyState != 4) return;
597
Tutorials
if(xhr.status != 200) {
textarea.value = xhr.status + " " + xhr.statusText
+ "\n" + xhr.responseText;
return;
}
textarea.value = xhr.responseText;
};
xhr.send(textarea.value);
}
</script>
<form name="input" action="javascript:doIEGoogle()">

<input type="submit" value="Test">
</form>
<p></p>
<textarea rows="30" cols="100" name="debugbox">

<?xml version='1.0' encoding='UTF-8'?>
<SOAPENV:Envelope
xmlns:SOAPENV="http://schemas.xmlsoap.org/soap/envelope/"
<SOAPENV:Body>
<ns1:doGoogleSearch
xmlns:ns1="urn:GoogleSearch"
SOAPENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<key xsi:type="xsd:string">ABQIAAAA-YwsmHQspwIU9OcKL4b5rhTd9gLE95ZWCg
lQjFVS1XYlL9GwFBSIRS2y1JQBK8NE1ktm1oJWkWiTZQ</key>
<q xsi:type="xsd:string">load testing web applications</q>
<start xsi:type="xsd:int">0</start>
<maxResults xsi:type="xsd:int">3</maxResults>
<filter xsi:type="xsd:boolean">false</filter>
<restrict xsi:type="xsd:string"/>
<safeSearch xsi:type="xsd:boolean">false</safeSearch>
<lr xsi:type="xsd:string"/>
<ie xsi:type="xsd:string"/>
<oe xsi:type="xsd:string"/>
</ns1:doGoogleSearch>
</SOAPENV:Body>
</SOAPENV:Envelope>
</textarea>
</body>
</html>
Recording the Page
598
Tutorials
To record this test page we follow exactly the same procedure as when recording an HTML page. From
there we selected the Test button and waited for the results from the Google search API. We ended the
recording at this stage. The following screen shot depicts what the result of the recording looks like:
The recorded node contains a node called /search/beta2.
Important
As they do not belong to an HTML page, independent SOAP requests have no associated Think
Time. If you want to test a sequence of SOAP calls, it is up to you to define delay actions to
simulate latencies. For more details on delay actions see the reference guide.
NeoLoad has correctly identified the request as a being a SOAP request: the URL, Server, Path and
Method properties of the request are consistently set.
Editing the SOAP Request
If you select the Edit XML Content button and choose the XML Tree Tab, you can easily browse
through the SOAP request elements. This is typically where you could use variables, changing for instance
the search text for the q parameter:
599
Tutorials
Checking the SOAP Request
As for any SOAP request, you can test the recorded request by selecting the button to open
the Check Virtual User dialog:
In our simple example, the Java script code just fills in the textarea with the received XML. In a real world
scenario, the HTML page would obviously do otherwise, it would probably analyze the results, display
them neatly in HTML and then let the user navigate on those results. Keep in mind that NeoLoad, just as
for HTML requests, will let you extract information from the SOAP response and inject that information
in further requests.
Recording from a real client
The previous sample shows how to record the request using a web browser. Please report to the reference
guide to see how recording from your existing SOAP client.
600
Tutorials
A Quick Tour on Analyzing SOAP Results

Contrary to HTTP requests, which always belong to an HTML page, SOAP request are defined and
managed by NeoLoad outside HTML pages. This has a particular consequence in the way NeoLoad
displays the results. If you have defined a scenario that includes SOAP requests, these requests will not
be detailed in the summary.
In our case the scenario only contains the HTML test page called SOAPTest.html. If you take a look
at the Test Summary this is what you will get:
As depicted in the following screen shot, it is only in the Values tab that you will see statistics on the
SOAP request, in our example the /search/beta2 request. Of course all graphing functionalities are
equally available for SOAP requests (Graphs tab).
Adobe Flex/AMF: Handling External Libraries

This tutorial describes how to design a virtual user containing Adobe Flex/AMF requests. It introduces
you to the Post-Recording Wizard, which is used to instruct NeoLoad how to decode the Adobe Flex/
601
Tutorials
AMF requests. If you do not have all the required files during the recording, this tutorial explains how to
repair Adobe Flex/AMF requests that could not be decoded.
To gain the most from this tutorial, it is recommended to have read the following sections beforehand:
• Adobe Flex/AMF Optional Module
• Project AMF Library Manager
• AMF Module General Preferences

In the same way that it allows HTTP exchanges to be defined and tested, NeoLoad also provides a method
of load testing AMF requests. AMF requests are similar in many ways to standard HTTP requests. This
means that all the NeoLoad features available for testing HTTP requests can also be used for AMF requests.
These include, among others, the use of variables, defining validations and, of course, obtaining results
for the tests.
Recording AMF0 Requests

To record AMF requests, just follow the standard procedure for recording a scenario.
Here's an example of an AMF0 request recording:
Note
• The AMF requests are marked in the virtual user by a icon that resembles the Adobe Flash
logo.
• The protocol version used by the AMF request can be seen in the request itself.
<version>0</version> indicates an AMF0 message.
Recording AMF0 requests is straightforward and requires no configuration.
Recording AMF3 Requests

To record AMF requests, just follow the standard procedure for recording a scenario.
602
Tutorials
For the record, the AMF3 protocol enables the carrying of customized objects. If the Java object classes
are missing, the request's binary data cannot be decoded for conversion to XML. The following procedure
explains how to solve the problem of missing Java classes.
Note
In Java, an object is termed externalizable when it implements the
java.io.Externalizable interface. These objects are particular, in that they manage the
saving and restoring of their attribute values themselves. Declaring these Java classes using
Adobe Flex/AMF libraries manager is mandatory.
When you close the browser, the Post-Recording Wizard is displayed:
Select the JAR/XML files to declare. Repeat the operation as required.
603
Tutorials
Once all the necessary JAR/XML files have been loaded successfully, the following screen is shown:
For further details of the next steps in the wizard, please refer to the documentation on the Post-Recording
Wizard.
604
Tutorials
Fixing an AMF3 Request Post-Recording

The JAR files required by an AMF request may be declared at any time.
Here, the request selected in the virtual user requires Java classes that haven't been declared yet. This fact
is revealed by several indicators:
•
The request's icon in the virtual user .
• The request contains unexpected characters, instead of XML.
• A link (in blue) indicates that the AMF Java libraries for this request are missing.
Click on the link (or use the "Edit / Preferences", "Project settings" and "Libraries
Manager" and the "Adobe Flex/AMF" tab) to declare the required AMF Java libraries: the following
screen is displayed.
605
Tutorials
Click the "+" button to open the file explorer. Select the JAR file to declare.
If the JAR/XML file loads correctly, a dialog box confirms that the AMF library has been successfully
declared:
606
Tutorials
The loaded JAR/XML file appears in the list and a message informs you that the process was successfully
completed. If the request is correctly converted to XML format, it should appear as follows:
If the request still hasn't been converted to XML format, it means that some required JAR files still have
not been declared. Repeat the operation as many times as is necessary.
Adobe Flex/AMF: Handling Polling and Streaming

This tutorial describes how to design a realistic virtual user containing Adobe Flex/AMF requests based on
Adobe Live Cycle Data Services (LCDS). It shows the modeling in NeoLoad of the two standard
ways of refreshing data from the Flash client, notably polling and streaming (also called "Push"). At the
607
Tutorials
end of the tutorial, you will also find an example of advanced design, with details on how to extract and
interpret data returned by a server via a streaming channel.
To gain the most from this tutorial, it is recommended to have read the "Adobe Flex/AMF: Handling
External Libraries" tutorial beforehand.
Understanding the context

NeoLoad allows you to load test AMF requests. These requests are based on standard HTTP interactions.
In most web applications, the request for data comes from the client (the web browser). In other words, it's
the user who requests information either by clicking on a link or performing some other action. In some
cases however, the server needs to send information to the client without the user requesting it. Typical
examples of this are a server-initiated events such as alert messages and data updates.
Flex servers using the AMF protocol update client data in two ways:
1. the polling method: This involves the browser querying the server at regular intervals. Technically
simple in its implementation, the method's downside is that it needlessly overloads the server and it
is not very reactive.
2. the streaming, or "push" method: In this case, the client sends a single request to the server, and
the server responds when pertinent information is available, without closing the request. Thus, the
server can again send information to the client using the same connection, without having to wait for
a new request. Using this method, client data can be rapidly updated while the network traffic is kept
minimized.
Polling and streaming require the use of specific NeoLoad requests to be able to handle these transaction
modes. See the section called “Defining a virtual user using streaming-type AMF Requests”.
Defining a virtual user using polling-type AMF requests

We're going to use an example provided by Adobe and included in LCDS (http://www.adobe.com/
products/livecycle/dataservices/). Follow the installation instructions and then start the
LCDS server. Then, go to the following URL: http://localhost:8400/lcds-samples/
traderdesktop/startfeed.jsp. This page activates a stock price fluctuation simulation.
The steps involved in creating a virtual user that uses AMF polling are:
1. Recording the scenario
2. Defining the virtual user
3. Checking the virtual user's validity
4. Viewing a load test that includes polling requests
a. Start recording
In the NeoLoad main window, click the button in the toolbar. Enter UserPolling in the
"Name" field.
b. Access the application
The web browser opens. Enter the following URL: http://localhost.:8400/lcds-

samples/traderdesktop/index.html
608
Tutorials
c. Select nio polling mode
Select "my-nio-amf-poll" mode. This corresponds to an operating mode using polling

HTTP requests through NIO sockets directly handled by LCDS.
By default, the operating mode selected is my-rtmp . This corresponds to an operating mode
using the RTMP protocol. Currently NeoLoad does not support this protocol.
d. Note the polling operating mode
The my-nio-amf-poll mode corresponds to an operating mode using polling requests.

The average delay between these requests is 3 seconds. This means there will be a minimum 3
second delay between two updates of the "Watch List". Please wait twenty seconds or so
(in other words, 7 refresh cycles).
e. Stop recording
Close the browser, then click "Stop". The Post-Recording Wizard displays the "Push
Application" window:
609
Tutorials
NeoLoad has detected that the recorded virtual user has used Push "AMF polling". Click
"Finish".
The Post-Recording Wizard creates the "UserPolling_AMF" virtual user from the recorded
virtual user.
f. Check the recording
The "UserPolling" user contains the raw recording of the requests.
Select the "UserPolling_AMF" virtual user, right-click, then select "Show all". The
polling request appears in the "polling_loop" loop under the "push_fork" fork.
610
Tutorials
The Push messages are located in the "POLL_3" polling request. The
"flex.samples.marketdata.Stock" message is a Push message executed each time a
response message contains a "flex.samples.marketdata.Stock" -type object.
a. Extracting and displaying the received stock symbol
First, we need to set a variable extractor on the Push message to extract the symbol:
1. Select the "flex.samples.marketdata.Stock" Push message, then click

"Advanced...".
2. Create a variable extractor.
3. Enter "Symbol" in the "Variable name" field.
4. Check the "XPath Expression" box and enter "//symbol" in the corresponding field.
5. Enter ">" in the "Starts with" field.
6. Enter "<" in the "Ends with" field.
7. Click "OK" to create the variable extractor.
611
Tutorials
Create a JavaScript action in "messageFork_1" located in the

"flex.samples.marketdata.Stock" Push message and enter the following JavaScript
code:
logger.debug("STOCK = "+ context.variableManager.getValue("symbol"));
The JavaScript action will display the stock symbol extracted from the message.
b. Keep the appropriate Push messages
This virtual user is only interested in the stock symbols received.

Delete the "flex.messaging.messages.AcknowledgeMessageExt" and
"DefaultMessage" Push messages.
3. Validating the virtual user
a. Go to the Virtual User Validation section
In the NeoLoad main window, click the button in the toolbar.
b. Configure the think time playback
Click the "Advanced..." button in the validation window. Check the "Play think time"
box, then click OK.
c. Start the virtual user validity check
Click the button in the validation window.
d. Check the server responses
Several polling requests and Push messages have been executed. Click on any one of them
to check its contents. With a Push message selected, click "Response".
612
Tutorials
The speed of execution in the validation check playback is real; this avoids submitting the server
to too high a polling rate. In testing, 3 seconds minimum separate each polling request.
NeoLoad allows you to work on an XML representation of the objects passing through the
server. In this example, we can see the XML representation of an instance of the example class
flex.samples.marketdata.Stock returned by the server.
<body class="ASObject" mappedClass="flex.samples.marketdata.Stock">

<open tagClass="double">33.61</open>
<last tagClass="double">32.41972272641574</last>
<symbol tagClass="String">GE</symbol>
<name tagClass="String">General Electric Company</name>
...
</body>
Here's an extract of the associated Java class:
package flex.samples.marketdata;
import java.util.Date;
public class Stock {

protected double open;
protected double last;
protected String symbol;
protected String name;
...
public double getOpen() {
613
Tutorials
return open;
}
public void setOpen(double open) {
this.open = open;
}
public double getLast() {

return last;
}
public void setLast(double last) {
this.last = last;
}
public String getSymbol() {

return symbol;
}
public void setSymbol(String symbol) {
this.symbol = symbol;
}
public String getName() {

return name;
}
public void setName(String name) {
this.name = name;
}
4. Viewing a load test that includes polling requests
a. Go to the Population Definition section
In the NeoLoad main window, click
b. Define the default population
In the Population Creation Wizard, click "OK" .
c. Go to the Load Policy section
Click
d. Define the load policy
Enter 10 in the "Simulated users" field. NeoLoad will launch 10 virtual users using
polling.
e. Start the test
Click the button in the toolbar. Then click "OK". The test starts. Wait 2 minutes.
f. Results
The test results allow you to check the server's performance for each Push message.
614
Tutorials
Defining a virtual user using streaming-type AMF Requests

We'll use the same example as before, namely one provided by Adobe and included in LCDS
(http://www.adobe.com/products/livecycle/dataservices/). Follow the installation
instructions and then start the LCDS server. Then, go to the following URL: http://
localhost:8400/lcds-samples/traderdesktop/startfeed.jsp. This page activates
the stock price fluctuation simulation.
The steps involved in creating a virtual user that uses AMF streaming are:
3. Validating the virtual user
615
Tutorials
4. Viewing a load test that includes a streaming request.
5. To learn more, see Virtual User Advanced Definition below.
a. Start recording
In the NeoLoad main window, click the button in the toolbar. Enter "UserStreaming"
in the "Name" field and click "OK".
b. Access the application
The web browser opens. Enter the following URL: http://localhost.:8400/lcds-

samples/traderdesktop/index.html
c. Change the operating mode to "streaming"
The my-rtmp operating mode is selected by default. Change the mode to my-nio-amf-
stream in the list to apply the operating mode for streaming requests. This corresponds to an
operating mode with streaming requests through NIO sockets . NIO sockets are used to break the
relationship between the number of streaming channels opened and the number of used threads
on the server side.
In streaming mode, the server refreshes the displayed data when it decides it is necessary. You
can see the difference in refreshment rate compared with polling mode. Please wait ten
seconds or so.
d. Stop the recording
Change back to the my-rtmp mode in order to shut down the streaming. Close the browser,
then click on "Finish".
e. Check the recording
616
Tutorials
Click on the "UserStreaming_AMF" user, then right-click and select Show
all. There are 2 streaming requests (identified by the icon) named /

nioamfstream;AMFSessionId=XXX open and /nioamfstream close, one to
open streaming and one to close it.
Click on the "UNSUBSCRIBE..." page and set the think time for the page to 10000ms. In an
advanced scenario, you could make the think time dynamic using a random variable, setting a
maximum and minimum think time.
f. Check the "streaming open" request
Unlike polling mode, just one request is sent to the server in this mode. The server sends
data back in a response when it decides it's appropriate, until it closes the connection when
streaming is finished. These different response data groups are stored by NeoLoad as several
responses.
Select the /nioamfstream;AMFSessionId=XXX open request. Click on the

"Advanced" button. In the dialog box, select the "Recorded response" tab. Finally, in
the left-hand panel, select one of the responses. NeoLoad displays a list of all the responses sent
by the server during the streaming request's recording.
617
Tutorials
a. Extracting and displaying the received stock symbol
First, we need to set a variable extractor on the Push message to extract the symbol:
1. Select the "flex.samples.marketdata.Stock_1" Push message, then click

"Advanced...".
2. Create a variable extractor.
3. Enter "Symbol" in the "Variable name" field.
4. Check the "XPath Expression" box and enter "//symbol" in the corresponding field.
6. Enter "<" in the "Ends with" field.
7. Click "OK" to create the variable extractor.
Create a JavaScript action in "messageFork_2". Delete the existing JavaScript code and
enter the following:
logger.debug("STOCK = "+ context.variableManager.getValue("symbol"));
The JavaScript action will display the stock symbol extracted from the message.
b. Keep the appropriate Push messages
618
Tutorials
This virtual user is only interested in the stock symbols received. Delete the
"flex.messaging.messages.AcknowledgeMessageExt", "String" and
"DefaultMessage" Push messages.
3. Checking the virtual user's validity
a. Go to the Virtual User Validation section
In the NeoLoad main window, click the button in the toolbar.
b. Configure the think time playback
Click the button in the validation window. Check the "Play think
time" box, then click OK..
c. Start the virtual user validity check
Select "UserStreaming" in the "Virtual Users" list. Then click the

button in the validation window.
d. Check the server responses
The same streaming request appears several times. Only one request was issued for this virtual
user, but the server regularly sends back partial responses. When each partial response is
received, a line is added to the list of played requests, together with its content. Click on one to
check the contents. When the request is selected, click on "Response".
4. Viewing a load test that includes a streaming request
619
Tutorials
a. Go to the Population Definition section
b. Define the default Population
In the Population Creation Wizard, click OK.
c. Go to the Load Policy section
Click
d. Define the load policy
Enter 10 in the "Simulated users" field. NeoLoad will launch 10 virtual users using
streaming.
e. Start the test
Click the button in the toolbar. Then click "OK". The test starts. Wait 2 minutes.
f. Results
As the test proceeds, NeoLoad clearly shows the speed of this architecture, with a considerable
number of responses being received by each virtual user. Streaming also provides very fast
response times. However, its use implies greater server-side resources than are required for
polling and, therefore, a reduced capacity in handling simultaneous users.
5. Virtual user advanced definition
We shall continue with the previous example, this time focusing on the content of the response to the
streaming request. We shall see how NeoLoad extracts part of the content sent by the server and help
620
Tutorials
us make decisions. Here is the proposed scenario: when the value of the General Electric (symbol
GE) stock rises above 31, a log is displayed and the virtual user stops.
a. Go to the Virtual user profiles
b. Edit the Push message conditions
Select the "flex.samples.marketdata.Stock_1" Push message in the tree. In the

"Settings" section, select "Conditions", then "Resolve all the following
elements".
Click "+" to set the new condition "${NL-MessageContent}"

"contains""<String>GE</String>".
The Push message is now configured to execute only when an update for the "GE" stock is
received.
c. Extract the received stock's value
Select the "flex.samples.marketdata.Stock_1" Push message, then click

"Advanced...". Create a variable extractor:
1. Enter "GE_last" in the "Variable name" field.
2. Check the "XPath Expression" box and enter "//last" in the corresponding field.
4. Enter "." in the "Ends with" field.
d. Check the variable extractor's validity
Lastly, check the extraction results. The "Value extracted from the recorded
page" field at the bottom of the variable extractor definition window must contain a number.
Click "OK" to confirm, then click "OK" again.
e. Define a condition block for GE_last > 31
Drag and drop the If...Then...Else logical action under /

nioamfstream;AMFSessionId=XXX open page. Double-click on the "Operand1"
field, then click on and select "GE_last". Click "OK". In the "Operator" field, select
"is greater than". In the "Operand2" field, enter "31". This condition block will only
be true when the quote for the General Electric stock is above 31.
621
Tutorials
f. Virtual user actions when GE_last > 31
In the "Then" condition, drag and drop the JavaScript logical action. Erase the default
code and replace it with:
context.variableManager.setValue("end","true");
Drag and drop the "Wait until" logical action just before the "UNSUBSCRIBE..." page.
Set the maximum delay to 60000ms and set the action's "${end}" "is equal to" "true"
condition to "wait until".
Delete the "end_delay_3" action.
Set the think time for the "UNSUBSCRIBE..." and "/nioamfstream close_1" pages to
0ms.
g. Check the virtual user's validity
Click on the button in the NeoLoad toolbar. Select "UserStreaming" in the "Virtual
Users" list. Next, click on the button in the validation window. The
validation process is run until the GE stock reaches 31, or until the "wait until" action
times out (think time for the UNSUBSCRIBE page). In the above example, the GE stock has
reached 34, triggering the JavaScript and ending the virtual user.
622
Tutorials
Adobe RTMP : Handling External Libraries

This tutorial describes how to design a virtual user containing Adobe RTMP requests. It introduces you to
the Post-Recording Wizard, which is used to instruct NeoLoad how to decode the Adobe RTMP requests.
If you do not have all the required files during the recording, this tutorial explains how to repair Adobe
RTMP requests that could not be decoded.
• Adobe RTMP Optional Module
• Project RTMP Library Manager

In the same way that it allows HTTP exchanges to be defined and tested, NeoLoad also provides a method
of load testing RTMP requests. RTMP requests are similar in many ways to standard HTTP requests.
This means that all the NeoLoad features available for testing HTTP requests can also be used for RTMP
requests. These include, among others, the use of variables, defining assertions and, of course, obtaining
results for the tests.
Recording RTMP requests

To record RTMP requests, just follow the standard procedure for recording a scenario and check RTMP
in the recorded protocols.
Warning
There are certain limitations regarding the recording of RTMP applications in NeoLoad. See the
recording limitations for more information.
623
Tutorials
For the record, the RTMP protocol enables the carrying of data including customized objects (encoded
using AMF protocol), audio and/or video. If the Java object classes are missing, the request's binary data
cannot be decoded for conversion to XML. The following procedure explains how to solve the problem
of missing Java classes.
Note
In Java, an object is termed externalizable when it implements the
java.io.Externalizable interface. These objects are particular, in that they manage the
saving and restoring of their attribute values themselves. Declaring these Java classes using
Adobe RTMP libraries manager is mandatory.
When you close the browser, the Post-Recording Wizard ir displayed:
Select the JAR files to declare. Repeat the operation as required.
624
Tutorials
Once all the necessary JAR files have been loaded successfully, the following screen is shown:
During recording, NeoLoad detects that RTMP channels have been created and offers to create a copy of
the virtual user that will allow the scenario to be run. The RTMP channels are blocking actions pending
reception of the server's messages. To be able to simulate a user using RTMP, we need to create this
simplified virtual user. See the documentation on RTMP channels for more information.
When copying the virtual user, NeoLoad inserts the RTMP channels in Fork actions and creates the various
types of Push message received during the recording.
625
Tutorials
Wizard.
Fixing an RTMP request after recording

The JAR files required by an RTMP request may be declared at any time.
Here, the request selected in the virtual user requires Java classes that haven't been declared yet. This fact
is revealed by several indicators:
•
626
Tutorials
• A link (in blue) indicates that the RTMP Java libraries for this request are missing.
Click on the link (or use the "Edit / Preferences", "Project settings" and "Libraries
Manager" and the "Adobe RTMP" tab) to declare the required RTMP Java libraries: the following screen
is displayed.
627
Tutorials
If the JAR file loads correctly, a dialog box confirms that the AMF library has been successfully declared:
The loaded JAR file appears in the list and a message informs you that the process was successfully
completed. If the request is correctly converted to XML format, it should look like this:
Google Web Toolkit: Managing External Libraries

This tutorial describes how to design a virtual user containing Google Web Toolkit requests. It introduces
you to the Post-Recording Wizard, which is used to instruct NeoLoad how to decode the GWT requests.
628
Tutorials
If you do not have all the required files during the recording, this tutorial explains how to repair GWT
requests that could not be decoded.
• The GWT Optional Module
• The Project's GWT Library Manager

In the same way that it allows HTTP requests to be defined and tested, NeoLoad also provides a method of
load testing GWT Web applications. GWT requests are similar in many ways to standard HTTP requests.
This means that all the NeoLoad features available for testing HTTP requests can also be used for GWT
requests, for example the use of variables or defining validations on the server's response.
Recording GWT Requests

To record GWT requests, just follow the standard procedure for recording a scenario.
To recap, the GWT-RPC protocol allows the exchange of custom Java objects. If the classes are missing for
the sent Java objects, the request's binary data cannot be decoded for conversion to XML. The following
procedure explains how to resolve the problem of missing Java classes.
Note
With GWT, an object is said to be serializable when it implements
the java.io.Serializable interface (from GWT 1.5 onwards) or the
com.google.gwt.user.client.rpc.IsSerializable interface (for earlier
versions).
Note
For NeoLoad to be able to decode the GWT requests and responses, the following elements are
required: the RPC services' client interfaces, the objects exchanged between the server and client
and the other referenced classes.
629
Tutorials
Select the JAR files containing the missing serializable Java classes. Repeat the operation as many times
as is necessary.
When all the required JAR files have been declared, the following screen is displayed:
630
Tutorials
Wizard.
Fixing a GWT Request Post-Recording

The JAR files required by a GWT request may be declared at any time.
Here, the request selected in the virtual user requires Java classes that are not available. This fact is revealed
by several indicators:
•
• A link (in blue) indicates that the GWT Java libraries for this request are missing.
631
Tutorials
Click on the link prompting you to declare the required GWT Java libraries. This takes you to the following
screen (you may also use the "Edit / Preferences"menu item, then select "Project Settings",
"Libraries Manager" and the "Google Web Toolkit" tab).
632
Tutorials
If the JAR file loads correctly, a dialog box confirms that the GWT library has been successfully declared.
The loaded JAR files appears in the list and a message informs you that the process was successfully
completed. Once the request is correctly decoded into XML , it appears in XML format.
633
Tutorials
Java Serialization: Handling External Libraries

This tutorial describes how to design a virtual user containing Java Serialization requests. It introduces
you to the Post-Recording Wizard, which is used to instruct NeoLoad how to decode the Java Serialization
requests. If you do not have all the required files during the recording, this tutorial explains how to repair
Java Serialization requests that could not be decoded.
• The Java Serialization Optional Module
• The Project's Java Serialization Library Manager

In the same way that it allows HTTP requests to be defined and tested, NeoLoad also provides a method
of load testing web applications programmed in Java using specific frameworks such as Spring Remoting
(Spring's HTTP Invoker). Java Serialization requests are similar in many ways to standard HTTP requests.
This means that all the NeoLoad features available for testing HTTP requests can also be used for Java
Serialization, including the use of variables and assertions on the server's responses.
Recording Java Serialization requests

To record Java Serialization requests, just follow the standard procedure for recording a scenario.
Specific frameworks such as Spring Remoting (Spring's HTTP Invoker) allow to transport customized Java
objects encapsulated in the HTTP protocol. If the Java object classes are missing, the request's binary data
cannot be decoded for conversion to XML. The following procedure explains how to solve the problem
of missing Java classes.
Note
For Java Serialization, an object is said to be serializable when it implements the
java.io.Serializable interface or the java.io.Externalizable interface.
634
Tutorials
Note
For NeoLoad to be able to decode the Java Serialization requests and responses, the following
items are required: the JARs for the framework used to transport the customized Java objects, the
customized Java objects exchanged between the server an client and the other referenced classes.
Select the JAR for the framework used to transport the customized Java objects.
635
Tutorials
Select the JAR files containing the missing serializable Java classes. Repeat the operation as many times
as is necessary.
When all the required JAR files have been declared, the following screen is displayed:
636
Tutorials
Wizard.
Fixing a Java Serialization request after recording

The JAR files required by a Java Serialization request may be declared at any time.
Here, the request selected in the virtual user requires Java classes that are not available. This fact is revealed
by several indicators:
•
• A link (in blue) indicates that the Java Serialization libraries for this request are missing.
637
Tutorials
Click on the link prompting you to declare the required Java Serialization libraries. This takes you to the
following screen (you may also use the "Edit / Preferences"menu item, then select "Project
Settings", "Libraries Manager" and the "Java Serialization" tab).
If the JAR file loads correctly, a dialog box confirms that the Java Serialization library has been
successfully declared.
638
Tutorials
The loaded JAR files appears in the list and a message informs you that the process was successfully
completed. Once the request is correctly decoded into XML , it appears in XML format.
Oracle Forms: Designing a Scenario with Iterations

This tutorial describes how to design a virtual user executing iterations on Oracle Forms requests. It
presents an actual case using NeoLoad on an Oracle Forms demo application. It describes in detail how to
create a virtual user that repeats a same business transaction several times over.
To gain the most from this tutorial, it is recommended to have read the "Oracle Forms User Guide".
639
Tutorials

With NeoLoad, designing a scenario for an Oracle Forms application is very quick. Where the Oracle
Forms application's usage requires that a dynamic element be added, NeoLoad allows you to use logical
actions, in particular the inclusion of a loop in the virtual user design.
With an Oracle Forms application, it is vital to take this requirement into account in the initial phases of
the scenario design. In the next sections, we shall look in detail at the best practices to be observed, using
iOrganizer, a demo application for the Oracle Forms 10g server.
Prerequisites
Installing the Demo Applications
In this case, we're going to use the iOrganizer application, one of the demo applications for the Oracle
Forms 10g server.
The demo applications can be downloaded at the following URL: http://www.oracle.com/

technology/sample_code/products/forms/index.html, in the Oracle Forms 10gR2
Demos section. Once the applications have been installed on your Oracle Forms server, connect
to the following URL: http://<server>:8889/forms/frmservlet?config=iorg where
<server> is the name of the Oracle Forms server's host machine.
640
Tutorials
Creating a User
To be able to connect to the iOrganizer application, you need to create a user account.
Procedure 16.8. Create a user account

1. Go to the following URL: http://<server>:8889/forms/frmservlet?config=iorg
where <server> is the name of the Oracle Forms server's host machine
2. Click on Register.
3. A new page entitled New User Page is displayed. Fill in the following information:
• First Name: Demo
• Last Name: User
• Password: NEOLOAD
• Phone: 0123456789
• Email: demouser@test.com
641
Tutorials
4.
Click Save ( icon ) then on Return to main page ( icon ).
5. In the iOrganizer application's login screen, enter DUSER in the Login field and NEOLOAD in
the Password field.
6. Click Enter. If the connection is successful, the application's main screen should be displayed.
7.
Click on the Exit Calendar button ( icon ).
Configuring NeoLoad
Before you can record the Oracle Forms scenario, NeoLoad needs the file containing the Oracle Forms
applet. See the procedure for configuring NeoLoad.
NeoLoad supports Oracle Forms component naming. Component naming must be configured on the Oracle
Forms server itself.
You can check to see if the server is correctly configured by referring to the procedure for checking the
Oracle Forms server.
If the server is not configured correctly, please follow the procedure for configuring the Oracle Forms
server.
Recording the Scenario
Procedure 16.9. Recording
1. In NeoLoad, click on Record / Start recording.
642
Tutorials
2. Name the virtual user AddressCreator.
3. Check the Delete cookies and Clear cache options.
4. Go to the following URL: http://<server>:8889/forms/frmservlet?config=iorg

where <server> is the name of the Oracle Forms server's host machine. The Oracle Forms Applet
is loading.
5. In the NeoLoad Recording Toolbar, enter AddressCreator_Login.
6. In the iOrganizer application's login screen, enter DUSER in the Login field and NEOLOAD in
the Password field.
7. Click Enter.
8.
In the toolbar,click on Address Book ( icon).
9. In the NeoLoad Recording Toolbar, enter AddressCreator_Create.
10.
Still in the toolbar, click on Create ( icon).
11. Return to the application and fill in the following information:
• First Name: DFirst
• Last Name: DLAST
• Business Phone: 002233445566
12.
Click Save ( icon), then on Return to Main Page ( icon).
13. In the NeoLoad Recording Toolbar, enter AddressCreator_Validate.
14. Return to the application and click on the letter D (at the bottom). The new entry created in the address
book should now be displayed.
643
Tutorials
15. In the NeoLoad Recording Toolbar, enter AddressCreator_Logout.
16.
Click on Return to Main Page ( icon), then click the Exit Calendar button ( icon).
17. Close the browser and go back into NeoLoad
18. Click the Finish button.
Variabilizing the Scenario

1. In NeoLoad, click on Edit / Variables.
2. Click the New variable button.
3. Select List in the list of variable types.
4. Enter Contacts in the Name field.
5. Double-click on the Add a column button.
6. Rename the columns as follows: FirstName, LastName, BusinessPhone
7. Double-click on the Add a value button.
8. Fill in the rows as follows:
• First row: FirstName: John, LastName: DOE, BusinessPhone: 0011221100
• Second row: FirstName: Jack, LastName: SPARROW, BusinessPhone: 6666006666
• Third row: FirstName: Bruce, LastName: SCOTT, BusinessPhone: 1524323256
Note
The input is case-sensitive. Failure to input the correct case may cause the Oracle Forms
application to block the creation of the entry in the database.
9. In the Value change policy section, select For each virtual user.
10. In the Variable scope section, select Local, each virtual user instance
iterates on each value.
644
Tutorials
11. Click OK once, and then again .
12. In the Virtual Users tree, expand the container AddressCreator_Create then the page
named address_book_first_name_0:value=dfirst. Click on the request with the same
name.
13. In the request's XML editor, replace DFirst with ${Contacts.FirstName}. Then click on
Apply.
14. Repeat the operation for the request named address_book_last_name_0:value=dlast,

this time replacing DLAST with ${Contacts.LastName}.
15. Repeat the operation again for the request named

address_book_business_phone_0:value=002233445... replacing
002233445566 with ${Contacts.BusinessPhone}.
Designing the Iterations

Procedure 16.10. Adding iterations for the user AddressCreator
1. In NeoLoad, click on the Virtual Users tab.
2. In the actions (bottom left, expand if necessary), drag and drop the Loop logical action to a position
just before the AddressCreator_Create container.
3. Select the AddressCreator_Create and AddressCreator_Validate containers and

drag them inside the loop (named loop).
645
Tutorials
4. Click on loop. Enter the value 3 in the Execute the loop field.
5. In the actions, drag and drop the Variable Modifier logical action to a position just after the
AddressCreator_Validate container.
6. Click on variable_modifier. Enter Contacts in the Variable name field.
7. The virtual user should look like this:
Configuring the Project

The Oracle Forms applet often issues requests that result in an HTTP 404 error on the server. Therefore,
you will need to tell NeoLoad not to count these as errors by using the following procedure:
Procedure 16.11. Ignore HTTP 404 errors in the recording

1. In NeoLoad, click on Edit / Preferences.
2. Click on the Project settings tab.
3. Select the Runtime parameters category.
4. Check the option Do not mark the specified HTTP error code when the same
error occurs during the record.
5. Click OK to confirm the setting.
646
Tutorials
Validating the Virtual User

1. In NeoLoad, click on Run / Start checking.
2. Click the Advanced button.
3. Check the Play thinktime option.
4. Click OK in the dialog box to confirm the setting.
5. Select the virtual user AddressCreator.
6. Click the Start checking button. The virtual user executes with the same think times as in the
recording.
Once the virtual user has stopped, you may re-connect to the iOrganizer application to check that the
contacts have been created (search the 'D' entries for DOE, and 'S' for SPARROW and SCOTT).
647
Tutorials
To Learn More
Using this scenario, you can add substance to the test by:
• Recording and playing back the creation of different user accounts
• Using several user accounts to run a load test
• Adding clicks on the entries created then configuring a validation on the response. This will make sure
that the entries are always created correctly during the load test.
Analysis
Table of contents
Analyzing Errors in the Errors Panel

Comparing Several Test Results
Analyzing Errors in the Errors Panel

This tutorial describes how to use the panel that displays details of the errors that occurred when executing
the requests in NeoLoad. The Errors panel can be used to correct problems when fine-tuning a virtual user,
or to better understand a server's behavior during a load test.
To gain the most from this tutorial, it is recommended to have read the Chapter 10, Design User Guide
beforehand.

Problems or errors occurring during the execution of a test scenario will bias your results making them
partially or at worst completely unusable. It is therefore important to identify and understand errors
648
Tutorials
occurring during a scenario run. In some situations understanding the source of a problem can be a
relatively complex task. To help you analyze causes of an error, NeoLoad provides extensive information
on the context in which the error occurred. This tutorial details where and how NeoLoad provides this
information.
The two main places NeoLoad indicates that errors have occurred and details them are in the Virtual User
Check dialog and in the Errors tab of the Results mode. The following section presents the Virtual
User Check dialog and goes into the details of understanding the information provided by NeoLoad.
Because the information provided by NeoLoad and the way that information is presented are very similar,
if not identical in both cases, the third section only details the slight differences and the information specific
to the Results mode.
Checking a Virtual User's Validity

A Virtual User simulates a real user accessing a series of web pages. When you have created and defined
a virtual user, an essential step is to check this Virtual User. Making sure the Virtual User is valid before
using it in scenario will guarantee that Virtual Users work at least on a per user basis. This is all the more
true when the pages used by the Virtual User contain dynamic information such as parameters or form
values. The following screen shot depicts a situation where a Virtual User has been defined with three
pages. This has been achieved selecting NeoLoad's Design mode and working in the Virtual Users
tab:
In our example, the virtual user called SimpleUser navigates through three pages that logs the user
on to the application. The first page /loadtest/welcome is the welcome page of the application,
the /loadtest/signOn page is where the user will enter his or her identifier and password, finally
the /loadtest/signedOn page is the page following the sign on and confirming that the user has
successfully signed on. The example is simple and rather unrealistic, a Virtual User would obviously
simulate a more complex behavior, but we'll keep it simple to illustrate error situations.
Checking a Virtual User is achieved by selecting the Check button. NeoLoad displays the Check
Virtual User dialog. Launching the check, in other words executing the Virtual User, is achieved by
selecting the Start checking button.
649
Tutorials
Information provided by the Check Virtual User dialog
1. HTML pages and HTTP requests
NeoLoad plays the pages contained in the Virtual User and displays a sequence of lines, one for each
HTML page and one for each HTTP request defined for that HTML page. For instance the HTML page
/loadtest/signedOn is defined by a unique HTTP request to /loadtest/signon.shtml
using the GET method. The Check Virtual User dialog displays two lines, one for the HTML
page and, immediately after it, another for the request. Had the page contained several requests, the
Check Virtual User dialog box would have displayed a line for each request.
2. Errors, response codes and assertion evaluations
Errors, response codes and assertion evaluations are only meaningful for HTTP requests, this is why
only those lines corresponding to requests display information relative to those elements. When a
request has a response code (see below) associated to an error or has a failed assertion, NeoLoad tags
the associated line with the icon rather than the check mark. If any one request has failed, the
dialog box displays a header with something like following: The Virtual User SimpleUser
contains 2 error(s).
An assertion validates a server response during a test by defining or asserting a condition that must be
met. We will detail a little further in this section how essential assertions can prove to be.
In our example, the HTTP request to /loadtest/error has failed. It has a 500 response code but
no failed assertions. By selecting that line, we can display detailed information on the failed request.
650
Tutorials
3. HTTP request details
When a failed request (or a successful request for that matter) is selected, the dialog box displays the
following elements:
• HTML Page: The HTML page to which the request belongs.
This is a link ; NeoLoad will jump to the specified page in the virtual user
profile if you follow the link.
• HTTP request: The HTTP request that has failed.
Again, this is a link and NeoLoad will jump to the specified request in the virtual user profile if you
follow the link. This feature is particularly useful when you want to check how the request is defined,
especially with regard to dynamic values such as dynamic URLs or dynamic form parameters.
Tip
Navigating back from the virtual user profiles to the request in the Check Virtual
User dialog is easily achieved by right clicking on the request in the Virtual User profiles
and selecting the Select in "Check Virtual User" Dialog item.
This makes it easy to navigate back and forth between the definition of the recorded page
and the error details.
• Response details: Details include the time at which the response was received, the response code,
the response duration and the number of bytes of the response.
The response code is equally a hyper link , NeoLoad will bring up a pop up
displaying the description of that particular response code.
a. HTTP Error Response Codes
HTTP response codes are standard codes, in the range of 400 and 500 they indicate error conditions
and are automatically detected by NeoLoad. HTTP response codes give you a good indication of
the type of error involved.
b. NeoLoad Error Codes
651
Tutorials
NeoLoad status codes are always prefixed by NL and are generated by NeoLoad because
some client mechanism has prevented NeoLoad from actually sending a request. Errors due to
connection failures or networking issues are typical examples of such situations.
• Request, response and assertion contents: the Details group box lets you select which contents
you want the dialog to display.
This feature is often essential when trying to understand the cause of an error. Viewing the request
will, for instance, make it clear what is wrong (a dynamic parameter, an erroneous URL, ...). The
response will contain the detailed reason of the error in the case of a server error, the description
associated to the code in the case of a NeoLoad error.
In our example, the returned response code is 500, an internal server error, the contents of the response
clearly describes the cause of the error. It is due in this case to a compilation error on the requested
JSP page:
Tip
You can easily search for some specific text in the pane containing the error description or
the actual request or response by right clicking in the pane and selecting the Search...
item.
The following screen shot depicts a situation where something in the network layer has gone wrong.
In this case rather than an HTTP response code, a NeoLoad status code is associated to the error and
the HTTP response contains the description of the NeoLoad error:
652
Tutorials
A word on assertions
In our example, when the login process fails, the application returns a page indicating that the operation has
failed. This implies that no error, whether it be a server error or a NeoLoad error, has been detected. And
yet, this situation is surely an error situation. Had our Virtual User contained additional pages depending on
the fact that the login had succeeded, an error would most probably occur later on in one of those pages. It is
therefore essential to use assertions to detect such situations. Assertions will help you identifying an error
situation early in the scenario and avoid analyzing incomprehensible errors due to earlier misbehaviors.
The following screen shot illustrates how an assertion can be used to detect that the login process has
failed. Note that the HTTP response code is 200, thus indicating a perfectly correct HTTP response.
For more details on using assertions, refer to the section called “Validating a Server Response”.
653
Tutorials
Analyzing Errors on a Scenario Run

Running a particular scenario will produce statistical results and provide a comprehensive list of all the
errors (and assertions failures) occurring during the scenario's run. The following screenshot shows the
content of the Errors tab in Results mode after having run a particular scenario. As mentioned earlier,
the information shown in this tab is very similar to that shown in the Check Virtual User dialog box:
Errors are also displayed by NeoLoad in Runtime mode during a scenario run, in the Runtime Errors
tab.
The following points are where the Check Virtual User dialog box and the Errors tab differ:
1. The Errors tab lists lines for HTTP requests only, contrary to the dialog box which presents a line
for the HTML page a request belongs to. This is mainly because the Errors tab displays an error line
for each type and each instance of a virtual user played during the scenario.
2. The Errors tab displays errors for each Virtual User played during the scenario, contrary to the
dialog box which, by definition, concerns a unique user. A scenario defines a number of virtual users
to be played. These users belong to different populations and include different types of users. Hence,
errors can occur for multiple users and multiple types of users.
In our example, the scenario has errors concerning two types of users, SimpleUser and
OccasionnalUser. NeoLoad numbers the users in the order they ran.
3. The Errors tab provides the response and request preceding the request causing the error. In
some situations, an error occurring on a request may be caused by the previous request or response, so
easy access to those elements greatly helps in understanding an error's cause.
The rest of this section details how the new elements provided by the Errors tab can be used.
Filtering and Sorting by Virtual Users
In our example, we want to analyze the 500 error generated on the OccasionnalUser virtual user, we
also want to concentrate on a particular user of this type, the OccasionalUser#5.
• Filtering: To only work with a particular type of user, the easiest way is to filter out the display of errors
by selecting the type of user in the Virtual Users drop down list box.
654
Tutorials
• Sorting: Working with a particular user is easily achieved by sorting errors by Virtual User: clicking
on the Virtual User column header.
The following screen shot depicts the result of having filtered on OccasionnalUser and sorted by
Virtual User:
Using the Previous Request
In our example, the GET request /loadtest/error has returned an HTTP 500 return code. This is
the following error code : Internal Servlet error.
If we take a look at the previous request by selecting the previous request radio button , we understand
that the loadtest/redirect/simple.jsp page has been requested:
We now push our investigation a little further and display the response returned by the previous request
by selecting the previous response radio button:
The response contains a 302 Moved Temporarily code redirecting the client agent to the page called
loadtest/error. Our problem is therefore in the loadtest/redirect/simple.jsp which
redirects to a an error page. This simple example shows you how to meaningfully use the information
NeoLoad provides concerning the context in which an error occurs.
655
Tutorials
Related Links
For more information on using assertions and validating server responses refer to the section called
“Validating a Server Response”.
For more information on HTTP response codes and NeoLoad status codes refer to the appendix.
Comparing Several Test Results

This tutorial describes how to compare two test results in NeoLoad and how to generate a comparison
report.
To gain the most from this tutorial, it is recommended to have read the reference documentation
beforehand.

NeoLoad provides the means of identifying potential performance bottlenecks in your application. This
is mainly achieved by obtaining fine grained statistics on the different pages of the application. Through
comparison you can analyze results from different runs of the same (or different) scenario(s). The steps
typically involved in a testing phase are:
1. Running a particular scenario
2. Analyzing the results and identifying time consuming pages
3. Changing and improving the pages, or the code called by those pages
4. Re-running the scenario
5. Comparing results before and after improvements
Comparing Results in the GUI

NeoLoad provides a compare mode within its graphical interface:
Procedure 16.12. Launching Compare mode

1. Open the Results Manager from the "Edit / Results Manager" menu.
2. In the table, select the two results to compare (click the first row, and 'Ctrl+click' the second row)
3. Click on the "Compare" button.
4. Edit the labels of the two tests and click "OK". The defaults are "A" and "B".
Comparing Results in Reports

NeoLoad can generate comparison reports:
Procedure 16.13. Generating a comparison report

1. Open the Results Manager from the "Edit / Results Manager" menu.
656
Tutorials
2. In the table, select the two results to compare (simple click for the first row, and 'Ctrl+click' for the
second row)
3. Click on the "Generate report" button.
4. Edit the labels of the two tests and click "Next". The default labels are "A" and "B".
5. Configure the format, the report's content and the report file's directory, then click "OK".
Miscellaneous Items
Table of contents
Monitoring an Application Server or Database

Using Additional Load Generators
Scheduling a Test
Monitoring an Application Server or Database

This tutorial describes how to create, configure and use a monitor for monitoring your application or
database server. It sets out the steps involved using an actual example, the Linux monitor.
To gain the most from this tutorial, it is recommended to have read the reference documentation on
"Monitors".

NeoLoad provides numerous statistics on your application, focused mainly on your pages' response
times. It's often useful and instructive to combine and check those figures against statistics coming from
components in your application architecture such as the application server or database server. NeoLoad
provides features that let you monitor these components . This tutorial describes the different types of
monitors provided in NeoLoad and where and how they can be defined, configured and used.
Adding and defining monitors

To start defining monitors, we'll first click on the "Monitors" tab in the "Design" section of NeoLoad.
657
Tutorials
To add a monitor, we first need to specify which machine we want to monitor. To do this, click on the
"New Monitored Machine" button.
NeoLoad displays a dialog box that allows you to define the monitors to be placed on the machine:
The dialog box lists the types of components and/or protocols that NeoLoad is able to monitor. These
monitors are optional modules; if you are interested in a particular monitor type, please contact Neotys
for more information.
Enter the machine's host name or the server's IP address and select the monitors you wish to place on the
machine. For our example, we'll select the Linux monitor.
Configuring the monitor
Click "Next >" to configure the monitors you have selected. The following panel displays the monitor
information.
Click "Next >" once more to enter the monitor's details. For more information on the specific settings
for each monitor, see the Reference Guide.
658
Tutorials
Checking the connection
To make sure the monitor is working properly and that NeoLoad can connect to your server, you may
test the connection by clicking on the "Test" button. If the monitor is working, the message "The
connection settings are correct" is displayed. If not, details of the error are displayed.
Monitor information
Click "Next >" to define the performance counters you wish to put in place on your server. Depending on
the type of monitor selected (in our case, Linux), NeoLoad will automatically define the most appropriate
counters to be monitored and the associated alert thresholds. Check or clear a box to add or remove a
counter from the monitor.
Here, we have added the CPU User, CPU System and CPU Idle counters, among others, to the
Linux SSH monitor.
659
Tutorials
Click on the "Alert thresholds" tab to set the alert thresholds for the desired performance counters.
In this example, two thresholds have been set for the "CPU Idle" counter:
• a warning-level alert will be triggered if the counter's value falls to or below 50 for more than 5 seconds.
• a critical-level alert will be triggered if the counter's value falls to or below 10 for more than 5 seconds.
Then click "Finish" to create the monitored machine, monitor and associated performance counters.
660
Tutorials
Viewing the monitor information during a scenario's run
While the scenario is running, you may select the "Runtime Monitors" tab in the "Runtime" section
and add any monitor information you wish to the display area.
Combining NeoLoad statistics with monitor information
The "Results" section allows you to view the graphs representing the various items monitored during
Runtime. The screenshot below shows a graph obtained by combining user load and the Linux SSH
monitor's CPU Idle counter.
661
Tutorials
In this example, the value of the CPU Idle counter regularly exceeds the alert threshold <= 50% at a
user load greater than 120 simultaneous virtual users.
Using Additional Load Generators

NeoLoad provides two main and distinct applications, the NeoLoad Controller and the Load
Generator. The latter, the Load Generator does the actual job of running a scenario by sending
the requests it defines. The Controller provides NeoLoad's main GUI, letting you design and
launch scenarios and analyze their results. The Controller also manages the Load Generators,
controlling them and delegating the running of the scenario to them. The Controller comes with its
own built-in Load Generator, as shown in the following diagram.
The Load Generator actually comes with an additional executable called the Agent. The Agent is
responsible for launching the Load Generator executable and for informing the Controller that
a Load Generator is present on the machine.
662
Tutorials
Installing a Load Generator

General
The installation process closely resembles that of the Controller, the main difference being that you do
not need to enter a license key. The NeoLoad license key operates on a per-Controller basis. You can
have one Controller and as many Load Generators as you need. Refer to the diagram above for a better
understanding of NeoLoad's deployment and license key requirements.
Also, keep in mind that a Load Generator is never launched manually. As shown above, it is always started
via the agent.
During the Load Generator installation process, the wizard asks you whether the agent should be run as a
service and if it should be run on start up. NeoLoad's default setting is to both install the agent as a service
and run it on start up. This default setting is usually the most appropriate.
If you decide otherwise, you will need to start the agent. Refer to the Reference Guide section on manually
launching the agent.
Firewalls
Since the Controller and Agent communicate with each other, any intervening firewall must be
correctly configured. Three ports need to be opened: one for the Agent (default: 7100), one for theLoad
Generator (default: 7101), and one for the Controller (default: 4569). One UDP port must
be defined for the Agent to allow the Controller to discover the Load Generators on the
network (default: 1369). The above diagram shows the default configuration. You may change all these
663
Tutorials
default settings by editing the Controller or Agent configurations. For more information, see the
documentation on configuring the firewall between the Controller and Load Generator.
Warning
If you're using Windows Firewall with the Agent installed as a service, the firewall will not
prompt you to open the ports used by NeoLoad. In this case, you will need to specifically configure
Windows Firewall to keep these ports open.
Running a Scenario Using Several Load Generators

If you have installed several Load Generators and their associated Agents, you may launch a
scenario using these Load Generators. In the Scenario panel in the Runtime section, click on the
Discover button (two arrows symbol) to display all the Load Generators installed and currently
available. In our example, NeoLoad displays the built-in generator (localhost), an available Load
Generator discovered on a machine whose address is DEXTER, and a generator named loki that was
discovered earlier and which is no longer available.
Advanced Load Generator Configuration
If you select a Load Generator and then click on the button, NeoLoad displays the Advanced Host
Configuration dialog box. In the Network tab you may select the specific network interfaces, (i.e.
the interfaces to the server hosting the application to be tested) the Load Generator should use to replay
a scenario. Likewise, you can specify which IP address the Load Generator should show to the tested
application when sending HTTP requests.
664
Tutorials
The Load Balancing tab lets you define how much load to generate on that particular Load Generator. If
all the Load Generators have a load factor of 1, they will all generate the same load. Conversely, if one
Load Generator has a load factor of 2, while all the others have a load factor of 1, then first Load Generator
will generate twice as heavy a load as the others.
665
Tutorials
Example 16.1. Example of load balancing according to load factor
Given that there are two generators: Generator 1 and Generator 2.
Generator 1 uses a load factor of 1.
Generator 2 uses a load factor of 3.
Consequently, Generator 1 will generate 1/(1+3) = 1/4 = 25% of the load and Generator 2 will generate
3/(1+3) = 3/4 = 75% of the load.
Related Links
For more information on installing Load Generators see the Reference Guide .
Scheduling a Test
This tutorial details the two methods that can be used to schedule the launching of a test at any given time.
Scheduling a Test with NeoLoad

The the "Scenarios" tab in the "Runtime" section, select the scenario to be launched, then click on
the "Advanced..." button. In the "Schedule a test" tab, enable scheduling for the test and enter
the time and date for its launch. You may also specify whether or not the test should be repeated (e.g.
every week).
666
Tutorials
Note
NeoLoad must be running for the test to start at the specified time.
See the section called “Scheduling a test” for more details.
Scheduling a Test with the OS

You may use your operating system's task scheduler to run NeoLoad using a command line (see the section
called “Running the Controller”). Once the test is completed, you may analyze the results using NeoLoad's
graphical user interface. Furthermore, by using the option to generate a report in HTML, PDF or XML
format, the results then can be automatically processed, in particular when the XML format report is used.
667
Part V. Appendix
Table of Contents
A. Regular Expressions .................................................................................................... 672
Overview ............................................................................................................... 672
Introduction .................................................................................................... 672
Using regular expressions ................................................................................. 672
Quick Reference ..................................................................................................... 672
Special character definitions .............................................................................. 672
Character classes ............................................................................................. 673
Pre-defined character classes ............................................................................. 673
Examples ............................................................................................................... 673
Extracting a URL parameter value ..................................................................... 673
Extracting a Form Parameter Value .................................................................... 674
Extracting HTTP headers .................................................................................. 676
Extracting miscellaneous values ......................................................................... 676
Common Errors & Tips ............................................................................................ 676
Use of the question mark '?' .............................................................................. 676
Brackets ........................................................................................................ 677
Spaces ........................................................................................................... 677
Multi-Line ..................................................................................................... 677
Links to Regex Resources ........................................................................................ 677
Links to Regex Testers ............................................................................................ 677
B. Status Code Definitions ................................................................................................ 678
Informational 1xx .................................................................................................... 678
100 Continue .................................................................................................. 678
101 Switching Protocols ................................................................................... 678
Successful 2xx ........................................................................................................ 678
200 OK ......................................................................................................... 678
201 Created .................................................................................................... 679
202 Accepted ................................................................................................. 679
203 Non-Authoritative Information ..................................................................... 679
204 No Content .............................................................................................. 679
205 Reset Content ........................................................................................... 680
206 Partial Content .......................................................................................... 680
Redirection 3xx ...................................................................................................... 680
300 Multiple Choices ....................................................................................... 681
301 Moved Permanently ................................................................................... 681
302 Found ..................................................................................................... 681
303 See Other ................................................................................................ 682
304 Not Modified ........................................................................................... 682
305 Use Proxy ................................................................................................ 682
306 (Unused) .................................................................................................. 683
307 Temporary Redirect ................................................................................... 683
Client Error 4xx ...................................................................................................... 683
400 Bad Request ............................................................................................. 683
401 Unauthorized ............................................................................................ 683
402 Payment Required ..................................................................................... 683
403 Forbidden ................................................................................................ 684
404 Not Found ............................................................................................... 684
405 Method Not Allowed ................................................................................. 684
406 Not Acceptable ......................................................................................... 684
407 Proxy Authentication Required .................................................................... 684
408 Request Timeout ....................................................................................... 684
669
Appendix
409 Conflict ................................................................................................... 685

410 Gone ....................................................................................................... 685
411 Length Required ....................................................................................... 685
412 Precondition Failed .................................................................................... 685
413 Request Entity Too Large ........................................................................... 685
414 Request-URI Too Long .............................................................................. 685
415 Unsupported Media Type ........................................................................... 686
416 Requested Range Not Satisfiable .................................................................. 686
417 Expectation Failed ..................................................................................... 686
Server Error 5xx ..................................................................................................... 686
500 Internal Server Error .................................................................................. 686
501 Not Implemented ...................................................................................... 686
502 Bad Gateway ............................................................................................ 686
503 Service Unavailable ................................................................................... 687
504 Gateway Timeout ...................................................................................... 687
505 HTTP Version Not Supported ..................................................................... 687
C. NeoLoad Status Codes ................................................................................................. 688
D. NeoLoad Javascript API ............................................................................................... 693
Class Logger .......................................................................................................... 693
Synopsis ........................................................................................................ 693
debug(String) .................................................................................................. 694
error(String) ................................................................................................... 694
fatal(String) .................................................................................................... 694
info(String) .................................................................................................... 694
isDebugEnabled() ............................................................................................ 695
isErrorEnabled() .............................................................................................. 695
isFatalEnabled() .............................................................................................. 695
isInfoEnabled() ............................................................................................... 696
isWarnEnabled() ............................................................................................. 696
warn(String) ................................................................................................... 696
Class RendezvousManager ........................................................................................ 696
Synopsis ........................................................................................................ 697
hasRendezvous(String) ..................................................................................... 697
isEnabled(String) ............................................................................................. 698
setEnabled(String, Boolean) .............................................................................. 698
unblock(String) ............................................................................................... 699
unblock(String, int) .......................................................................................... 699
unblockAll() ................................................................................................... 699
Class RuntimeContext .............................................................................................. 699
Synopsis ........................................................................................................ 700
currentVU ...................................................................................................... 700
variableManager .............................................................................................. 700
fail() ............................................................................................................. 700
fail(String) ..................................................................................................... 701
fail(String, String) ........................................................................................... 701
Class VariableManager ............................................................................................. 701
Synopsis ........................................................................................................ 701
changeValue(String) ........................................................................................ 702
getValue(String) .............................................................................................. 702
parseString(String) ........................................................................................... 703
setValue(String, String) .................................................................................... 703
Class VirtualUser .................................................................................................... 703
Synopsis ........................................................................................................ 703
id ................................................................................................................. 704
670
Appendix
name ............................................................................................................. 704

get(Object) ..................................................................................................... 704
put(Object, Object) .......................................................................................... 704
remove(Object) ............................................................................................... 705
setCookieForServer(String, String) ..................................................................... 705
stop() ............................................................................................................ 706
671
Appendix A. Regular Expressions
Overview
Introduction
NeoLoad includes the Apache Jakarta ORO [http://jakarta.apache.org/oro/] regular expressionsoftware for
handling Perl5-compatible regular expressions.
Regexes may be used within NeoLoad to define:
• content assertions: the request is valid if the content matches or contains the regex,
• variable extractors: extracts a value from a request's response and assigns the value to a variable,
This guide is not intended as a comprehensive guide to regular expressions.
The Quick Reference and Examples sections should provide enough information for most cases. Please
see the Links to Regex Resources section for links to fuller documentation and tutorials. You may also
test your regexes with the tools listed in the Links to Regex Testers section.
Using regular expressions

Regular expressions are used to find substrings matching a pattern
Let's consider the following text as an example: The value is: 45675
We can carry out two kinds of operation on the text:
• test whether the text contains "The value is: <a number>" , as when defining a content assertion.
In this case, the regex would be: The value is: \d*
• extract the numerical value from the text, as when defining a variable extractor. In this case, the regex
would be: The value is: (\d*)
The brackets define a group. Here, we refer to this group value using "$1$", as the expression only
contains one bracketed group. When several groups are defined, use "$index$", where index id the
group number in order of appearance from left to right.
Quick Reference
Special character definitions
\ Quotes the next meta character

^ Match the beginning of a line
. Match any character (except newline character)
$ Match the end of a line
| Alternation
() Group
[] Character class
* Match 0 or more times

+ Match 1 or more times
672
Regular Expressions
? Match 0 or 1 times
{n} Match exactly n times
{n,} Match at least n times
{n,m} Match at least n but no more than m times
Character classes
[abc] a, b, or c (simple class)

[^abc] Any character except a, b, or c (negation)
[a-zA-Z] a through z, or A through Z, inclusive (range)
[a-d[m-p]] a through d, or m through p: [a-dm-p] (union)
[a-z&&[def]] d, e, or f (intersection)
[a-z&&[^bc]] a through z, except b and c: [ad-z] (subtraction)
[a-z&&[^m-p]] a through z, but excluding m through p: [a-lq-z] (subtraction)
Pre-defined character classes
. Any character (except newline character)

\d A digit character: [0-9]
\D A non-digit character: [^0-9]
\s A whitespace character: [ \t\n\x0B\f\r]
\S A non-whitespace character: [^\s]
\w A word character: [a-zA-Z_0-9]
\W A non-word character: [^\w]
Examples
Extracting a URL parameter value
Content: <a href="/page.jsp?kind=1&param1=value1&param2=value2">
Regex to extract value1 (only param1 is dynamic):
<a href="/page.jsp\?kind=1&param1=(.*?)&param2=value2">
Regex to extract value1 (all parameters dynamic):
<a href="/page.jsp\?.*?param1=([^&"]*)
Regex to extract value1 (where only the kind=1 links are to be taken into account):
<a href="/page.jsp\?kind=1.*?param1=([^&"]*)
Comments:
• The first "?" is escaped with a backslash as it is a special character.
• The first dynamic part, ".*?" , means "any character followed by 'param1='" in this instance. The
question mark "?" means that the first occurrence matched must be used.
• ([^&"]*) means "any character except '&' and '"', several times". The brackets are required to define
the group. The first group ($1$ in NeoLoad), refers to this matching part.
673
Regular Expressions
Extracting a Form Parameter Value

Content:
<form action="doit.jsp" method="post">

<input type=hidden name=myHiddenField value="hidden information" >
Name: <input name="cn" type="text" value="filled value"><br>
<input name="myRadioField" value="val1" type="radio">Radio Value 1<br>
<input name="myRadioField" value="val2" type="radio" checked="checked" >Radio V
<input type="checkbox" name="myCheckbox" value="checkBoxValue" checked="checked
<select name="dropDownList">
<option value="val1">list choice 1
<option value="val2" selected>list choice 2
</select><br>
<input value="Send" type="submit"><input type="reset">
</form>
The above form looks like this:
Extracting from a text field

Content (value in quotation marks): <input name="cn" type="text" value="filled
value">
Regex: <input name="cn" type="text" value="([^"]*)"
Content (value without quotation marks): <input name="cn" type="text" value=myvalue>
Regex: <input name="cn" type="text" value=([^\s>]*)
Comment: In each case, the brackets define the group whose value may be extracted in NeoLoad using
$1$.
Advanced case: Where the web page contains several forms with text fields of the same name, the regex
must contain the following:
<form action="doit.jsp" method="post">(.|\s)*?<input type=hidden

name=myHiddenField value="([^"]*)"
Comments:
• (.|\s)*? means "any character, including the new line character". "?" means that the first "<input"
must be used.
• ([^"]*) means "any character except the quotation mark character '"' ". The brackets are required to
define a group. The first group ($1$ in NeoLoad), refers to ''(.|\s)*". However, the second group
($2$ in NeoLoad) also needs to be taken into account.
674
Regular Expressions
Extracting from a hidden field

The hidden field is dealt with in a similar way to a normal text field. The input type value "hidden" is
substituted for "text".
Content: <input type=hidden name=myHiddenField value="hidden information"

>
Regex: <input type=hidden name=myHiddenField value="([^"]*)"
Extracting from a radio button

Content: <input name="myRadioField" value="val2" type="radio"
checked="checked" >Radio Value 2
Regex: <input name="myRadioField" value="([^"]*)" type="radio"

checked="checked" >([^<\n]*)
Comments:
• The radio button selected is the one with the checked attribute set to "checked".
• ([^"]*) means "any character except the quotation mark character '"' ".
• ([^<\n]*)means "any character except '<' and the new line character ".
• The brackets are required to define a group. The first group refers to the value and the second refers to
the radio button's label. Therefore, use $1$ in NeoLoad to extract the value and $2$ to extract the label.
Extracting from a checkbox

Content: <input type="checkbox" value="checkBoxValue" name="myCheckbox"
checked="checked">A checkbox
Regex: <input type="checkbox" value="([^"]*)" name="myCheckbox"

checked="checked">([^<\n]*)
Comments:
• The checkbox selected is the one with the checked attribute set to "checked".
• ([^"]*)means "any character except the quotation mark character '"' ".
• The brackets are required to define a group. The first group refers to the value and the second refers to
the checkbox's label. Therefore, use $1$ in NeoLoad to extract the value and $2$ to extract the label.
Extracting from a list

Content:
<select name="dropDownList">
<option value="val2" selected>list choice 2
</select>
675
Regular Expressions
Regex: <select name="dropDownList">(.|\n)*<option value="([^"]*)"

selected>([^<\n]*)
Comments:
• The list item selected is the one with the selected attribute set.
• (.|\n)* means "any character, including the new line character".
• [^"]*) means "any character except the quotation mark character '"' ".
• The brackets are required to define a group. The first group in the regex is redundant; the second refers
to the value and the third to the list item's label. Therefore, use $2$ in NeoLoad to extract the value
and $3$ to extract the label.
Extracting HTTP headers

Content:
Content-Type: text/html
Content-Length: 163
myHeader: myValue
Date: Thu, 03 Feb 2005 16:44:33 GMT
Server: Apache-Coyote/1.1
Regex: myHeader: (.*)
Comment: (.*) means "any character, except the newline character". The brackets are required to define
a group. Extract the header value in NeoLoad using $1$.
Extracting miscellaneous values

Content: <div class ="welcomebar"> Welcome: John Doe </div>
Regex: <div class ="welcomebar"> Welcome: (\w* \w*) </div>
Comments:
• (\w* \w*) means "two words separated by a space". The brackets are required to define a group.
The first and unique group refers to ''(\w* \w*)". Therefore, use $1$ in NeoLoad to extract both
first and last names.
• Using "(\w*) (\w*)" instead of "(\w* \w*)" may be used to extract the first and last name
separately. In this case, use $1$ to extract the first name and $2$ the last name.
Common Errors & Tips

Use of the question mark '?'
When working with URLs, pay particular attention to the use of the question mark (?), which
is a special character that requires escaping with the backslash, for example: "/page\.html\?
param1=value1" (the dot "." is also a special character).
676
Regular Expressions
Brackets
When using regexes in Variable Extractors, do not forget to use brackets to define the various groups. The
" .*" and "(.*)" patterns may both match an expression, but only the pattern enclosed in brackets will
extract the value by referring to the group using $groupNumber$. In certain cases, brackets need to be
used to isolate part of a regex pattern, regardless of any group definition requirements. This must be taken
into account when defining the groups whose values are to be extracted.
Spaces
A space is a normal character that must be taken into account in regexes. Check to make sure there are no
extra spaces at the start or end of the regex, especially after cutting and pasting.
Multi-Line
The characters ".*" mean "matching any string of characters except line breaks". If the expression is tested
over several lines, use "([^^]*?)", which includes line breaks.
Links to Regex Resources

Useful links:
• http://java.sun.com/docs/books/tutorial/extra/regex/index.html - Tutorial on the java.util.regex package.
• http://www.zvon.org/other/PerlTutorial/Output/regexps.html - Examples.
• http://www.regular-expressions.info/ - Tutorial, examples.
Links to Regex Testers

NeoLoad can test the regexes to be used.
Regexes may also be tested with other tools:
• online applet: http://jakarta.apache.org/oro/demo.html
• Regex Coach (http://www.weitz.de/regex-coach/), a comprehensive freeware tool.
677
Appendix B. Status Code Definitions
Each Status-Code is described below, including a description of which method(s) it can follow and any
metainformation required in the response.
Informational 1xx
This class of status code indicates a provisional response, consisting only in the Status-Line and optional
headers and terminated by an empty line. There are no required headers for this class of status code. Since
HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
client except under experimental conditions.
A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even
if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be
ignored by a user agent.
Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been
closed, or unless the proxy itself has requested the generation of the 1xx response. (For example, if a
proxy adds a "Expect: 100-continue" field when it forwards a request, then it does not need to forward the
corresponding 100 (Continue) response(s).)
100 Continue
The client SHOULD continue with its request. This interim response is used to inform the client that the
initial part of the request has been received and that it has not been rejected by the server yet. The client
SHOULD continue by sending the remainder of the request or, if the request has already been completed,
ignore this response. The server MUST send a final response after the request has been completed. See
[RFC 2068], section 8.2.3 for detailed discussion of the use and handling of this status code.
101 Switching Protocols

he server understands and is willing to comply with the client's request, via the Upgrade message header
field ([RFC 2068], section 14.42), for a change in the application protocol being used on this connection.
The server will switch protocols to those defined by the response of the Upgrade header field immediately
after the empty line which terminates the 101 response.
The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a
newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous
protocol might be advantageous when delivering resources that use such features.
Successful 2xx
This class of status code indicates that the client's request was successfully received, understood, and
accepted.
200 OK
The request has succeeded. The information returned with the response depends on the method used in
the request, for example:
GET an entity corresponding to the requested resource is sent in the response;
678
Status Code Definitions
HEAD the entity-header fields corresponding to the requested resource are sent in the response without
any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the end server.
201 Created
The request has been fulfilled and recorded in a new resource. The created resource can be referenced by
the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a
Location header field. The response SHOULD include an entity containing a list of resource characteristics
and location(s) from which the user or user agent can choose the most appropriate. The entity format is
specified by the type of the media given in the Content-Type header field. The original server MUST
create the resource before returning the 201 status code. If the action cannot be carried out immediately,
the server SHOULD respond with 202 (Accepted) response instead.
A 201 response MAY contain an ETag response header field indicating the current value of the entity tag
for the requested variant just created, see [RFC 2068], section 14.19.
202 Accepted
The request has been accepted for processing, but the processing has not been completed. The request
might or might not be eventually acted upon, as it might be disallowed when processing actually takes
place. There is no facility for re-sending a status code from an asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for
some other process (perhaps a batch-oriented process that is only run once per day).The user agent does
not have to be connected to the server till the end of the process. The entity returned with this response
SHOULD include an indication of the current status of the request and whether a pointer to a status monitor
or an estimation of when the user can expect the implementing of the request to be over.
203 Non-Authoritative Information

The returned metainformation in the entity-header is not the definitive set as available in the original server.
It comes from a local or a third-party copy. The set presented MAY be a subset or superset of the original
version. For example, including local annotation information about the resource might result in a superset
of the metainformation known by the origin server. The use of this response code is not required. It is only
appropriate for a response of 200 (OK).
204 No Content
The server has fulfilled the request but does not need to return an entity-body and might want to return
updated metainformation. The response MAY include new or updated metainformation in the form of
entity-headers, which if found SHOULD be associated with the requested variant.
If the client is a user agent, it SHOULD NOT change its document view into the one that caused the
sending of the request. This response is primarily intended to allow input for actions to take place without
causing a change of the user agent's active document view, although any new or updated metainformation
SHOULD be applied to the document currently in the user agent's active view.
The 204 response MUST NOT include a message-body,and is thus always terminated by the first empty
line after the header fields.
679
205 Reset Content

The server has fulfilled the request and the user agent SHOULD reset the document view which caused
the request to be sent. This response is primarily intended to allow input for actions to take place via user
input, followed by a clearing of the form in which the input is given so that the user can easily initiate
another input action. The response MUST NOT include an entity.
206 Partial Content

The server has fulfilled the partial GET request for the resource. The request MUST have included a Range
header field ([RFC 2068], section 14.35) indicating the desired range, and MAY have included an If-Range
header field ([RFC 2068], section 14.27) to make the request conditional.
The response MUST include the following header fields:
- whether a Content-Range header field ([RFC 2068], section 14.16) indicating

the range included with this response, or a multipart/byteranges
Content-Type including Content-Range fields for each part. If a
Content-Length header field is present in the response, its
value MUST match the actual number of OCTETs transmitted in the
message-body.
- Date
- ETag and/or Content-Location, if the header would have been sent

in a 200 response to the same request
- Expires, Cache-Control, and/or Vary, if the field-value

differs from the one sent in any previous response for the same
variant
If the 206 response is the result of an If-Range request that used a strong cache validator (see [RFC 2068],
section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of
an If-Range request that used a weak validator, the response MUST NOT include other entity-headers;
this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response
MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the
same request.
A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-
Modified headers do not match exactly, see 13.5.4.
A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial)
responses.
Redirection 3xx
This class of status code indicates that further actions need to be taken by the user agent in order to fulfill
the request. The action required MAY be carried out by the user agent without interaction with the user
if, and only if, the method used in the second request is GET or HEAD. A client SHOULD detect infinite
redirection loops, since such loops generate network traffic for each redirection.
Note: previous versions of this specification recommended a maximum of five redirections. Content
developers should be aware that there might be clients that implement such a fixed limitation.
680
300 Multiple Choices

The requested resource corresponds to any set of representations, each one with its own specific location.
The agent- driven negotiation information ([RFC 2068], section 12) is being provided so that the user (or
user agent) can select a preferred representation and redirect its request to that location.
Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource
characteristics and location(s) from which the user or user agent can choose the most appropriate. The
entity format is specified by the media type given in the Content- Type header field. Depending upon the
format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed
automatically. However, this specification does not define any standard for such automatic selection.
If the server has a preferred choice of representation, it SHOULD include the specific URI for that
representation in the Location field; user agents MAY use the Location field value for automatic
redirection. This response is cacheable unless indicated otherwise.
301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource
SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-
link references to the Request-URI to one or more of the new references returned by the server and where
it is possible. This response is cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the response. Unless the request
method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink
to the new URI(s).
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST
NOT automatically redirect the request unless it can be confirmed by the user, since this might change the
conditions under which the request was issued.
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing
HTTP/1.0 user agents will erroneously change it into a GET request.
302 Found
The server has performed a sendRedirect. A browser should automatically request the URL indicated by
the Location header.
The requested resource resides temporarily under a different URI. Since the redirection might be
occasionally altered, the client SHOULD continue to use the Request-URI for future requests. This
response is only cacheable if indicated by a Cache-Control or Expires header field.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method
was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the
new URI(s).
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the
redirected request. However, most existing user agent implementations treat 302 as if it was a 303 response,
performing a GET on the Location field-value regardless of the original request method. The status codes
681
303 and 307 have been added for servers that wish to make unambiguously clear the expercted reaction
of the client.
303 See Other

The response to the request can be found under a different URI and SHOULD be retrieved using a GET
method on that resource. This method exists primarily to allow the output of a POST-activated script to
redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally
requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected)
request might be cacheable.
The different URI SHOULD be given by the Location field in the response. Unless the request method
new URI(s).
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such
clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response
as described here for 303.
304 Not Modified

If the client has performed a conditional GET request and access is allowed without the document being
modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a
message-body, and is thus always terminated by the first empty line after the header fields.
The response MUST include the following header fields:
- Date, unless its omission is required by [RFC 2068], section 14.18.1 If a clockless origin server obeys
these rules and proxies and if clients add their own Date to any response received without one (as already
specified by [RFC 2068], section 14.19), caches will operate correctly.
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
- Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous
response for the same variant
If the conditional GET used a strong cache validator (see [RFC 2068], section 13.3.3), the response
SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator),
the response MUST NOT include other entity-headers; this prevents inconsistencies between cached
entity-bodies and updated headers.
If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response
and repeat the request without the conditional.
If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect
any new field values given in the response.
305 Use Proxy

The requested resource MUST be accessed through the proxy given by the Location field. The Location
field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305
responses MUST only be generated by origin servers.
Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by
origin servers only. Not observing these limitations has significant security consequences.
682
306 (Unused)
The 306 status code, which was used in a previous version of the specification , is no longer used and
the code is reserved.
307 Temporary Redirect

The requested resource resides temporarily under a different URI. Since the redirection MAY be altered
on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is
only cacheable if indicated by a Cache-Control or Expires header field.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method
new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note
SHOULD contain the information necessary for a user to repeat the original request on the new URI.
Client Error 4xx

The 4xx class of status code appears when a client made a mistake. Except when responding to a HEAD
request, the server SHOULD include an entity containing an explanation of the error situation. It is whether
a temporary condition, whether a permanent condition. These status codes are applicable to any request
method. User agents SHOULD display any included entity to the user.
If the client is sending data, a server implementation using TCP SHOULD be careful to ensure that the
client acknowledges the receipt of the packet(s) containing the response, before the server closes the input
connection. If the client continues sending data to the server after the close, the server's TCP stack will
send a reset packet to the client, which may erase the client's unacknowledged input buffers before they
can be read and interpreted by the HTTP application.
400 Bad Request

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT
repeat the request without modifications.
401 Unauthorized
The request requires user authentication. The response MUST include a WWW-Authenticate header
field ([RFC 2068], section 14.47) containing a challenge applicable to the requested resource. The client
MAY repeat the request with a suitable Authorization header field ([RFC 2068], section 14.8). If the
request already included Authorization credentials, then the 401 response indicates that authorization
has been refused for those credentials. If the 401 response contains the same challenge as the prior
response, and the user agent has already, at least once, attempted authentication, then the user SHOULD
be presented the entity that was given in the response, since that entity might include relevant diagnostic
information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access
Authentication" [43].
402 Payment Required

This code is reserved for future use.
683
403 Forbidden
The server understood the request but is refusing to fulfill it. Authorization will not help and the request
SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public
the reason why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the
entity. If the server does not wish to make this information available to the client, the status code 404 (Not
Found) can be used instead.
404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the
condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows,
through some internally configurable mechanism, that an old resource is permanently unavailable and has
no forwarding address. This status code is commonly used when the server does not wish to reveal exactly
why the request has been refused, or when no other response is applicable.
405 Method Not Allowed

The method specified in the Request-Line is not allowed for the resource identified by the Request-URI.
The response MUST include an Allow header containing a list of valid methods for the requested resource.
406 Not Acceptable

The resource identified by the request is only capable of generating response entities which have content
characteristics not acceptable according to the accept headers sent in the request.
Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity
characteristics and location(s) from which the user or user agent can choose the one most appropriate. The
entity format is specified by the media type given in the Content-Type header field. Depending upon the
format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed
automatically. However, this specification does not define any standard for such automatic selection.
Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept
headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User
agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable. If
the response is unacceptable, a user agent SHOULD temporarily stop the receipt of more data and query
the user for a decision on further actions.
407 Proxy Authentication Required

This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the
proxy. The proxy MUST return a Proxy-Authenticate header field ([RFC 2068], section 14.33) containing
a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with
a suitable Proxy-Authorization header field ([RFC 2068], section 14.34). HTTP access authentication is
explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].
408 Request Timeout

The client did not produce a request within the time that the server was prepared to wait. The client MAY
repeat the request without modifications at any later time.
684
409 Conflict
The request could not be completed due to a conflict with the current state of the resource. This code is only
allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit
the request. The response body SHOULD include enough information for the user to recognize the source
of the conflict. Ideally, the response entity would include enough information for the user or user agent to
fix the problem; however, that might not be possible and is not required.
Conflicts are most likely to occur in response to a PUT request. For example, if versioning was being used
and the entity being PUT included changes to a resource which conflicts with those made by an earlier
(third-party) request, the server might use the 409 response to indicate that it can't complete the request.
In this case, the response entity would likely contain a list of the differences between the two versions in
a format defined by the response Content-Type.
410 Gone
The requested resource is no longer available at the server and no forwarding address is known. This
condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete
references to the Request-URI after user approval. If the server does not know, or has no facility to
determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used
instead. This response is cacheable unless indicated otherwise.
The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that
the resource is intentionally unavailable and that the server owners desire the removal of the remote links to
that resource. Such an event is common for limited-time, promotional services and for resources belonging
to individuals no longer working at the site of the server. It is not necessary to mark all permanently
unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion
of the server owner.
411 Length Required

The server refuses to accept the request without a defined Content- Length. The client MAY repeat the
request if it adds a valid Content-Length header field containing the length of the message-body in the
request message.
412 Precondition Failed

The precondition given in one or more of the request-header fields evaluated to false when it was
tested on the server. This response code allows the client to place preconditions on the current resource
metainformation (header field data) and thus prevents the requested method from being applied to a
resource different than the one intended.
413 Request Entity Too Large

The server is refusing to process a request because the request entity is larger than the server is willing or
able to process. The server MAY close the connection to prevent the client from continuing the request.
If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is
temporary and to define the moment when the client MAY try again.
414 Request-URI Too Long

The server is refusing to service the request because the Request-URI is longer than the server is willing
to interpret. This rare condition is only likely to occur when a client has improperly converted a POST
685
request to a GET request with long queried information, when the client has descended into a URI "black
hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is
under attack by a client attempting to exploit security holes present in some servers using fixed-length
buffers for reading or manipulating the Request-URI.
415 Unsupported Media Type

The server is refusing to service the request because the entity of the request is in a format that can't be
supported by the requested resource for the requested method.
416 Requested Range Not Satisfiable

A server SHOULD return a response with this status code if a request included a Range request-header
field ([RFC 2068], section 14.35), and none of the range-specifier values in this field overlap the current
extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-
ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current
length of the selected resource.)
When this status code is returned for a byte-range request, the response SHOULD include a Content-Range
entity-header field specifying the current length of the selected resource (see [RFC 2068], section 14.16).
This response MUST NOT use the multipart/byteranges contenttype.
417 Expectation Failed

The expectation given in an Expect request-header field (see [RFC 2068], section 14.20) could not be met
by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not
be met by the next-hop server.
Server Error 5xx

Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has
erred or is incapable of performing the request. Except when responding to a HEAD request, the server
SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary
or permanent condition. User agents SHOULD display any included entity to the user. These response
codes are applicable to any request method.
500 Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request.
501 Not Implemented

The server does not support the functionality required to fulfill the request. This is the appropriate response
when the server does not recognize the request method and is not capable of supporting it for any resource.
502 Bad Gateway

The server, while acting as a gateway or proxy, received an invalid response from the upstream server it
accessed in attempting to fulfill the request.
686
503 Service Unavailable

The server is currently unable to handle the request due to a temporary overloading or maintenance of the
server. This implies that it is a temporary condition which will be alleviated after some delay. If known,
the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client
SHOULD handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a server must use it when becoming
overloaded. Some servers may wish to simply refuse the connection.
504 Gateway Timeout

The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server
specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to
access in attempting to complete the request.
Note: Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups
time out.
505 HTTP Version Not Supported

The server does not support, or refuses to support, the HTTP protocol version that was used in the request
message. The server is indicating that it is unable or unwilling to complete the request using the same
major version as the client, as described in [RFC 2068] section 3.1, other than with this error message.
The response SHOULD contain an entity describing why that version is not supported and what other
protocols are supported by that server.
687
Appendix C. NeoLoad Status Codes
• NL-REDIRECT-01. NeoLoad could not follow the sendRedirect directive for the previous request
(302 Moved Temporarily)
Cause: Previous request not found.
Explanation:
The request that failed has the "HTTP redirect" type in NeoLoad. This means that the request must
follow the redirection directive of the previous request. The redirection is valid when the previous
requests returns the HTTP status code 301, 302, 303 or 307, and headers containing the header named
"Location".
NL-REDIRECT-01 means that the previous request (designated by the 'referrer') has not been played.
Please check the referrer of the request that failed (click the "Advanced..." button and select the
"Advanced settings" tab) and check in your virtual user that the 'referrer' request is being played before
the request that fails.
Cause: Location header missing in previous request.
Explanation:
"Location".
NL-REDIRECT-02 means that the previous request (designated by the 'referrer') had an HTTP status
code of 301, 302, 303 or 307 but no header named "Location" when played back. The web application
should be fixed.
Cause: The previous request did not issue a redirection (no 302 status)
Explanation:
"Location".
NL-REDIRECT-03 means that the previous request (designated by the 'referrer') did not have an HTTP
status code of 301, 302, 303 or 307 when played back. First, please verify that the referrer of the
request that failed is in fact the appropriate request (click "Advanced..." button and select the "Advanced
settings" tab). Next, investigate why the previous request did not return the expected status code.
Typically, an invalid parameter has been sent and the previous request has failed with '200' as the HTTP
status code.
688
NeoLoad Status Codes
Cause: The previous request contains an error.
Explanation:
The request that failed has the "HTTP redirect" type in NeoLoad. This means that the request must follow
the redirection directive of the previous request. The redirection is valid when the previous requests
returns the HTTP status code 301, 302, 303 or 307, and headers containing the header named "Location".
NL-REDIRECT-04 means that the previous request (designated by the 'referrer') failed.
• NL-LINKEXTRACTOR-01. The link or form could not be extracted from the previous request.
Cause: The previous request contains an error.
Explanation:
The request that failed has the "Link/Form extractor" type in NeoLoad. This means that the request must
extract its dynamic information from the previous page (designated by the 'referrer').
NL-LINKEXTRACTOR-01 means that the previous request failed.
Cause: The definition does not match any link or form in the previous request.
Explanation:
The request that failed has the "Link/Form extractor" type in NeoLoad. This means that the request must
NL-LINKEXTRACTOR-02 means that the NeoLoad definition of the request is not properly designed
to extract its dynamic information from the previous page. Please check the request definition and
validate the regular expressions that may have been used.
Cause: The previous request was not played.
Explanation:
The request that failed has the "Link/Form extractor" type in NeoLoad. It means that the request must
The NL-LINKEXTRACTOR-03 error means that the preceding request (designated by the "referrer")
was not played. This usually indicates a problem with the virtual user's configuration or that a previous
error prevented the referrer being played.
• NL-HTTPERROR-01. HTTP connection problem.
• NL-NETWORK-01. Miscellaneous I/O error when connecting to the server.
The "java.net.NoRouteToHostException: No route to host: connect" error

probably indicates that an incorrect network interface has been used. Check the load generator's
advanced network settings.
689
The "java.net.SocketException: Connection reset" error may occur when the server
is overloaded.
• NL-NETWORK-02. Error when connecting to server (bind error).
Indicates an error occurring locally when attempting to bind a socket. This is usually due to the
load generator not being able to open any more sockets on the local system. Please refer to the
Troubleshooting Guide for details on which system settings to check.
• NL-NETWORK-03. Error when connecting to the server. Indicates a server-side error occurring
when attempting to bind a socket. This is usually due to the server being shut down or not being able
to open any more sockets.
If the error details are "java.net.ConnectException: Connection timed out:

connect" for all the requests, it would suggest that the load generator cannot access the application.
You can verify this behavior by trying to access the application on the load generator machine.
• NL-INVALID-CONFIGURATION. Invalid configuration for request.
• NL-RUNTIME-01. Unexpected load generator error when connecting to the server. This is a
NeoLoad bug, please contact support.
• NL-RUNTIME-02. Unexpected load generator error when playing the request. This is a NeoLoad
bug, please contact support.
• NL-RUNTIME-03. Unexpected load generator error when playing the request. This error can
occur when the client request body and/or the server response body does not contain any data. Some
applications may not strictly respect the HTTP protocol, so it's not necessarily an error.
• JS-OK. JavaScript execution succeeded.
• JS-FAIL. The script flagged the JavaScript Action as having failed (Call to
context.fail()method)
• JS-ERROR-COMP. JavaScript compilation failed: invalid syntax.
• JS-ERROR-EVAL. JavaScript execution failed. Typically, the script used a variable or a function
that does not exist.
• NL-PLUGIN-ENGINE-01. Generator internal error while processing the XML request. This error
relates to problems that may arise in the generator while preparing the XML request prior to sending.
The error details will pinpoint whether the problem is due to the replacement of variables or to the
conversion from XML to binary format.
• NL-PLUGIN-ENGINE-02. Generator internal error while processing the XML request. This error
relates to problems that may arise in the generator while preparing the binary response after its reception.
The error details will pinpoint whether the problem is due to the conversion from binary format to XML.
• NL-PLUGIN-ENGINE-03. XML HTTP requests whose conversion to XML has failed cannot be
played back. During recording, certain XML requests may not have been converted to the XML format
correctly. These requests are notified visually in the virtual user profiles. This kind of request sometimes
can be produced by the Adobe Flex/AMF module. The requests flagged as containing an error must be
repaired according to the instructions in the documentation supplied with the XML module generating
the request.
• NL-AMF-PLUGIN-ENGINE-01. Generator internal error while processing the Adobe Flex / AMF
request. This error code covers all the errors that may occur while preparing an Adobe Flex / AMF
690
request prior to it being sent to the server. The most common error is caused when NeoLoad attempts to
play back an Adobe Flex / AMF request that was incorrectly converted to XML format during recording,
and has not been repaired. To fix the problem, see the tutorial entitled XML Adobe Flex/AMF Module:
Advanced Use.
• NL-AMF-PLUGIN-ENGINE-02. Generator internal error while processing the AMF response. This
error code covers all the errors that may occur while decoding an Adobe Flex / AMF response after
reception. The most common error is caused by a response containing Adobe Flex/AMF externalizable
objects (see the AMF Post-recording Wizard for more details on these objects) that could not be decoded.
• NL-AMF-PLUGIN-ENGINE-03. An AMF error message was returned by the server and the error
code contained in the message does not appear in the AMF error message exclusion list. See the AMF
General Preferences for more information on Adobe Flex/AMF error codes and their handling.
• NL-AMF-STREAMING-PLUGIN-ENGINE-01. The server shut down the streaming channel

prematurely.
• NL-RTMP-PLUGIN-ENGINE-01. Internal generator error during processing of the Adobe RTMP

request. This error code covers all errors that may occur while preparing an Adobe RTMP request before
it being sent to the server. The most common error is caused when NeoLoad attempts to play back an
Adobe RTMP request that was incorrectly converted to XML format during recording and has not been
repaired. To fix the problem, see the tutorial entitled Adobe RTMP XML Module: Advanced Use .
• NL-RTMP-PLUGIN-ENGINE-02. Internal generator error during processing of the RTMP

response. This error code covers all errors that may occur while decrypting an Adobe RTMP response
after reception. The most common error is when the response contains externalizable Adobe RTMP
objects (see the RTMP Post-Recording Wizard for more details on these objects) that could not be
decrypted.
• NL-RTMP-PLUGIN-ENGINE-03. A RTMP error message was returned by the server.
• NL-RTMP-PLUGIN-TIMEOUT-01. The server took too long to respond to the client connection
or RTMP request. The default maximum connection and response times are 60 seconds. These
settings may be changed in the "<NeoLoad>\conf\controller.properties" file. Locate the
"[RTMP]" category (create it if it does not already exist) and the "socket.read.timeout" and
"socket.connection.timeout" parameters (the values are in milliseconds: 60000 equals 60
seconds).
• NL-OF-PLUGIN-ENGINE-01. An error occurred while encrypting the Oracle Forms request. This
error may have a number of causes: the error details will give more indications as to the error's probable
source. Generally, the error arises when the virtual user tries to encrypt an Oracle Forms request where
the dynamic encryption key negotiation with the server has previously failed.
• NL-OF-PLUGIN-ENGINE-02. An error has occurred while decrypting the Oracle Forms response.
The Oracle Forms server returned an error indicating that it did not understand the request, or that the
response sent back by the server could not be decrypted correctly.
• NL-OF-PLUGIN-ENGINE-03. An unknown handlerId has been found while creating the

Oracle Forms request. During runtime, a list of all existing handlerIds is maintained. Each time a
CREATE or a DESTROY DataMessage is received, the handlerId is added or removed from this
list. A handlerId is declared as unknown if it's not within the list of all existing handlerIds. For
more information, please see the documentation on Oracle Forms message sample.
• NL-GWT-PLUGIN-ENGINE-01. Generator internal error while processing the GWT request. This
error code covers all the errors that may occur while preparing a GWT request prior to it being sent to
the server. The most common error is caused when NeoLoad attempts to play back a GWT request that
691
has been incorrectly converted to XML format during recording and has not been repaired. To fix the
problem, see the tutorial entitled XML Google Web Toolkit Module: Advanced Use.
• NL-GWT-PLUGIN-ENGINE-02. Generator internal error while processing the GWT response.

This error code covers all the errors that may occur while decoding a GWT response after reception.
The most common error is caused by a response containing GWT objects (see the GWT Post-recording
Wizard for more details on these objects) that could not be decrypted.
• NL-GWT-PLUGIN-ENGINE-03. A GWT error message was returned by the server.
• NL-JAVA-PLUGIN-ENGINE-01. Generator internal error while processing the Java Serialization

request. This error code covers all the errors that may occur while preparing a Java Serialization request
prior to it being sent to the server. The most common error is caused when NeoLoad attempts to play
back a Java Serialization request that has been incorrectly converted to XML format during recording
and has not been repaired. To fix the problem, see the tutorial entitled XML Java Serialization Module:
Advanced Use.
• NL-JAVA-PLUGIN-ENGINE-02. Generator internal error while processing the Java Serialization

response. This error code covers all the errors that may occur while decoding a Java Serialization
response after reception. The most common error is caused by a response containing Java objects (see the
Java Serialization Post-recording Wizard for more details on these objects) that could not be decrypted.
• NL-JAVA-PLUGIN-ENGINE-03. A Java Serialization error message was returned by the server.
• NL-ASSERTION-FAILED. At least one assertion failed on the server response of the request.
692
Appendix D. NeoLoad Javascript API
Class Logger
The Logger object is used to log messages.
The message will be displayed:
When running a test:
• in NeoLoad GUI when the Javascript failed for any reason,
• in the Load Generator log file in any case ("loadGenerator.log.00x" of the logs folder. Open the logs
folder with the menu "Help / open logs folder").
When checking a Virtual User: in NeoLoad GUI only.
The different methods of this class log the message with different log levels: FATAL, ERROR, WARN,
INFO, DEBUG. If the level used to log the message is lower than the log level defined in the runtime
policy, then the message will be ignored.
The runtime log level can be set in NeoLoad GUI, in the project's preferences: menu "Edit / Preferences".
The default is ERROR, it will ignore any message at WARN, INFO and DEBUG level. Warning, as it can
be very verbose, the runtime log level should be decreased to debug small tests only (few users for a few
time). Don't forget to switch back to ERROR level for normal tests.
Note that the log level is forced to DEBUG when validating your Virtual Users using the Check dialog.
Warning, logging at ERROR level will not flag the JSAction as failed. If you want to flag the JSAction
as failed, use fail(java.lang.String) method.
NeoLoad provides a predefined Logger named logger
Example
logger.error("Unexpected value:"+var1);
Synopsis
public class Logger {
// Public Methods
public void debug(String message);
public void error(String message);
public void fatal(String message);
public void info(String message);
693
NeoLoad Javascript API
public boolean isDebugEnabled();
public boolean isErrorEnabled();
public boolean isFatalEnabled();
public boolean isInfoEnabled();
public boolean isWarnEnabled();
public void warn(String message);
debug(String)
public void debug(String message);
Parameters
message the message.
Log a message at DEBUG level, will be logged if runtime level is DEBUG.
error(String)
public void error(String message);
Parameters
Log a message at ERROR level, will be logged if runtime level is lower or equal to ERROR.
Warning, logging at ERROR level will not flag the JSAction as failed. If you want to flag the JSAction
as failed, use fail(java.lang.String) method.
fatal(String)
public void fatal(String message);
Parameters
Log a message at FATAL level, will always be logged.
info(String)
public void info(String message);
694
Parameters
Log a message at INFO level, will be logged if runtime level is lower or equal to INFO.
isDebugEnabled()
public boolean isDebugEnabled();
Parameters
return true if this logger is debug enabled, false otherwise.
Check whether this logger is enabled for the DEBUG Level.
This function is intended to lessen the computational cost of disabled log debug statements.
For some javascript action, when you write,
logger.debug("This is entry number: " + i );
You incur the cost constructing the message, concatenation in this case, regardless of whether the message
is logged or not. You should write
if(logger.isDebugEnabled()) {
logger.debug("This is entry number: " + i );
}
This way you will not incur the cost of parameter construction if debugging is disabled for the session.
isErrorEnabled()
public boolean isErrorEnabled();
Parameters
return true if this logger is error enabled, false otherwise.
Check whether this logger is enabled for the ERROR Level.
See isDebugEnabled() for more information.
isFatalEnabled()
public boolean isFatalEnabled();
Parameters
return true if this logger is fatal enabled, false otherwise.
695
Check whether this logger is enabled for the FATAL Level.
isInfoEnabled()
public boolean isInfoEnabled();
Parameters
return true if this logger is info enabled, false otherwise.
Check whether this logger is enabled for the INFO Level.
isWarnEnabled()
public boolean isWarnEnabled();
Parameters
return true if this logger is warn enabled, false otherwise.
Check whether this logger is enabled for the WARN Level.
warn(String)
public void warn(String message);
Parameters
Log a message at WARN level, will be logged if runtime level is lower or equal to WARN.
Class RendezvousManager
Rendezvous Management
The rendezvous Manager allows you to:
• Release a set number of virtual users detained at a specific rendezvous point.
• Release all virtual users detained at a specific rendezvous .
• Release all virtual users detained at all rendezvous .
• Enable or disable a rendezvous .
• Find out if a rendezvous is enabled or disabled.
696
• Find out if a specific rendezvous point exists in one of the virtual users played.
The rendezvous Manager acts on the test runtime globally, however many Load Generators are in use.
Please note the following points on the way rendezvous function:
• An order issued by the rendezvous Manager is disseminated to all the Load Generators involved in
running the scenario.
• When concurrent orders are issued, the last order issued takes precedence over the others.
Example: Given that there are 3 Load Generators, (G1, G2 and G3). On G1, a virtual user's JavaScript
action calls the following code:
context.RendezvousManager.setEnabled("rendezvous",false);
G1, G2 and G3 will then disable the rendezvous named "rendezvous": all the generators obey the order
issued by G1.
Synopsis
public class RendezvousManager {
// Public Constructors
public RendezvousManager();
// Public Methods
public Boolean hasRendezvous(String RDVName);
public Boolean isEnabled(String RDVName);
public void setEnabled(String RDVName,

Boolean isEnabled);
public void unblock(String RDVName);
public void unblock(String RDVName,

int virtualUserCount);
public void unblockAll();
hasRendezvous(String)
public Boolean hasRendezvous(String RDVName);
Parameters
RDVName rendezvous name
697
return Boolean value corresponding to the rendezvous ' existence
Indicates the existence of a rendezvous by returning a Boolean value.
This method returns:
• TRUE if the scenario contains the specified rendezvous (enabled or not).
• FALSE if the scenario does not contain the specified rendezvous .
• FALSE if the rendezvous does not exist.
isEnabled(String)
public Boolean isEnabled(String RDVName);
Parameters
RDVName
return Boolean value corresponding to the rendezvous state
Indicates the state of a rendezvous by returning a Boolean value.
This method returns:
• TRUE if the rendezvous exists and is enabled.
• FALSE if the rendezvous exists and is disabled.
• FALSE if the rendezvous does not exist.
When the specified rendezvous does not exist, an error is thrown and the script execution is stopped.
setEnabled(String, Boolean)
public void setEnabled(String RDVName,
Boolean isEnabled);
Parameters
isEnabled Boolean value of the new rendezvous state
Enables or disables a given rendezvous .
Disabling a rendezvous has the following consequences:
• Virtual users arriving at the rendezvous after it has been disabled are not detained.
• The virtual users that were previously detained at the rendezvous remain detained until their release (by
the rendezvous policy or after timeout).
698
unblock(String)
public void unblock(String RDVName);
Parameters
Releases all the virtual users detained at the specified rendezvous at that precise moment in time.
Any virtual users arriving at the rendezvous after the method is called are detained.
unblock(String, int)
public void unblock(String RDVName,
int virtualUserCount);
Parameters
virtualUserCount number of virtual users to be released. A negative number unblock

all virtual users (equivalent to unblock(RDVName)).
Releases a set number of virtual users detained at the specified rendezvous . The virtual users are released
on a FIFO (first in - first out) basis: the first virtual user to arrive at the rendezvous is the first to be released.
The number of virtual users released is spread among the generators according to their load.
There are some special cases:
• The specified rendezvous doesn't exist: an error is thrown and the script execution is stopped.
• The number of virtual users to be released is greater than the number of virtual users detained: NeoLoad
releases the number of virtual users detained
• The number of users specified is less or equal to 0: an error is thrown and the script execution is stopped.
unblockAll()
public void unblockAll();
Releases all the virtual users detained at that precise moment in time, whatever the rendezvous at which
they are detained.
Any virtual users arriving at the rendezvous after the method is called are detained.
Class RuntimeContext
This class represents the execution context of the script.
It is accessible from the pre-defined variable: "context" and should not be created directly.
699
Example:
var myvar = context.variableManager.getValue("myvar");

if (myvar==null) {
context.fail("Variable 'myvar' is not defined");
}
Synopsis
public class RuntimeContext {
// Public Fields
public VirtualUser currentVU ;
public VariableManager variableManager ;
// Public Methods
public void fail();
public void fail(String message);
public void fail(String errorCode,

String message);
currentVU
public VirtualUser currentVU ;
The Virtual User currently running.
variableManager
public VariableManager variableManager ;
The VariableManager
fail()
public void fail();
Mark the current script as failed and stops the execution of the script. A default error message will be
logged at ERROR level.
Note that the script exits, but the Virtual User keeps running and go to the next action.
700
fail(String)
public void fail(String message);
Parameters
message The message
Mark the current script as failed and stops the execution of the script. The specified message will be logged
at ERROR level.
fail(String, String)
public void fail(String errorCode,
String message);
Parameters
errorCode the error code for the NeoLoad action
message The message
Mark the current script as failed and stops the execution of the script. The specified message will be logged
at ERROR level.
Class VariableManager
Manages NeoLoad variables.
The two kind of NeoLoad variables are:
• The declared variables
These variables are explicitly declared in the Variables Panel of NeoLoad. They have a "Value change
policy" that defines when they should take a new value.
• The runtime variables
These variables are set at runtime, by Variable Extractors for example. Their values must be explicitly
changed to another value.
The VariableManager allows you to:
• get and set values of runtime variables
• get and change values of declared variables
Synopsis
public class VariableManager {
701
// Public Methods
public void changeValue(String variableName);
public String getValue(String variableName);
public String parseString(String text);
public void setValue(String variableName,

String value);
changeValue(String)
public void changeValue(String variableName);
Parameters
variableName the variable name.
Change the value of a declared variable like a File variable or a Counter variable.
Note that the variable name should be used, not the variable expression: use 'varname' and NOT
'${varname}'. Nevertheless, name can be composed: for example "data_for_${login}" if variable
"data_for_jsmith" is defined.
getValue(String)
public String getValue(String variableName);
Parameters
return the String value or null when not found.
Returns the value of a variable or null if the variable does not exist.
Note that the variable name should be used, not the variable expression: use 'varname' and NOT
'${varname}'. Nevertheless, name can be composed: for example "data_for_${login}" if variable
"data_for_jsmith" is defined.
Warning, the result is always a String. If the variable value represents a number, you may need to explicitly
convert it to a number before using it. Use parseInt(varname) or parseFloat(varname) for example.
// variable value is "45"

var varAsString = context.variableManager.getValue("myVar");
var varAsInt = parseInt(varAsString);
varAsString = varAsString + 1; // New value is "451"
varAsInt = varAsInt + 1; // New value is "46"
702
parseString(String)
public String parseString(String text);
Parameters
text the String
return the parsed text. Returns the same text if it contains no variables,
never returns null.
Evaluate a String that contains variables. For example, "the counter value is: ${counter}" will return "the
counter value is: 7".
Note that variables can be composed like ${var1_${var2}}
setValue(String, String)
public void setValue(String variableName,
String value);
Parameters
value the new variable value.
Assign a value to a runtime variable. It creates the variable if it does not exist. Note that the variable name
should be used, not the variable expression: use 'varname' and NOT '${varname}'.Nevertheless, name can
be composed: for example "data_for_${login}" if variable "data_for_jsmith" is defined.
When using the name of a declared variable, a runtime variable will be created that will override the
declared variable. It is not recommended to override declared variables.
Class VirtualUser
VirtualUser represents a Virtual User instance.
Typically, you have several instances of a Virtual User running at the same time.
Usually, for debugging purpose, you can get the id of the current Virtual User (e.g., "UserA#3") with
context.currentVU.id
Synopsis
public class VirtualUser {
// Public Fields
public String id ;
703
public String name ;
// Public Methods
public Object get(Object key);
public void put(Object key,

Object value);
public Object remove(Object key);
public void setCookieForServer(String serverName,

String cookie);
public void stop();
id
public String id ;
The id of the Virtual User (e.g., "User1#3"). This id is only valid if the Virtual User is context.currentVU.
In all other cases, this id will be null
name
public String name ;
The Virtual User name (e.g., "User1")
get(Object)
public Object get(Object key);
Parameters
key the key whose associated value is to be returned
return the value to which the specified key is mapped, or null if the current
Virtual User instance contains no mapping for the key.
Returns the value to which the specified key is mapped, or null if there's no mapping for the key.
put(Object, Object)
public void put(Object key,
Object value);
704
Parameters
key key with which the specified value is to be associated
value value to be associated with the specified key
Stores a user-defined object in the Virtual User instance. It associates the specified value with the specified
key.
remove(Object)
public Object remove(Object key);
Parameters
key the key whose associated value is to be returned
return the value to which the specified key is mapped, or null if the current
Virtual User instance contains no mapping for the key.
Removes the mapping for a key if it is present.
Returns the value previously associated with the key, or null if there's no mapping for the key.
setCookieForServer(String, String)
public void setCookieForServer(String serverName,
String cookie);
Parameters
serverName the NeoLoad name of the server.
cookie the cookie string
Sets a Cookie for the Virtual User instance. The cookie is associated with the specified server so that the
cookie will be sent in all following requests to the specified server according to the cookies settings: the
cookie will be sent if the cookie path matches the request path and if the expiration date is not reached.
The cookie must have the standard format: e.g., "name=value; expires=Thu, 2 Aug 2007 20:47:11 UTC;
path=/".
Note that name=value is mandatory, other information is optional.
Sample:
Sets a cookie that expires in 7 days, and that will be sent in requests which paths are under /app on the
server jack_80
var today = new Date();

var oneDay = 1000 * 60 * 60 * 24; // 24H in ms
var expires = 7 * oneDay;
var expires_date = new Date(today.getTime()+expires);
var cookie = "username=John; expires=" + expires_date.toGMTString() +"; \
705
path=/app";
context.currentVU.setCookieForServer("jack_80",cookie);
Important
The serverName parameters designs the NeoLoad name of the server, not the physical one. Check you
server names in the repository panel of NeoLoad.
To clear a Cookie
Set a Cookie with an expired date to remove the Cookie for the Virtual User instance. Note that the
cookie header should be removed from the request headers of the appropriate requests in the repository:
the requests that come after the Javascript and which URL match the server and path of the cookie.
Sample:
var expires_date = new Date(0);

var cookie = "username=John; expires=" + expires_date.toGMTString() +"; \
path=/app";
context.currentVU.setCookieForServer("jack_80",cookie);
stop()
public void stop();
Stops the execution of this Virtual User instance. Note that it stops only the current instance, the other
Virtual Users keep running. This action does not log anything, it is your responsability to log an error
message if needed.
706
Glossary
Action See Logical Action.
Assertion Validates a server response during a test by defining, asserting, a condition that
must be met. Validation can be based on the response content, size or duration.
NeoLoad can be configured to throw assertion errors when the conditions defined
by an assertion are not met. Other than clearly pointing out unexpected or faulty
behavior in load scenarios, assertions and assertion errors also reveal functional
issues.
Average 90% The average 90% is calculated for response times by removing the lowest and
highest 5% of values to iron out any outliers. The resulting figure is close to the
one obtained by the majority of end-users.
Basic Authentication Within the context of an HTTP transaction, basic authentication is an operation
whereby the browser includes user account information (login and password) in
a request. The information is sent as plain text (merely base64 encoded) in the
Authorization header .
See Also NTLM Authentication.
Business Transaction See Container.
Container A virtual user container groups the different web pages that make up a "business
transaction". In other words, a container is a set of web pages that carry out a
business exchange. A typical example of this type of container is the set of pages
used to connect to the application. These containers are clearly marked in the test
results to make analyzing download times easier.
File Variable A file variable takes its values from a file with a format such as a comma separated
values (CSV) file. To use a file variable, the file from which the values will be
read has to be configured.
See Also Variable.
Form Extractor The form extractor is used in a "Submit a form in the previous
request" -type request. This process extracts a form in the server response's
HTML code so that its values can be injected into the current request.
See Also Variable Extractor.
HTTP Request The HTTP request sent to the server to retrieve an HTML page, image or CSS file.
Requests are grouped within pages.
HTTP Response The HTTP response is the Web server's answer to an HTTP request.
Link Extractor The link extractor is used in a "Follow a link from the previous
request" -type request. This process extracts a link in the server response's
HTML code so that it can be used in the scenario.
List Variable A list variable is a variable whose values are sourced from a specific list within
NeoLoad.
See Also Variable.
Load Generator The load generator is a program controlled by the controller, which plays a
scenario while simulating a predefined number of users. A load generator is run
707
Glossary
by its load generator agent for each test. This term may refer either to the program
simulating the users, or to the machine on which it is installed.
Load Generator Agent The load generator agent responds to the NeoLoad controller's instructions to start
and stop the load generator for each test. The NeoLoad controller has an agent
and load generator built in for ease of use. Additional agents may be installed on
other machines if required.
Logical Action A logical action is used to enrich the content of a virtual user's behavior pattern.
Typical examples of logical actions are loops, to repeat a sub-series of web
pages, pauses, to represent a user's waiting time, and containers, which can
group several pages within a business transaction.
See Also Container.
Long Polling Long polling is a method used by the Push technology and is a hybrid of polling
and streaming. As with polling, it uses a mechanism whereby a request is sent by
the client to the server at regular intervals. As with streaming, the server keeps
the connection open to send messages in real time. The connection is periodically
interrupted in order to generate a new request.
See Also Polling, Streaming.
Monitor A monitor observes the behavior of a component part of a monitored machine

(web server, application server, operating system, database...). A monitor groups
together several performance counters and indicators.
See Also Performance Counter, Performance Indicator.
Monitored Machine A monitored machine is a server, or other device in the infrastructure, that is to be
monitored. A monitored machine may be a physical machine or a network device.
A monitored machine groups together several monitors.
See Also Monitor.
NTLM Authentication NTLM (NT LAN Manager) is an authentication protocol used by many Microsoft
servers. The protocol uses encryption to securely transmit passwords. See the
Microsoft [http://www.microsoft.com] website for further details.
See Also Basic Authentication.
Performance Counter A performance counter is a numeric value that shows the state of one of the
monitor's elements.
See Also Performance Indicator.
Performance Indicator A performance indicator is a text value, comprising several lines of text, that shows
the state of one of the monitor's elements.
Polling Polling is a mechanism used by the Push technology whereby a request is sent by
the client to the server at regular intervals. In return, the server updates the status of
each connected client. Between two polling requests, the server stores the updates
sent to the client in its memory until the next polling request is received.
See Also Push.
Population A population is a group of virtual user types which allows the application to be
tested using different business actions. One typical example is when testing a e-
business website with 90% of users browsing the catalog and 10% making an on-
line purchase.
Push Push technology is a type of communication where information is "pushed" by the

server to the browser, contrary to the normal "pull" principle whereby the browser
708
Glossary
initiates the request for information. There are several Push methods: polling, long
polling or streaming.
See Also Polling, Streaming.
Push Message In Push technology, a Push message is a container of actions that defines the
actions or business transactions to be executed when a message is received. A Push
message is defined by a list of conditions that must be met for it to be executed.
See Also Push.
Recording Proxy The NeoLoad component which records the requests. It is seen as a proxy by the
browser and may connect to the server via a user proxy if required.
See Also User Proxy.
Regex See Regular Expression.
Regular Expression Regular expressions are used to find sub-strings that match a specified pattern.
In NeoLoad, they are used to define character strings for extraction (see Variable
Extractor) or rules for validating text (see Assertion).
More information is available in the'Appendix A, Regular Expressions chapter.

Scenario A scenario sets out all the test parameters: duration, load policy (constant, ramp-
up, peak or custom), number of virtual users to be generated etc. NeoLoad can
manage several scenarios for each project.
See Also Virtual User.
SOAP SOAP (Simple Object Access Protocol) is a lightweight protocol for the exchange
of information in a decentralized, distributed environment. It is an XML-based
protocol that consists of three parts: an envelope that defines a framework for
describing what is in a message and how to process it, a set of encoding rules
for expressing instances of application-defined data types, and a convention for
representing remote procedure calls and responses. See W3C [http://www.w3.org/
TR/soap/] for more details.
See Also WSDL.
Standard Deviation Standard deviation is a measure of the variation in response times compared to
the average. A high value indicates wildly fluctuating response times, whereas a
low value indicates that the response times are consistent and stable.
Streaming Streaming is a mechanism used by the Push technology whereby a blocked request
is sent by the client to the server. In other words, the client never completely
finishes reading the server's response to the request, the server sending back
several separate response packets in the same flow.
See Also Push.
Think Time The think time is the time specified to simulate the time taken by a real user to
read one page before clicking to the next.
It's possible to use a global think time for all pages (use a variable to obtain a
dynamic value within an interval), or define a think time for each separate page.
See Also Variable.
TTFB (Time to First Byte) The time taken, in seconds, to receive the first byte of the server response.
Equivalent to the time taken by the server to start sending the response, excluding
download time.
709
Glossary
User Proxy A proxy in the usual sense: a proxy server used to connect to the web server.
See Also Recording Proxy.
Variable Variables are used to add dynamic content to a scenario, for example, by
submitting dynamic form parameters or connecting to the server using different
user accounts. The different types of variables include: counter, list, random
integer, random string, date....
See Also File Variable, List Variable.
Variable Extractor A variable extractor is used to extract content from a server response during a test
and assign the extracted content to a variable. This variable can then be used for
the rest of the scenario.
See Also Variable, Link Extractor.
Virtual User A virtual user simulates the browsing actions of an application's real user. It
consists of a series of web pages and may contain logical actions such as
containers, loops and think times in order to simulate more complex behavior
patterns.
Web Page A page or Web page is the web page as displayed by the web browser. It consists
of an HTML request and its sub-components, such as images or CSS files.
WSDL WSDL (Web Service Definition Language) is a specification defining how

to describe web services in a common XML grammar. See W3C [http://
www.w3.org/TR/soap/] for more details.
See Also SOAP.
XPath XPath is a non-XML language used to describe one part of an XML document.
710
isFatalEnabled, 695
Index isInfoEnabled, 696
isWarnEnabled, 696
A L
Assertion, 517, 554, 650
List Variable, 497
Load Generator, 389, 408
C Load generator, 402
changeValue, 702 Load Scenario, 513
Classes Logger, 693
Logger, 693
RendezvousManager, 696 M
RuntimeContext, 699
marqueur, 571
VariableManager, 701
Methods
VirtualUser, 703
changeValue, 702
Container, 83, 402, 408, 408, 415, 465
debug, 694
currentVU, 700
error, 694
fail, 700, 701, 701
D fatal, 694
debug, 694 get, 704
getValue, 702
E hasRendezvous, 697
info, 694
error, 694
isDebugEnabled, 695
isEnabled, 698
F isErrorEnabled, 695
fail, 700, 701, 701 isFatalEnabled, 695
fatal, 694 isInfoEnabled, 696
Fields isWarnEnabled, 696
currentVU, 700 parseString, 703
id, 704 put, 704
name, 704 remove, 705
variableManager, 700 setCookieForServer, 705
File Variable, 497 setEnabled, 698
Form Extractor, 557 setValue, 703
stop, 706
G unblock, 699, 699
get, 704 unblockAll, 699
getValue, 702 warn, 696
H N
hasRendezvous, 697 name, 704
HTTP Request, 501, 504, 514, 558
HTTP Response, 514, 545, 557, 564 P
paramètre de framework, 576
I parseString, 703
id, 704 Population, 228, 388, 402, 408, 513
info, 694 put, 704
IP spoofing, 390
isDebugEnabled, 695 R
isEnabled, 698 Recording Proxy, 37
isErrorEnabled, 695 Regular Expression, 179, 518, 549, 672
711
Index
remove, 705
RendezvousManager, 696
RuntimeContext, 699
S
Scenario, 387
setCookieForServer, 705
setEnabled, 698
setValue, 703
SOAP, 111
SSL, 67, 487
stop, 706
T
Think time, 5
Think Time, 94, 463
U
unblock, 699, 699
unblockAll, 699
User proxy, 38
V
Variable, 545
Variable Extractor, 179, 545
variableManager, 700
VariableManager, 701
Variables, 186, 229
VirtualUser, 703
Virtual User, 498, 499, 506, 511, 513, 517, 649
Virtual User Container, 490
W
warn, 696
Web Service, 111
712

Neoload Manual Document

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Neoload Manual Document

Enviado por

Direitos autorais:

Formatos disponíveis

NeoLoad® Documentation

Adobe Flex/AMF ...................................................................................... 46

Stop Virtual User .................................................................................... 192

Microsoft Windows Monitor ..................................................................... 281

Generating a Report ................................................................................. 410

Advanced Configuration ................................................................................... 448

Network Tuning and Configuration .................................................................... 471

Extracting a URL parameter value .............................................................. 673

502 Bad Gateway .................................................................................... 686

• an Introduction to load testing,

Thank you for choosing NeoLoad.

Any comments, feedback or suggestions are welcome, either by mail to <feedback@neotys.com>.

This software includes software libraries developed by L2FProd.com (http://www.L2FProd.com/).

About Load Testing

• test a web site's vulnerability to crashing under load.

Load Testing with NeoLoad

2. Defining test parameters

3. Running the test

4. Analyzing the results

Procedure 2.1. Installing NeoLoad on an unsupported Unix platform:

CPU & Memory

A minimum of 1024 Mb system memory is recommended.

• design scenarios using the GUI,

Unix (GUI installer):

Unix (command line):

Installer in console mode

Installing a Load Generator

Unix (GUI installer):

Unix (command line):

Install in console mode

License Key Management

The Standard Key

Installing the license key

Procedure 2.2. Installing the standard license:

2. In the "License" section, select "Use a license file".

3. Click the "Enter a license key..." button.

Activating the license key

There are two ways to activate the license:

• Activating by e-mail or web form:

1. NeoLoad generates a license activation request file named "license.req".

5. Select "Enter an activated license key".

Transferring the license key

The transfer procedure can take a few hours to be processed by Neotys.

Procedure 2.3. Transferring the license key

2. Click the "Transfer to another computer..." button.

3. NeoLoad generates a disable request file named "license-inactivation.req".

4. Send this file to Neotys by e-mail at <activation@neotys.com>.

The Floating Key

Installing the floating key

Reserving a floating key

Procedure 2.4. Reserving a key

2. In the "License configuration" section, select the "Connect to a license server"

5. Select the appropriate license, then click on the "Get" button.

6. Choose the reservation type :

Releasing a floating key

2. Click on the "Release..." button.

In this case, there are two choices:

2. Transfer the key to another machine

Switching from a floating license to a standard license

In this case, there are two choices:

1. Either release the floating key, or

Running from the command line