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.