Error: “Cannot install license information, probably access to system resource was denied”

Solution:

This error indicates that you need to log in with local administrator permission, since you installed the product with administrator permission. If you still get the error after login as local administrator, run setlicensepermissions.exe from the \bin directory to change the registry permissions

Error “License key was generated with a version superior to your license manager. Upgrade your license manager”

Solution:

Make sure the HostID that was sent to HP Customer Support was generated from the correct LoadRunner version. If you sent the HostID of LoadRunner 7.6, but apply the license key on LoadRunner7.0 install, you will get this problem.

Error: "License cannot be save in your installation directory. (Error code = -4) It will be used only for this session.

Solution:

Make sure that you have administrator privilege to the Controller. If you are accessing the Controller via the network, make sure that you have write access to the network.

Client Interview Question in Load runner

1) How you will get the requirements?

2) What is the differences between running vuser as a process and thread ?

3) Which functions are used in scripting ?

4) Work flow process of the perormance testing?

5) Have you used in controller ?

6) How you design a scenario in controller ?

7) Have written any functions in scripting ?

8) What are the bottlenecks you found?

9) Have you using goal oriented scenario ?

10) Tell me your project end to end process?

11) Tell me about your experience project profile

12) Your LR rating in 1 to 10 scale

14) What is protocol?

15) What is a memory leak?

16) Define Heap Usage?

17) Your past experience how many users you have run the test?

18) What are the bottlenecks you have find the current project? Tell me two critical bottlenecks

19) What type recommendations given to the client or stakeholder?

20) What protocol you worked in fast experience? How to work with that web service protocol in your project.

21) You have any use the heart beat settings did you used in current project?

22) How work is handled in the team?

24) You have 10 URLs? How to test the URLs in in at a time LR (i am not understand the Question)

26) You have any used the custom functions in your project?

28) When memory reach 100%, then ideally what you will think?

30) What type of reports and documents you have prepared? Explain the summary report.

32) Tell me the LR server requirements?

34) What type of analysis did you used in your projects? Tell me few observations and what parameter u have captured?

36) What you have done the Pervious projects? Explain the last project

38) What are other options in correlation function and did u used in your project?

Copying files larger than 2 GB over a Remote Desktop Services

When you try to copy a file that is larger than 2 GB over a Remote Desktop Services or a Terminal Services session through Clipboard Redirection (copy and paste) by using the RDP client 6.0 or a later version, the file is not copied. And, you do not receive an error message.


There are two methods for this

Method 1:Use Drive Redirection through Remote Desktop Services or a Terminal Services session if you want to transfer files larger than 2 GB.

Method 2:
Use command-line alternatives such as XCopy to copy files larger than 2 GB over a Remote Desktop Services or Terminal Services session. For example, you can use the following command:

xcopy \\tsclient\c\myfiles\LargeFile d:\temp
Copy and paste files:
You can copy and paste the files between the remote session and the local computer or between the local computer and the remote session by using the Copy and Paste feature. However, this is limited to files that are smaller than 2 GB.

Transfer of files by using Drive Redirection:
The drives on the local computer can be redirected in the session so that files can easily be transferred between the local host and the remote computer. The drives that you can use in this manner include the following:

1. local hard disks
2. floppy disk drives
3. mapped network drives

On the Local Resources tab of Remote Desktop Connection, users can specify which kinds of devices and resources that they want to redirect to the remote computer.

Do You Know If Your Database Is Slow?

The time to respond:

There was a question at Pythian a while ago on how to monitor Oracle database instance performanceand alert if there is significant degradation. That got me thinking, while there are different approaches that different DBAs would take to interactively measure current instance performance, here we would need something simple. It would need to give a decisive answer and be able to say that “current performance is not acceptable” or “current performance is within normal (expected) limits”.

Going to the basics of how database performance can be described, we can simply say that database performance is either the response time of the operations the end-user do and/or the amount of work the database instance does in a certain time period – throughput.

We can easily find these metrics in from the v$sysmetric dynamic view:

SQL> select to_char(begin_time,'hh24:mi') time, round( value * 10, 2) "Response Time (ms)"
from v$sysmetric
where metric_name='SQL Service Response Time'

TIME Response Time (ms)
--------------- ------------------
07:20 .32


So this is the last-minute response time for user calls (here in ms). We can check the throughput by checking the amount of logical blocks (it includes the physical blocks) being read, plus we can add direct reads (last minute and last several seconds output here for a database with 8 KB block):

