Internal Error (call customer services): ptObjMgr is NULL

This warning occurs when parsing html pages. These are pages in which images, sound files, etc. are embedded into the actual HTML code. For this reason the page cannot be parsed like a regular html page.


To be able to parse this type of page, you can change the following Run-Time Setting:

Run-Time Settings> Preferences> Options> Change "Parse HTML Content-Type" from "TEXT" to "ANY" and Replay the script.

Though this warning can be ignored as long as the script runs fine and completes the business process. So, it's recommended to replay the script with web_reg_find() for each page and verify whether all web_reg_find() functions are successful. Also, compare recorded and replayed snapshots. If everything is fine then we can ignore this warning message.

How to determine correct communication protocol your application is using to achieve successful recording in LoadRunner Vugen?

LoadRunner is tested based on the communication protocols and not on specific application. To record any application in LoadRunner, one needs to find the protocol that the client and server use for communication. Most application besides using the necessary TCP/IP protocol, also use an application level protocol (E.g.: HTTP, SNMP, etc.) Which run over the TCP/IP network protocol? If the application uses an application level protocol, then the corresponding Vuser type from Vugen can be selected to record the application. Sometimes the application uses combination of protocol, in Which case multiple protocols can be selected at the same time to do the recording. If the application just sends messages over TCP/IP without using any higher level protocol, then the option to use is Winsock protocol. Since Winsock does recording at the network (TCP/IP) level, it is less intuitive. You need to find out from the application developers who have developed the application itself, what is the protocol being used for communication between client and server.

So, tools which can be used to identify the communication protocol used by an application under test (AUT) are as follows:

1. Protocol Advisor available within LoadRunner Vugen

2. Use network sniffer e.g. Wireshark, Fiddler etc.

3. Record using WinSock protocol and analyse the send and receive buffers to identify the protocol used by an AUT

How does LoadRunner handle cache (Run Time Settings->Browser Emulation)?

The "Simulate browser cache" option tells LoadRunner to pretend that it has a cache and to keep track of the resources it has alread downloaded. If a resource is in the cache and it is requested again, LoadRunner will not ask the server for this resource. This is how a browser with a cache behaves.

The "Simulate a new user each iteration" option tells Loadrunner when to clear the cache. If the option it checked, LoadRunner will pretend that each iteration is a new user, and so a new cache. If the option is not checked, then the cache is kept between iterations.

1. With "Simulate browser cache" and without "Simulate a new user each iteration," LoadRunner will not download the resources on second iteration onwards if it is in the cache.

2. With "Simulate browser cache" and "Simulate a new user each iteration," LoadRunner will reload the resources each iteration, but only load them once per iteration if they are in the cache.

3. With "Simulate browser cache" and without "Simulate a new user each iteration," but with web_cache_cleanup (a LoadRunner function to empty the cache), web_cache_cleanup will override the setting and, as such, it will clear the cache when the function is called, just like if the "Simulate a new user" was checked.

Error: "--27776: Server "[server_name]" shut connection during attempt to negotiate SSL session"

In case you are dealing with HTTPS based/SSL enabled application, you should be reading this post very carefully as it help you to avoid any script replay failure caused due to HTTPs connections.
During replay of a script via an HTTPS connection to the SSL Web server, the vugen script fails with the following error:


 "attempting to reuse saved session.........."


This error is caused due to an SSL session being reused. Information from previous handshakes is incorrectly put into the failing SSL handshake. To resolve this issue, you can reduce the amount of connections simultaneously opened to a Web server by using the following statement at the very beginning of the script:
   web_set_sockets_option("MAX_connectionS_PER_HOST","1");
It has been found that changing the number of open connections does not cause a significant change in performance. Performance issues are more likely to be caused by other factors such as network congestion at a router/switch/hub than by the number of maximum connections allowed.

How to ensure LoadRunner script replay sucessfully when BASIC type of authentication used by an application under test?

When your application under test (AUT) uses BASIC authentication, and you have replayed the default recorded and enhanced script ( e.g. parameterization, correlation etc. ), it may fail as the authentication process sends the first 401 handshake and fails on the second with an error such as 501.


To check if your application uses BASIC authentication or not, you can of course check with your development team or check in the response header in the vugen replay logs. To resolve this issue and achieve successful replay, you can actually add below function at the very beginning of the action section and then replay your script:
   web_set_sockets_option ("INITIAL_BASIC_AUTH", "1");

 

Upper limit on the timeout placed in LoadRunner function web_set_timeout()?

Yes, there is an upper limit to the time which you can define in this timeout function. The limit is set to 1000 seconds. I certainly don't think there is any need to define timeout beyond this limit, as if your application is taking this long already to respond, which means this is something wrong with the application response itself and increasing the timeout further will not help.

And if you will try to place the timeout beyond 1000 seconds in web_set_timeout() function, you will see below error message in the replay logs:

"Error - 27285: setting the timeout value failed"

Difference between LoadRunner HTML or URL/HTTP recording mode

It is always recommended to use HTML mode unless problems arise where URL mode is necessary. There are a few cases in whihc URL mode is necessary. For example, if your application employs certain types of refresh directives (eg. meta refresh tags) to redisplay a correct page, URL mode would be necessary.

HTML mode differs from URL mode in that HTML mode script actively parse through the returned information to obtain resources to download. URL mode does not parse, thus; resources (eg. gif, jpg, etc...) will be directly scripted into the Vuser. This will also means that script length will be increased compare to the script generated in HTML mode. Which in terns increase the memory footprints of the URL script , and may cause issues if its required to run URL mode generated script for more number of vusers on limited number of available injector boxes.

When you set the HTML mode to record resources as separate steps, it may seem identical to the URL mode, but in fact isn't. HTML mode still employs the parsing engine to detect resources. Only resources that LoadRunner can not detect will be scripted in HTML mode, whereas; 'all' resources are scripted in URL mode.

This automatic parsing mechanism will help take care of many correlation issues related to the downloading of resources, thus; I strongly recommend HTML over URL.