1. Q: What versions of LoadRunner did you work in?

A: 7.5, 7.8, 8.0, 8.1, and 9.0

2. Q: What is a performance test plan

A: A performance test plan contains the scope, objective, focus and approach of the testing effort. It includes the items in scope / items not in scope, goals, load critical transactions, load rates, types of tests, timelines, key stakeholder information who need to approve the plan, risks/assumptions, and environment information(both test and production). A good plan is a foundation of all testing that follows, so it is a very part of performance testing.

3. Q: What is Correlation and how do you do it?

A: A lot of scripts that are generated by LR protocols are based on the communication between the client and server. They are values that are dynamic that are sent from the server that need to be captured as a variable. In the case of a web application, the values are captured using web_reg_save_param. The key to correlation is to identify what value is dynamic, and in which server request was it first seen. To identify that I enable all extended logging including data returned from the server and identify the value that is dynamic. There is another to correlate that is called automatic correlation. I am not a big fan of auto correlation as it is unreliable. Some examples of dynamic values are session id, message id, and date/time stamp.

4. Q: Is there a situation you would want to use automatic correlation and why?

A: In some cases especially in .net applications, you see large dynamic values like the viewstates that need to be correlated in almost every request. I would create a custom rule as these values have the same left and right boundaries in the recording options.

Q: If you have to correlate a very large dynamic value in a web application, want needs to be done?

A: By default web_reg_save_param allows the parameter size to be 256 characters only. If the parameter is larger the function web_set_max_param_lenght needs to define the size of the parameter.

Q: What is parametrization?

A: Parametrization is adding a variable to a value. Since we create a script as a single user in VUGEN and replay it in multi user mode in the controller, values like username, password, accounts etc need to be parametrized to represent accurate usage. Also it is a common practice to develop scripts in one environment and test in the other. The environment information in the URL also needs to be parameterized. There are different types of parameters:

1. File has 3 types(unique, random, sequential)2. Random number

3. Unique Number

4. Date / Time

5. Load Generater

6. Etc

7. Q: What is the difference between parametrization and correlation?

A: Correlation deals with capturing dynamic values returned from the server as variables. Parametrization is user defined variables.

8. Q: How do you identify a bottleneck?

A: I set up monitors to identify bottlenecks. I look at both client side monitors and server side monitors.

I look at client side monitors like response times, throughput (data returned from the server in bytes), hits/sec( http requests from the client to the server) and running Vusers. I look at:

1. Is response time acceptable2. As running Vusers are increasing with hits/sec also increasing is throughput increasing or

decreasing.

If I see a problem I look at each tier of servers and also networking to identify the root cause of the issue:

1. web servers: I basically look at all the counters that would tell me if the server is available(System\System Up Time counter), is the server busy(Processor(_Total)\% Processor Time which is nothing but CPU usage), is hardware functioning properly (System\Context Switches/sec and Processor(_Total)\Interrupts/sec counter), is there enough RAM or memory(Memory\Available Bytes and Memory\Used bytes counters), and is disk fast enough( I/O counters)

2. application servers: Look at all the above counters like in the web server and also look at JVM(Java Virtual Machine) counters like heap usage, and garbage collection. In addition we need to look at threads, queuing, pooling, and database connection. In case there is an issue additional diagnostics might be needed to help identify the issue in the code. I have also used J2EE diagnostics in the past to help identify:

a) Code problems( slow methods, memory problems, bad coding practices, and synchronization problems for threads)

b) Configuration problems for JVM heap size, number of threads, and database connection pool.

c) Architectural problems.

3. database servers: Look at all the above counters like in the web server and also look at the some of these other counters:

a) SQL round trip time

b) Queries executed, and if any full table scans are occurring.

c) Buffer to cache ratio

I have worked with Oracle statspack reports which I get from the DBA’s and also used SQl navigator for SQL servers.

From my experience most performance issues happen at the application or database server level

Q: What are some of the ways you monitor servers?

I have used 3 ways based on what was available to me at the client:

1. I have set up loadrunner monitors through the LR controller. This requires some setup on the server side. For UNIX based servers rstatd needs to be enabled and running on the server

2. By getting stats directly from the servers. For windows based servers I have used the perfmon program. For UNIX based servers I have used commands like top, vmstat, and svmon. I have also written shell scripts to capture the performance data.

3. By using tools like SiteScope, Wily Introscope, Tivoli Performance Viewer, and TeamQuest.