Troubleshooting performance testing

This topic provides information about how to troubleshoot several problems with Test Performance.

If you run tests and encounter problems, make sure that you have followed all the Performance testing tips.

If an error message is displayed when you run tests, try looking up the error message in the Performance testing error messages section of the online help. Only the most common error messages are listed. If no error message is displayed when you encounter a problem, open the error log by clicking Window > Show View > Error Log. If the workbench shuts down while running tests, restart the workbench and examine the error log. By default, warning and error messages are logged. You can increase the default logging level by clicking Window > Preferences > Logging. The log file is stored in the .metadata directory of your workspace. To avoid excessive logging, the Logging Level should be adjusted for individual Logger Names in the Loggers tab. For example, to get more information about a problem connecting with IBM® Engineering Test Management, increase the Logging Level for com.ibm.rational.test.lt.rqm.adapter Logger Name. For the licensing issue, adjust the level for com.ibm.rational.test.lt.licening Logger Name. When you no longer need the extra logging, use the Restore Default button in the Logging Preferences to reset all the levels to their recommended defaults.

You might encounter some of these problems while performance testing:

Connectivity problems between workbench and agent computers

If the workbench stops or locks up when you attempt to start running tests, it is important to confirm that all the agent computers are running. Perform the following steps to confirm your installation is properly configured:

Confirm that there is sufficient disk space available on the workbench computer and the agent computers.
Restart the workbench computer.
Verify the network connectivity between the workbench computer and agent computers. To confirm the hostname in majordomo.config file can be DNS resolved on the agent machine, use a shell ping to the workbench hostname. If the ping results fail use the IP address of the workbench instead.
Confirm the server port number on the test workbench computer. Click Window > Preferences > Server. This is the port number that should be specified in majordomo.config file on the agent machines.
Restart the agent computers and verify the Majordomo process is running.
On the agent machines, set the optional debug flag in the majordomo.config file. Set the value equal to true; the default value is false. You do not have to restart the agent. Within about ten seconds it should automatically pick up the changes to majordomo.config.

Look in %TEMP% directory for the majordomo.log file. This file contains information about the attempts to contact the workbench including information about any failures and the reason for the failures.

On the Windows operating system, the %TEMP% directory is typically at %USERPROFILE%\AppData\Local\Temp.

If the majordomo service is configured to log in as Local System Account, then the %TEMP% directory is at %SystemRoot%\TEMP, typically C:\Windows\TEMP.
You can check the agent status on the workbench computer by clicking the icon. For the Agent Controller, you can attempt to share files between the workbench computer and agent computers. Click Window > Preferences > Agent Controller > Hosts, and then add the agent computers as hosts, and click Test Connection to test connectivity to the instances of the Agent Controller that are running on the agent computers.

Recording configuration problems

No HTTP traffic is captured while recording: See Recording reliable HTTP tests for instructions on configuring your web browser. If you are attempting to use Internet Explorer to record tests from a secure website, see Configuring Microsoft Edge for recording on a secure website. Disable firewalls on the workbench computer and the agent computers.
No traffic is captured while recording: Ensure that the recorder type that you select matches the protocol in use by the system under test. For example, do not attempt to use the HTTP recorder if the system under test uses the Citrix protocol.
No test is generated after recording: When the test generator cannot create a test from the recorded traffic, typically an error message is displayed or written to the error log. Try looking up the error message in the Performance testing error messages section of the online help.
Recorder controls are not available: If you use a workspace from a different version of the product, the recorder controls might not be available. Instead, the recorder controls from the other version of the product are displayed. Click Window > Reset Perspective to reset the Performance Test or Service Test perspective. Alternately, click File > New > Other to select the wizard to use.

Problems running large tests or long-run tests

If a test runs but ends with errors, check that the workbench computer and agent computers meet the hardware and software requirements that are detailed in the installation guide. Pay close attention to the memory and disk space requirements. See Increasing memory allocation for more information on how to set the maximum heap size to avoid out-of-memory errors. Monitor processor and memory usage on the workbench and agent computers and watch for excessive processor use or excessive memory use by javaw.exe or java.exe processes.