SQL> select a.begin_time, a.end_time, round(((a.value + b.value)/131072),2) "GB per sec"

from v$sysmetric a, v$sysmetric b

where a.metric_name = 'Logical Reads Per Sec'

and b.metric_name = 'Physical Reads Direct Per Sec'

and a.begin_time = b.begin_time

BEGIN_TIME END_TIME GB per sec

-------------------- -------------------- ----------

16-jun-2013 08:51:36 16-jun-2013 08:52:37 .01

16-jun-2013 08:52:22 16-jun-2013 08:52:37 .01

We can check more historical values through v$sysmetric_summary, v$sysmetric_history and dba_hist_ssysmetric_summary.

So did these queries answer the basic question “Do we have bad performance?”? 100 MB/sec throughput and 0.32 ms for a user call? We have seen better performance, but is it bad enough that we should alert the on-call DBA to investigate in more detail and look for the reason why we are seeing this kind of values? We cannot say. We need something to compare these values to so that we can determine if they are too low or too high. It is somewhat like being in a train that passes next to another moving train, going in same direction but at a different speed. We don’t know the speed of our train, and we don’t know the speed of the other train, so we cannot answer the question “Are we going very fast?”. If we turn to the other side and see a tree passing on the other side of the train, we will be able to estimate the speed of the train (also taking into account our experience of what is very fast for a train…). So we need something that has an absolute value. In the case of the tree, we know that the tree has speed of 0

How to Improve Database Performance by Measuring User Experience?

What is Response Time Analysis?

Response time analysis is a new approach to application and database performance improvement that allows DBAs and developers to manage their databases guided by the most important criteria - what causes application end-users to wait. Also referred to as wait time analysis, it allows IT teams to align their efforts with service level delivery for IT customers.

The picture represents the Response Time monitoring process. Each SQL query request passes through the database instance. By measuring the time at each step, the total Response Time can be analyzed.



Rather than watching server health statistics and making guesses about their performance impact, wait and response time methods measure the time taken to complete a desired operation. The best implementations break down the time into discrete and individually measurable steps, and identify exactly which steps in which operations cause application delays. Since the database primary mission is to respond with a result, response time is the most important criteria in making database performance decisions.

Response Time = Processing Time + Waiting Time

Response time is defined as the sum of actual processing time and the time as session spends waiting on availability of resources such as a lock, log file or hundreds of other Wait Events or Wait Types. Even when the session has access to the CPU (a CPU Wait Type for example), it is not necessarily being actively processed, since often the CPU is waiting for an I/O or other operation to complete before processing can continue. When multiple sessions compete for the same processing resources, the wait time becomes the most significant component of the actual Response Time.

Wait Events and Wait Types
To accurately measure the Response Time for a database, it is necessary to discretely identify the steps accumulating time. The steps corresponding to physical I/O operations, manipulating buffers, waiting on locks, and all other minute database processes are instrumented by the database vendors. In SQL Server, these steps are called Wait Types. In Oracle, Sybase and DB2, they are referred to as Wait Events. While the specifics are unique for each vendor, the general idea is the same. These Wait Types/Events indicate the amount of time spent while sessions wait for each database resource. If the Wait Types/Events can be accurately monitored and analyzed, the exact bottlenecks and queries causing the delays can be determined.

Differences vs. Conventional Statistics
Typical database performance monitoring tools focus on server health measures and execution ratios. Even with a sophisticated presentation these statistics do not reflect the end-user experience or reveal where the problem originated. Knowing an operation took place millions of times does not inform whether it was actually the cause of an application delay.

Key criteria to distinguish Response Time vs. Conventional analysis methods:

Measure response time for an action to take place, from receipt of request to beginning of response.
Measure each SQL query separately, so the response time effects of a specific SQL can be isolated and evaluated. Measuring total response time across the instance does not give useful information.
Identify the discrete internal steps (Wait Types/Events) that a SQL query takes as it is processed. Treating the instance as a black-box without seeing where the time is consumed internally does not help problem solving.

Practical Considerations for Response Time Analysis
The Response Time approach to performance monitoring is only practical if it can be implemented efficiently in a performance sensitive production environment. Confio uses low-impact agentless technology to meet this requirement. Here are some practical considerations:

