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.

What is "wasted time" and does it get included in the response time metrics calcualted by LoadRunner Controller\Analysis?

The concept of "wasted time" was introduced to distinguish between actual time spent on processing and displaying information, from Human/idle-waiting overhead. Wasted time is calculated as a factor of unnecessary waiting. In Vugen, the transaction time includes the "wasted time" but it is subtracted from transaction time when displayed in Controller and Analysis.

Below types of activities are considered as wasted time by LoadRunner:
1. Rendezvous is considered as wasted time, since the client Vuser could theoretically continue executing, but has opted to wait for other Vusers to meet at certain points of execution.
2. Any silent waits (i.e., via TE_wait_silent), where the context or text has already been displayed, but the Vuser still waits to ascertain that it is stable. (Functions such as TE_wait_text() have lr_wait_silent embedded in it.) This is to ensure that the text is actually stable before continuing. It is considered wasted time, since the Vuser really did not have to wait, but did just to make sure the text appeared and stabilized.
3. Any User Input time (think time) is considered wasted time, since the application is not engaged in processing or displaying information. Even if the typing style is modified (i.e., via TE_typing_style), the total duration of the typing is considered "wasted time."
4. Explicit sleep statements are not considered "wasted time" since it may be argued either way. If you want idle waits to be included in "wasted time," use TE_wait_silent().
5. For Winsock script, time to compare the difference between the receiving buffer and data in the data.ws is counted as wasted time.
6. For Web script, the time taken for web_reg_find or web_reg_save_param functions to look for a particular string in the response buffers, is counted as wasted time.

Though wasted time does not impact the response time metrics calculated by Controller and Analysis, however, it does impact the OS resources on the load generator box as it makes the session for a particular vusers to be held active for longer time than usual.

Number of vusers that can be run on a typical Load Generator

There are several factors that can affect the scalability of a script, and so the number of Vusers that can be run, it is not always possible to determine the hardware requirements to run a given number of vusers. The best approach is to run some tests to verify empirically the resource requirements of the specific scripts being used during a test.
Factors that can impact the number of vusers which can run on a load generator are:

1. Length of the business process or in other words script length
2. Complexity of the script e.g. custom code, correlation etc
3. Number of scripts needs to be executed in the test scenario
4. Protocol used to script the business flow in Vugen
5. Run time setting used “Run vuser as process” or “Run vusers as thread”. It’s recommended to use Run vuser as a thread option (default one) unless your application under test (AUT) is not thread safe
6. Level of the logs selected under Run time settings during test execution
7. Load generator machine is physical or virtual
8. Hardware configurations of the load generator machine. The primary factors affecting the script execution are Memory and CPU Utilization. Other factors such as Network Bandwidth and Hard Disk speed can become factors but in virtually all cases the core issue will be Memory and CPU related.

In order to determine the number of users that will run on a given Load Generator machine it is best to run some tests from the LoadRunner Controller. Create a scenario using the scripts in question where they are run on a remote Load Generator using a slow ramp up of vusers. During this process monitor that Load Generator to see what Memory and CPU resources are used as the load is increased. Note that in this case the "load" that we are talking about is the client side processing load on the Load Generator machine itself and not the load on the Server (which is what is normally measured during an actual load test.)

Using this method an accurate estimation may be made about how many vusers can be run on that machine. Also some extrapolation may be done to determine additional hardware requirements for additional vusers. It is also wise to monitor the Load Generator machines during the actual test to ensure they are not a bottleneck in the test (as that would invalidate the test results anyway.)

Some rules of thumb for monitoring load would be:
- CPU usage should stay below ~80-90% continuous usage.

- Memory usage should stay within the physical limits of the machines memory. This means that the "Commit Charge Total" should be less than the "Physical Memory Total" which will ensures that minimal paging is done to simulate physical memory.

Process Explorer - Powerful tool to assist in identifying LoadRunner Vugen recording Issues

Microsoft Process Explorer is a very powerful tool to help you to identify certain types of recording issues e.g vugen is unable to record script as few of the application running on your machines are interfering in LoadRunner mechanism to place a hook on the communication flows between client and server or antivirus is causing issues etc.
Process explorer displays processes running on your machine, and associated dlls/exe invoked.The unique capabilities of Process Explorer make it useful for tracking down DLL-version problems or handle leaks, and provide insight into the way Windows and applications work.


Below steps explains how to use while trying to identify/troubleshoot recording related issues:

a. Having installed this program, run 'procexp.exe'. This launches the application.

b. The top half of the screen list all the processes running on the machine. Click on menu 'View | LowerPane View -> Dlls' and then the second half of the screen displays the list of DLLs used by the process which is highlighted in the top half of the screen.