Run tests with fewer virtual users that use the default schedule settings to determine whether the behavior is linked to the number of users. Examine the test log for error messages that the system under test generates. Run tests with a single virtual user and make sure that the system under test is not generating errors, before you attempt to run tests with a large number of users. If you encounter problems, restart the workbench and agent computers before attempting to run tests again.

If the workbench shuts down while running tests, search for file names that begin with javacore. The name of javacore files includes the date, time, and process ID. If you find a javacore file with a date, time, and process ID matching the workbench, open the file in a text editor. You can find the reason for failure at the beginning of the javacore file.

Data correlation errors

If you can record tests successfully, but the expected behavior is not triggered in your application when you run tests, you might need to perform manual data correlation. Typically when additional data correlation is needed, the test log includes messages similar to this message:Unable to extract the value. To troubleshoot data correlation problems, try running tests using only one virtual user running on the workbench computer, and compare the playback to the recorded test to determine which responses from the system under test are unexpected. See Debugging HTTP tests to learn how to use the test log and the Protocol Data view to troubleshoot HTTP tests. To learn more about data correlation, see Correlating response and request data.

Common errors integrating with IBM® Engineering Test Management

All modes of the adapter use the Eclipse error log. You can view the log by opening the workbench and clicking Window > Show View > Error Log. By default, warning and error messages are logged. You can turn on more detailed logging for the adapter by clicking Window > Preferences > Logging. The log component for the adapter is named com.ibm.rational.test.lt.rqm.adapter.

If you are running the adapter as a Windows™ service or from the command line, you can view the adapter.log file without opening the test workbench.


Problem	Solution or cause
Where do you look for errors or warnings?	In the workbench, click Window > Show View > Error Log.
You do not see the adapter available for selection.	Verify that the Engineering Test Management server address that is provided to the adapter is correct. Provide the correct address. Check the provided login and password. Provide the correct password.
The adapter continuously fails to connect to Engineering Test Management.	Make sure that the server is running. If necessary, restart the server or check network connectivity.
The adapter is displayed as red in the selection dialog.	The adapter is not communicating with the server. The adapter might already be in use.
You attempt to import a script from the adapter but no scripts are found.	Make sure the project path that is entered in Engineering Test Management is a project under the workspace that is associated with the running adapter. You have to enter only the project name. This is less error prone than typing the complete project path, but either forms are acceptable. If running from the command line or as a service, be certain the WORKSPACE_DIR environment variable that is set in the adapter.config file is the same path as seen in the select workspace dialog when running the test workbench. Be careful not to set the path to a project folder under the workspace directory. Make sure that you are not using a workspace that contains a project that was copied from a shared location. A workspace that contains projects from shared locations cannot be used for projects that are not shared.
The adapter is running from the command line or as a service, and tests continue to fail.	Run the adapter in GUI mode so that you can see what happens when the test workbench runs the test script.
Adapter Windows™ services does not start. A error message states that the service failed to start in a timely fashion.	Ensure that the computer has .NET 2.0 or later. This platform can be installed from the Windows™ Update Site or manually. For more information on installing .NET, see http://support.microsoft.com/kb/923100.
When testing shared assets, the execution fails with and an `IOException` message is displayed.	The most likely cause is that the Engineering Test Management to UNC shared location is not set up correctly. From Engineering Test Management, ensure that you can access the UNC shared directory without being prompted for a password. You might have to map a drive on Windows™ for the Engineering Test Management system to log into the UNC share. Ensure that you have defined the shared resource in Engineering Test Management under Admin > System Properties > Resources. Ensure that the test-script points to a shared location that still exists. If you have associated a Engineering Test Management test script with a shared location that has changed (for example if the IP address has been reassigned) you might need to reassociate every test script Ensure that the UNC shared directory that is specified in Engineering Test Management points to a project.
When testing shared assets, the execution fails with a low level model error.	Ensure that the adapter has the required protocol extensions installed. The test assets located on the shared location can only be run on an adapter workspace that supports those protocols.
Service tests that were created in a previous version of the product cannot be run.	Upgrade every SOA asset to the latest version.
The adapter cannot connect to the server, and one of the following error messages is displayed: `Communications error with server` `Error occurred while registering the adapter`	When using Engineering Test Management 3.0 or later, the server URL that is configured for the adapter must exactly match the public URI of the Engineering Test Management server. The server public URI is available on the Engineering Test Management administration page. By default the administration page is at https://`servername`:9443/qm/admin. The adapter user must be a member of the Engineering Test Management project area. Open the project area administration page on the Engineering Test Management server to determine whether the adapter user is a member of the project area. For Engineering Test Management 3.0 and later, the adapter user must be a member in the test team member role, not the test team contributor role. This error can also occur if you have modified these roles from their defaults.

