Why LoadRunner is Just Not Enough


There’s a question I’ve been mulling over for a while now:

“Is LoadRunner able to give you the actual picture on its own?”

After a lot of research, I’ve come up with an answer: “Sure, If you’re a guru. But most of the time, No.”

But… But… Why Not?

Allow me to explain.

LoadRunner is a tool for performance monitoring. It can tell you that under how much load, and after how much time, what an application’s behavior is. What it cannot tell you is what was the origin of the problem, or that was this problem even a software problem, or a mere hardware configuration issue. (To be fair, HP itself says that LoadRunner is able to provide only 10% of the actual diagnostics information.)

To let you in on a secret, my confidence in the tool was shaken in a couple of LoadRunner projects, which made me sit up and take notice.

According to HP, LoadRunner can only provide about 10% of the actual diagnostics information.

After exploring more, and doing some experiments, I came to know LoadRunner is not been able to tell me:

  • What was the condition of hardware before and after load test
  • What was the area causing the problem
  • What other application area are suffering due to this load
  • Is there a way to improve?

What Now?

Staying true to Tester’s Oath, we’ve identified the problems with LoadRunner. Now, on to finding the solutions!

My research led me to a rather obvious solution. HP Diagnostics and HP Site Scope.

Site Scope is a tool that basically monitors all the aspects of IT infrastructure (in words of HP, “Remote monitoring of IT infrastructure and applications without installing any software on target systems”). Meanwhile HP Diagnostics, well the name clearly indicates its function: It identifies & highlights actual problem at any given point of time, and helps you targeting them.

To better explain the situation, an ideal performance testing combination looks like this:


  • Site scope will give you information of hardware and software whenever script is being executed, before it and after it.
  • Diagnostics will tell you what is the current state of application, which function is using how much resources, and which one has left stones unturned
  • LoadRunner will execute the scenario, and tell you what the situation from user experience standpoint is.

So by combining the results from all three, you will be able to assess the situation much more clearly. Where the issue occurred, what caused that issue, and where to begin in order to resolve it.

Use HP Diagnostics, HP SiteScope and HP LoadRunner, together for best performance assessment.

In my next blogs, I will try to help you set up performance testing environment, as I believe is the correct way.

Topics are:

  1. HP Diagnostics introduction
  2. Setting up Diagnostics Commander Server
  3. Setting up Diagnostics Mediator Server
  4. Setting up Diagnostics Java Probe with Tomcat
  5. Setting up Diagnostics Java Probe with JBOSS
  6. Setting up Diagnostics .NET Probe
  7. HP Sitescope Introduction
  8. Setting up Sitescope monitors
  9. Configuration of HP Diagnostics and HP Site Scope with HP LoadRunner


If you are facing any issue regarding HP Quality Center/ HP Application Lifecycle Management, please feel free to give us a holler on Facebook, Twitter, or Email, and we will try our best to help you out.