c. Click on menu 'View | Select Columns' and under the Process Image tab check 'Image path'. Now under the DLL tab, make sure you have Path selected as well.

d. Now bring up VuGen and start your recording. After you have done so, come back to process explorer and select 'Vugen.exe' as the process and then have a look at the Dlls listed below. Now click on File | Save in a notepad file.

You can get detailed information and download it from below link:
http://technet.microsoft.com/en-gb/sysinternals/bb896653

Co-existence of LoadRunner and Quick Test Professional\Unified Functional Testing on same Machine

As LR and QTP\UFT binaries/installer has some of the files in common, this can cause issues for both the product to co-exist on the same machine, and eventually may cause crash any of these products while carrying out various testing activities.


Though I would strongly recommend not to install LR and QTP/UFT products on the same machine, however, if this has to done, you must ensure below sequence of installation is followed:


> LoadRunner should be installed first.
> Upon successful installation of LR, only then QTP/UFT should be installed

What version of Microsoft Data Access Components (MDAC) supported by LoadRunner (LR) 12.01 supported?

MDAC is one of the pre-requisite which needs to be installed on the boxes before LR installation. As you might be aware that LR install the pre-requisites on its own in case these are not installed before kick starting LR installation. HP LoadRunner 12.01 supports MDAC v2.8 SP1 (or later).

Basic Metrics to measure the performance and identify performance bottlenecks of Web Server

To characterize your web server's performance, you need to measure both throughput and response time.

Throughput (say, HTTP operations per second) is a capacity metric, while response time (usually measured in milliseconds) gives you an idea of responsiveness for individual users.

Graphing your throughput vs. response time frequently highlights some interesting trends. Up to the capacity limit of your server, throughput tends to increase along a flat response time curve. When your server reaches its maximum thoughput, response time increases exponentially.

Poorly tuned servers display one of two phenomena (sometimes both): the response time increases proportionally with the throughput, or the response time remains constant while the throughput actually degrades. These curves generally indicate a poorly-designed algorithm at the heart of the server.

Before you begin your performance measurements, take some time to set your goals. Should your average response time come in under 50 ms? 500 ms? Should you measure the 90th or 95th percentile, rather than the average? How many users do you need to support? The answers to these questions need to come from your own (Business Analyst and Product team) intimate understanding of your application, user population, and workload.

LoadRunner - Counters useful for monitoring Web & SQL server performance

While carrying out performance test execution, it's very important to monitor the underlying infrastructure to identify performance bottlenecks.

The following is a list of counters that are useful for monitoring Web server performance:  

Object	Counter
Web Service	Maximum Connections
Web Service	Bytes Total/sec
Web Service	Current NonAnonymous Users
Web Service	Current Connections
Web Service	Not Found Errors
Active Server Pages	Requests/sec
Active Server Pages	Errors/sec
Active Server Pages	Requests Rejected
Active Server Pages	Request Not Found
Active Server Pages	Memory Allocated
Active Server Pages	Requests Queued
Active Server Pages	Errors During Script Run Time
Memory	Page Faults/sec
Server	Total Bytes/sec
Process	Private Bytes/Inetinfo

The following is a list of counters that are useful for monitoring SQL Server performance:

Object	Counter
SQLServer	User Connections
SQLServer	Cache Hit Ratio
SQLServer	Net-Network Reads/sec
SQLServer	I/O-Lazy Writes/sec
SQLServer-Locks	Total Blocking Locks
PhysicalDisk	Disk Queue Length

The following is a list of counters that are useful for monitoring both Web and SQL server performance:

Object	Counter
Processor	% Total Processor Time
PhysicalDisk	% Disk Time
Memory	Available Bytes
Memory	Pool Nonpaged Bytes
Memory	Pages/sec
Memory	Committed Bytes
System	Total Interrupts/sec
Object	Threads
Process	Private Bytes:Total

Minimum OS Level Permissions Required to Install LoadRunner

Though it's recommended to be either a local admin or member of the power user group to carry out LR installation, however, there are few occasions where due to security reasons it's not possible for your organization to give you those rights, in that case, there is still a possibility for you to carry out installation with minimum possible rights which are mentioned below in detail:

a.Full access (read/write permissions) to registry keys under:

HKEY_CURRENT_USER\Software\Mercury Interactive 
HKEY_LOCAL_MACHINE\Software\Mercury Interactive

b.Full access (read/write permissions) to the file system to be able to copy files.

