Run time error “Server Error in ‘LoadTest’ Application.” when we click on test

Run time error “Server Error in ‘LoadTest’ Application.” is observed when we click on scenario both in My Performance Center and DesktoClient version 12.56 .

The full error message is:

Server Error in ‘/LoadTest’ Application.

Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a “web.config” configuration file located in the root directory of the current web application. This <customErrors> tag should then have its “mode” attribute set to “Off”.

<!– Web.Config Configuration File –>

<configuration>
<system.web>
<customErrors mode=”Off”/>
</system.web>
</configuration>
image text
The test can be edited but in the summary tab the error message appears.

The issue is observed when analysis template and/or resource monitors which were deleted from the project are used it the problematic test.

To overcome the issue the missing analysis template and/or resource monitors should be removed from the test.

1. If the test is using a deleted analysis template the options are in the test to choose another analysis template or the default analysis template by following the steps below:

Click on a problematic test
Click on Edit test button
In test window select Advanced-> Analysis Template Options
In the Analysis Template Options select:
Use default Analysis Template
Click on OK
Save the test

2. If the test is using a deleted monitor the missing monitor need to be removed from to test or substituted it with an existing monitor.

To delete a Monitor please follow the steps below:

Click on Associated Monitors tab
Select the missing Monitor
Click on Remove Selected
To add an existing monitor

Click on Associated Monitors tab
Select “Add Monitor Profile” or “Add Monitor OFW”
Select the Monitor from Select Monitors part of the screen.

Advertisements

The Docker image names which are displayed by default in Performance Center Administration (under Orchestration) are misspelled

In the Docker Images tab in Orchestration, the predefined image names below are misspelled, and the images do not actually exist until they have been pulled from Docker hub into the local orchestrator.
1. performancetesting/load_generator_linux:12.60
2. performancetesting/load_generator_win:12.60

To fix this issue
1. Delete the default images, and then create new images as follows:

For a Dockerized Linux 12.60 Load Generator image:
1. Image Name: performancetesting/load_generator_linux
2. Image Type: UNIX (not Linux as in predefined image)
3. Purpose: Load Generator
4. Image Tag: 12.60

For a Dockerized Windows 12.60 Load Generator image:
1. Image Name: performancetesting/load_generator_windows
2. Image Type: Windows
3. Purpose: Load Generator
4. Image Tag: 12.60

2. Pull the images from your Orchestrator node (Swarm/Kubernetes). For example:

Docker pull performance testing/load_generator_windows:12.60

Micro Focus introduces New Protocol : TruWeb

Micro Focus has introduced a brand-new protocol to its outstanding line up of protocols. TruWeb is created with a developer mindset. It is a protocol that focuses on the HTTP (transport) level, providing a lightweight, scalable and cross-platform solution for web protocol testing.

This protocol is available in version 12.60 of LoadRunner and Performance Center as well as StormRunner Load. You can start to take advantage of the capabilities that TruWeb has to offer. You can write a TruWeb script using Virtual User Generator (VuGen), Atom.io, JetBrains WebStorm (IntelliJ), or other IDEs and tools.

TruWeb allows performance engineers, testers and developers create scripts on any platform. It supports Windows, MacOS and Linux. You can record scripts via HAR files or the TruWeb Proxy Recorder. On top of this, TruWeb can also be ran as a standalone solution. You can run TruWeb in single mode, which runs a single iteration for a single Vuser, or in load mode, which runs the script use the scenario settings defined in the scripts scenario.yml file.

TruWeb is currently in Tech Preview. It is in its first phase of its release. The below links will allow you to read more of the current capabilities as well as download and give it a test drive.

TruWeb is currently in Tech Preview. Meaning you do not need a license to run it. However, this may change in future versions.

HPE Diagnostics User Interface freezes or hangs

Having launched the HPE Diagnostics User Interface (UI) by clicking on “Open Diagnostics” (or “Open in This Window”) and entering a user name and password, performing an action such as viewing the data for long periods (days or weeks) for all Java Probes may result in the UI freezing and no further actions being possible. This issue may occur in a larger Diagnostics environment where there are many Mediators and numerous probes.

Once the Diagnostics UI has frozen no recovery is possible and the browser tab displaying the UI must be closed. The UI can then be opened in a separate browser tab (or new browser instance) however it is likely that the freeze behavior will re-occur.

A possible cause is that the Java applet which runs the Diagnostics UI has insufficient memory such that while the UI is performing the user action, the applet process runs out of memory and terminates. When this process terminates, the UI remains visible in the browser but is no longer functional.

To confirm that the Java applet process is terminating, open the Windows Task Manager and locate the process named “jp2launcher.exe”. This process will appear while the Diagnostics UI is being initialised (after the user name and password are validated):

image text

If the “jp2launcher.exe” is no longer visible when the Diagnostics UI freezes, then the process may have run out of memory.

A workaround for this issue is to increase the heap (memory) available to the Java applet. This can be done by modifying the Java runtime parameters as follows:

1) Open the Windows Control Panel and search using “Java” to locate the “Java (32-bit)” Control Panel entry. Click on the entry to open the Java Control Panel:

image text

Note: If there is no “Java (32-bit)” Control Panel entry this may be due to there being multiple Java versions installed on the client platform. Locate the Java 32-bit installed in a folder under “C:\Program Files (x86)” (typically “C:\Program Files (x86)\Java\jre7\bin”) and execute the file “javacpl.exe” using right-click “Run as administrator”.

2) Click on the “Java” tab and then on the “View” button to open the “Java Runtime Environment Settings” dialog.

3) The default heap size is typically 256MB however this may be system dependent. The actual process memory size can be seen in the Windows Task Manager before the process terminates. Specify a larger heap size and test to see if the UI freeze remains present – increase as needed. The following example confgure a 700MB heap however up to 1GB (“-Xmx1G”) may be used (as this is a 32-bit process memory is limited):

image text

LoadRunner Upload – Download file / Operative System 4 GB Memory Limitation

Each operating system has a physical memory limit which reciprocally define the boundaries for memory and address space that can be used by the processes, services, objects and services executed over the current operative system version.

Following is the memory limits that are present in Windows OS and how it affects the mdrv.exe process emulation when uploading/downloading large files, generating a reaction where the mdrv will crash, hangs or result in a memory violation.

 The implementation of LR file uploading/downloading is not optimized for huge file. It always reads all the files to memory before upload. That means, for files with 1 GB in size, mdrv has to   obtain 1 GB sequential memory space in the process for each Vuser. However, mdrv is a 32 bit process. In windows system, a 32 bit process has at most 4 GB in memory space, and only 2 GB of them can be used by developer. If the user tries to upload a file with 2 GB in size, it is almost impossible to find proper memory for it, since the other functions will also use some memory.

When the file size is smaller, like 500 MB to 1 GB, it will be possible to make the upload successful. But when we run the script in controller, we should make the Vuser run in process mode.

From the Operating System perspective and as a workaround it is possible to switch the memory use and memory address space allocation to 3 GB for the application and less 1 GB for the operating system.

In order to increase the memory and address space to 3 GB limit we need to be implement the following steps.

  1. Right-click on the Command Prompt icon in the Accessories program group of the Start menu. Click Run as Administrator.
  2. At the command prompt, enter:

bcdedit /set IncreaseUserVa 3072

  1. Restart the computer.
  2. Run the script one more time in VuGen and in the Controller using the LG as process.

For disabling  the  memory increase here is the command.

  1. Right-click on the Command Prompt icon in the Accessories program group of the Start menu. Click Run as Administrator.
  2. At the command prompt, enter:

bcdedit /deletevalue IncreaseUserVa

  1. Restart the computer.

Error -27732: Internal Error – can’t get initial credentials for username/password

The following error appears in web based protocol replay:

Error -27732: Internal Error – can’t get initial credentials for username/password

Wrong configuration of the required elements to make the script replay while using Kerberos authentication

Wrong username password:

  1. In the script go to the web_set_user function
  2. Verify that the username and password specified are correct

Wrong KDC IP:

  1. Open the windows environment settings
  2. Check the krb5.ini location specified in KRB5_COFIG
  3. Open the krb5.ini in an editor
  4. Check the KDC IP specified is as seen in wireshark recording of the application

Error -27732: Internal Error – can’t parse username

The following error message appears during the replay of web based script:

Error -27732: Internal Error – can’t parse username

The KRB5_CONFIG was defined under the System variables. Currently only exact path name is supported.

  1. Open the Windows’ Environment Variables
  2. Search for KRB5_CONFIG in System variables
  3. Verify the path is exact (For example don’t use %windir%)
  4. Correct and save the file path
  5. Restart VuGen