• Low Impact Data CaptureData capturing should not place a burden on your production systems. 
• Agentless architectures offload processing to a separate system that reduces production database impact to less than 1%.Agentless Database OperationEliminate need to test, install and maintain software on production servers.
• Passive Monitoring of Production DataMonitor real production sessions, not simulated test transactions.
• Continuous 7/24 MonitoringInsist on continuous monitoring across all sessions on all servers to ensure any operation can be deeply examined at any time. Occasional trace files will not provide continuous coverage.

How does collating the test results work in loadrunner controller?

At the end of a test the results are collated by the LoadRunner controller. Each of the generators results are collected in a .eve (Event) file and the output messages for the controller are collected in a .mdb (Microsot Access) database. This happens in the directory specified for the results on the controller. A .lrr (loadrunner
results) file is created. The .lrr file is text. The .eve file was text prior to around LoadRunner 7.5, but since then it has been an unpublished compressed format. 

When you start the analysis utility it take the information in the .lrr file and the .eve file and creates a .mdb (microsoft access database) or SQL Server database entries which contain each timing record and data
point entries. If collation fails at the end of the test you will have only partial results for analysis

How we will do Spike Testing and Explain it with example?

Spike Testing is a form of testing process in which an application is tested with unusual increment and decrements in the load. The system is unexpectedly loaded and unloaded. It is done to notice how actually the system reacts with unexpected rise and decline of users.

Example:

when you are always checking the result of your exam on JNTU site means site is suddenly loaded and unloaded and then the IT squad of JNTU check how the site reacts with unexpected increase and decrease of users than it is Spike testing.

Spike testing is mechanism of testing which means when in a web page frequent number of visitor access the page unexpectedly increases to maximum then obviously performance of the page breaks down. So the mechanism of testing a performance about web page due to unexpected sort of traffic on the page is always called as Spike testing.

Spike testing is usually done by unexpectedly increasing the number of loads generated by users by a very enormous amount and observing the dramatic behavior of the system.

The goal of spike testing is to regulate whether performance will deteriorate, the system will always fail, or it will be able to hold dramatic changes in load.

A spike is a keen rise in the density for a given variable, generally immediately followed by a decrease. This category of transient variation is often notice in the measurement of voltage or you can say current in circuits.

Spike testing is always used in load and performance testing. These tests are commonly based on real universe or projected workloads with focus on huge load/performance conditions.Spike testing is handling to check whether a system can handle dramatic changes in load. It is accomplish by spiking the no of users of an application and always produces an excellent way of verifying existing limitations in the current operational environment. spike testing is a type of performance testing

Issues when creating Loadrunner scripts with the Java protocol

When writing a Loadrunner script that interacts with MQ, Websphere or Weblogic, as a scripter, you need to use the Java protocol.

This is a bit of a nuisance for those of us who have become familiar with C programming language and can use it with our eyes shut. The question is often asked, why do I need to use Java? I want to use C. Java can take a long time to use and logically seems to work quite differently to C.

Well, the answer is a little obvious (but only when you know the answer!) In order to develop Automation for MQ, Weblogic or Websphere, you often need to use the same libraries that the developers have used. The developers have often written the application in Java, and the supporting object libraries are the Java versions for the middleware products MQ, Weblogic and Websphere.

In many cases, the Loadrunner automation is simulating a device which runs the Java application. This could be a desktop, laptop or a handheld terminal (HHT). The device contains a compiled version of the code. This code is executed on one of three circumstances:

• The device is switched on and the operating system is configured to execute at start up
• An input is received from the device such as barcode being scanned
• A message is received from a middleware application such as MQ, Websphere or Weblogic

When executing an automated test script with Vugen, Loadrunner always compiles the script first. With a Java script, this will create a compiled version of the application similar to that which in the real world is located on the desktop, laptop or a handheld terminal. The main difference between the Loadrunner script and the real application is that the Loadrunner script would normally be written to process a distinct business function, i.e. it would contain only a subset of the functionality of the real application.

In order to compile the application, the Loadrunner scripter needs to have access to the same common java files as the developer, the so called JAR files. The JAR files need to be accessible to Loadrunner when it compiles. This is done by entering the information into the runtime settings. By specifying the location of the classpath files in the runtime settings, you are telling Loadrunner where to find the Classpath files so that compilation will work.

While this seems straightforward, the way Loadrunner works with the compiler means that it detects the names of the Classpath files, but does not necessarily determine where they are.

To get around this we can change the path statement on the environment variables for the machine running Vugen. This also does not always work. What should work is to physically place the JAR files in the Loadrunner directory of program files and set the Classpath statements accordingly.

At this point your script will compile and any other errors after this are down to real coding issues