If there is any problem either with agent startup or connection from Controller to the agent on a Windows 2000 machine with a power user, try the following: 
1. Open the Local Security Settings window through Start -> Programs ->Administrative Tools -> Local Security Policy. 
2. Select Security Settings -> Local Policies -> User Rights Assignments. 
3. Add the user to the "Create global objects" policy

Advantages and Disadvantages of Using Loadrunner Vugen’s Run Time Viewer

By reading the title of this post, you might be wondering that I can only see advantages of using Run Time Viewer during script development and what could be its disadvantages?

Though, run time viewer provides visual verification checkpoint to determine weather your script is able to navigate through the recorded actions successfully or not. However, this should NOT be used as a final verification point due to below reason:

Run time viewer is not an Internet Explorer (IE). This is a utility embedded within HP LoadRunner which has very limited functionality compare to IE in displaying advanced technologies elements e.g. ajax, applets etc. So, in case if any of the pages will not be displayed by Run Time Viewer, this does not mean that your script has anything wrong or not working. To verify that, you should be replaying your script with full extended logs enabled and review replay logs to check for any error or warning messages.

Another issue I have seen by keeping the run time viewer enabled during replay in my past experience (especially with Oracle NCA protocol script ) is that, the  vugen crashes during script replay. To get rid of this issue, HP recommended to turn it off during replay.

Important point to be considered:

It's good to use Run Time Viewer during script replay, however, do not use it as final verification to determine the script successful replay. Do check replay logs and application under test logs (if accessible) to decide that. Also, in case vugen crashes during script replay with run time viewer enabled, try to disable it to get rid of this issue.

LoadRunner Vugen's Run-time Settings > Preferences > Advanced option WinInet replay instead of Sockets (Windows only)

LoadRunner's (LR) default engine is Socket based, which is of course more lighter and scalable than the WinInet engine. However, based on my experience, I have seen few situations where script replay fine only with WinInet engine. This may solve the problem in shorter term, however, may introduce scalability issues in case huge number of virtual users needs to be executed on the involved injectors. Socket mode replay uses an HP proprietary interface to the network card providing a lighter engine that is  scalable for load testing and compatible with both Windows and non-Windows Load Generator machines.


WinInet replay uses the Microsoft WinInet DLL to talk to the network card. The limitations of the WinInet replay engine is that it is not scalable, nor does it support UNIX. In addition, when working with threads, the WinInet engine does not accurately emulate the modem speed and number of connections. However, the WinInet interface is used by Internet Explorer and is optimized to work with this browser. It supports all of the features incorporated into the Internet Explorer, and thus, WinInet replay can resolve some replay errors and may produce faster replay transaction times than using the Sockets mode replay.


Important point to be considered:
Only use the WinInet replay if the load test will run in a completely Windows environment with a relatively low number of Vusers are required to run on each Load Generator.

LoadRunner’s Vugen Run Time Setting Miscellaneous->Multithreading-> Run Vusers as Thread or Process

Though by default Vugen Run Time setting (RTS) is set to run vuser as thread, however, I have seen sometimes testers are struggling to understand why they should use the default setting and why not go for run vuser as process? To sort this confusion out, I thought of writing this article with detailed reasoning behind it.

It’s strongly recommended to set this RTS as 'run vuser as thread'. Reason behind this is explained below in the table which demonstrate the difference between these two settings:

RUN VUSER AS THREAD	RUN VUSER AS PROCESS
When you run Vuser as a thread, LoadRunner (LR) will launch 1 thread per vuser.  e.g. if you will run 50 vusers, LR will launch only 1 process (mdrv.exe) with 50 threads running within that single process (if the limits is set to 50, it can be less or more based on what you customize it from the default value which is 50).	When you run Vuser as process, LR will launch 1 process (mdrv.exe) per vuser. e.g. if you will run 50 vusers, LR will launch 50 mdrv.exe processes.
Running vuser as thread will be more effective on keeping the OS resources consumption on the injector’s boxes to considerably low as this setting does not have very heavy footprints.	Running vuser as process will be very heavy on OS resources consumption on the injector boxes
As multiple threads running within a single process share the available resources among themselves , it’s recommended to use this setting when huge number of vusers are required to run on the injector boxes	As each vuser has its own process and privately allocated resources, it’s not recommended to use this setting when huge number of vusers are required to run on the injector boxes

 

Important points to be considered:

• You will need to check with your development team if application is thread safe or not. If it’s not thread safe, then you may have to choose run vuser as process because running vuser as thread will not work with your application.
• By default, LoadRunner configurations have 50 as the max limit on the number of threads which can run within single process. Though you can increase this number, however, it’s good to keep in mind that by increasing this limit to some unreasonable number will make system/injectors unstable. So, it’s strongly recommended to keep it as default unless HP recommends you to do so.