Currently the replay of Ajax TruClient scripts do not support multithreading mode, that is, scripts could only be replayed in "Run as Process" mode.
Ajax TruClient is a GUI based protocol and during the replay a separate instance of Gecko (Firefox layout engine) is created for each Vuser. If you run 50 Vusers you will have at least 50 processes, just like if you open 50 instances of Firefox browser. That’s why the protocol consumes so much resources (RAM and CPU).
In Windows XP, Ajax true client script replays fine in interactive mode, but fails in load mode when replaying "wait for object" with the "
Error -203256: ** 16: Wait for …** failed – target object was not found".
There is an issue with Windows XP that is connected to some dlls that are duplicates in the Gecko dir under LoadRunner and in the System32 dir.
This might create some problems during load replay
Add "<LR install folder, full path>\bin\gecko" to the beginning of the path environment variable
[Net An. Warning (1590: d10)] Request Connection: Remote Server @ xx.xxx.x.xxx:443 (Service=) Failed attempt #1. Unable to connect to proxy (@ xx.xxx.x.xxx:xxxx): sid = xxxx, rc = 10056)
[Net An. Warning (1590: d10)] Request Connection: Remote Server @ xx.xxx.x.xxx:443 (Service=) Failed attempt #2. Unable to connect to proxy (@ xx.xxx.x.xxx:xxxx): sid = xxxx, rc = 10056)
In secure http communication, the "handshake" syncs the server and the client up with the encryption methods and keys that will be used for the remainder of the communications. A successful handshake creates the new "secure key" that the remainder of the connection will be using.
In this case, the client tries to set up a secure connection (ssl handshake) every time, instead of using the "secure key" that was created during the first successful handshake, for the remainder of the session. The ssl handshake succeeded on the some attempts but was failing on other requests, and that is why Internet explorer was freezing randomly at different steps in the business process.
Open "Registry Editor" in Windows (Start menu > Run > regedit)
Set the value for "ReuseSSLSession" to 1
By doing this, we are ensuring that the "secure key" created during the first successful ssl handshake, is reused for the entire session instead of the client trying to do a ssl handshake every time.
While recording with RDP Protocol, RDP Client is throwing the error "The connection was ended because of a network error. Please try connecting again to the remote computer again"
The Encryption Level of the RDP-TCP connection on the Terminal Server is set to FIPS Compliant.
To disable the FIPS encryption level by changing the Encryption level setting in the RDP-Tcp Properties dialog box, follow these steps:
1. Click Start, click Run, type tscc.msc in the Open box, and then click OK.
2. Click Connections, and then double-click RDP-Tcp in the right pane.
3. In the Encryption level box, click to select a level of encryption as Client Compatible.
The LoadRunner Controller returns the following error when the user tries to configure a Windows Resource Monitor on an Application Under Test (AUT) server:
Error: Cannot connect to <AUT Server Name> – Network path cannot be found.
Hint: Check that your login username appears as administrator on this machine
Tips on configuring a Window Resource Monitor:
1. Make sure that you are authorized to monitor the remote machine.
For more information, refer to the post – “ How to ensure proper authentication when using the Windows Resources Monitor “in this site
2. By default, Windows machines enable monitoring only for users with administrator privileges. If you do not have administrative privileges, refer to “ How to enable non-administrator users to remotely monitor a machine with Windows Resource Monitor “ in this site
3. Make sure that "Remote Registry" service is started on the machine that you want to monitor against. To start the "Remote Registry " service:
a. Go to Start -> Settings -> Control Panel -> Administrative Tools -> services.
b. Right mouse click on "Remote Registry ", and select <Start>.
How does the Network Speed Simulation in the Vuser Runtime Settings work? Does it calculate the transaction response times at different speeds based on the size in bytes of the HTTP responses?
That is, if you set the Vuser setting to run at 1 MBs as a custom speed, how does LoadRunner determine what the response time for a transaction should be?
Does it take the size in bytes for an HTTP response, and then determine based on bytes per second how long the response time should be?
Bandwidth throttling doesn’t predict the response time. It only limits the amount of bandwidth available to a process or thread using the operating system’s own control.
If the bandwidth required exceeds what is available, this will impact response times and be reflected in the results.
But setting this doesn’t automatically result in higher response time calculations.
In LoadRunner 11, the following error is displayed in the replay log of a Java script (Java Record Replay, Java Over HTTP, Java Vuser):
Error: Failed to find java
As mentioned in the LoadRunner 11 readme, VuGen recording is not supported on 64-bit applications. However 32-bit applications can be recorded on 64-bit operating systems.
This error message appears if the 64-bit version of the Java SDK has been installed on the machine.
To fix this issue
· Uninstall the 64-bit version of the Java SDK,
· Install the 32-bit version of the Java SDK.
Note: LoadRunner 11 does not currently support Java 7