Error when running the Docker command

When you run the Docker command, if the user specified ID does not match the hardcoded user ID 1001 in the Docker image, the test run fails.

Problem Cause Solution

Problem	Cause	Solution
When you run a test with the Docker image without specifying the run as user (-u) option, or if you specify the option but, as a user, you use an ID of a incorrect or non-existent user ID, the following error is displayed: Eclipse: An error has occurred. See the log file /tmp/home/.eclipse/com.hcl.onetest.performance -20230531_1900_10.5.400_58521712_linux_gtk_x86_64 /configuration/1686156215689.log. java.io.FileNotFoundException: /tmp/ memento942333548370101376-out.dat (No such file or directory) at java.io.FileInputStream.open (FileInputStream.java:195) at java.io.FileInputStream.<init> (FileInputStream.java:138)	The default user ID in the Docker image is hardcoded as 1001. When you run a Docker command and your user ID is different from the hardcoded user ID, you might see permission issues when the workspace is created.	To work around this problem, you must specify the Docker command with the -u {user id of the current user or just 0 for root} as follows: -u `id -u` `-u 0` The following command is used in a Docker-compose file: `rpt-wb: image: hcl-onetest-studio:10.5.3 user: '0' entrypoint: cmdline -workspace /RPTWorkspace_HCL -project Proj1_v1052 -schedule Schedules /Sche_2Agts.testsuite -results autoResults -stdout -exportstatshtml /Results -exportlog /testlog.txt -vmargs "-Dhptcostconfirm" ports:`

When you run a test with the Docker image without specifying the run as user (-u) option, or if you specify the option but, as a user, you use an ID of a incorrect or non-existent user ID, the following error is displayed:

Eclipse:
An error has occurred. See the log file
/tmp/home/.eclipse/com.hcl.onetest.performance
-20230531_1900_10.5.400_58521712_linux_gtk_x86_64
/configuration/1686156215689.log.
java.io.FileNotFoundException: /tmp/
memento942333548370101376-out.dat 
(No such file or directory)
at java.io.FileInputStream.open
(FileInputStream.java:195)
at java.io.FileInputStream.<init>
(FileInputStream.java:138)

The default user ID in the Docker image is hardcoded as 1001. When you run a Docker command and your user ID is different from the hardcoded user ID, you might see permission issues when the workspace is created.

To work around this problem, you must specify the Docker command with the -u {user id of the current user or just 0 for root} as follows:

-u `id -u`

-u 0

The following command is used in a Docker-compose file:

rpt-wb:
    image: hcl-onetest-studio:10.5.3
    user: '0'
    entrypoint: cmdline -workspace /RPTWorkspace_HCL 
   -project Proj1_v1052 -schedule Schedules
    /Sche_2Agts.testsuite -results autoResults 
   -stdout -exportstatshtml /Results -exportlog 
    /testlog.txt -vmargs "-Dhptcostconfirm"
    ports: