Friday, 30 May 2014

Types of Logs in Load runner

Logs in runtime settings in Load runner


While creating and debugging the script which generated in LoadRunner always create various types of 

logs which appear in Virtual user generator screen. These logs are very useful when it’s come to
debugging your script.


There are four types of log available in LoadRunner:

  1. Recording Log
  2. Generation Log
  3. Replay Log
  4. Co-relations Results





1. Recording Log: This log is generated when user records any script. This log mainly contains client
server communication information which is nearly non-readable format. This is not very useful for us
since we cannot map many things of this log with our script. This log contains all protocol communication
information which used by application on which we are recording.

This Log is useful when we re-generate the script using “Regenerate Script” option of Vugen.
Recording log is traces created during the recording Vugen.

User cannot re-generate script if this log is not available.


2. Generation Log: The time user stop recording, recording log traces converts into readable format
and create a log which is known as “Generation Log”. This log is very useful to see request and response
captured by LoadRunner during recording. This log can be refer in script folder by accessing the file
“CodeGenerationLog.txt “


3.Replay Log:
 Now this is the log which helps us a lot while modifying the script. This log generated
when user replay the recorded script. In this log we can see what request has been sent to server and
which kind response we have received during replay. It’s become very handy when we need to find the
problem where script is getting fail during replay. We can increase/decrease the reply log contents by
changing the settings in “Run time setting” by selecting standard log or extended log section.

To view the complete error messages in the Analysis session of load runner

We can see the complete error messages in the analysis session.

 
Add "AdditionalGroupBy=Error Message" to ErrorsPerSecond.def and ErrorSummary.def

To display the complete error messages in the Analysis tool,follow the below steps:
1. Close Analysis
2. Go to "LoadRunner Install Dir"\bin\dat.
3. Open ErrorsPerSecond.def using a word editor (notepad/wordpad).
4. Edit the section for "Graph Definitions."
5. Add an "Error Message" value to the AdditionalGroupBy key.

Example:
               [Graph Definitions]
                 AdditionalGroupBy=Error Message

6. Repeat Steps 5 and 6 for ErrorSummary.def.
7. Reload the raw analysis session and Add Error Statistics graph.
8. After the 'Error Statistics' graph is added, right click on the graph and select ' Set Filter/Group By'
     option.
9.On the Lower pane where it says, 'Group By' select 'Error Message' and it should be available in the
    'Available Group'
10.On the upper pane where it says 'Filter Condition', under 'Error Message' or 'Error Type' select all
      or any of the error codes or message to be shown on the graph.
      This will show the error messages along with the code on the lower half pane where the graph is
      displayed and it will exported in any reports that are created.

To display the Number of Vusers in Scenario

Steps to display the total number of Vusers in the scenario instead of just the running Vusers

If you want to display the total number of Vusers in the scenario instead of just the running Vusers

There are two files that need modifications.

1. Open VuserStateGraph.def located under \bin\dat.
  •      Search for the [AdditionalFilter0] section.
  •      Change Values=Run to Values=Quit.
  •      Save the file.
2. Open AnalysisSummary.asc located under \bin\dat.

a. Change FieldName=Maximum Running Vusers: toFieldName=Total Running Vusers:.
     Save the file.

3. Open up the results file (.lrr) again, it will now display the Total Running Vusers as opposed to        
     Maximum Running Vusers.

Issue in replay due to Redirection

This summary is not available. Please click here to view the post.

Process to run Vuser scripts in Stand-Alone Mode in LR

Running Vuser Scripts in Stand-Alone Mode:


In order to perform load testing with a Vuser script, you need to incorporate the script into a LoadRunner
scenario. Before integrating the script into a scenario, you should check its functionality by running the
script in stand-alone mode.

Stand-alone mode:
Running a script in stand-alone mode means running the script without using a LoadRunner Controller.
This is done to establish how the script will execute when run from the Controller. If the script is
Windows-based, you use VuGen to run it in stand-alone mode. If the script is UNIX-based, you must
run it from a UNIX command line.

If the stand-alone execution is successful, then incorporate the script into a scenario.

JVM garbage collection in young generation


    Allocating new objects using new operator (almost) always happens in Eden space. But Eden is actually
a stack. When you create new object needing N bytes, single pointer advances by N bytes on that stack and
that's it. Allocating is that fast, no searching for free spot, compacting, whatever.

  Offcourse this stack is not infinite, at some point we'll reach its end, triggering minor GC. Also most likely
multiple objects are already garbage. So what JVM does in minor GC is the following:



  • Traverse graph of objects starting from GC roots.
  • Copy all objects reachable from GC roots to one of survivor spaces (no gaps, we know all of them
    and this 
    is a single process)

  •  Wipe out eden space (basically just moving this stack pointer back to 0)

In subsequent minor collections there are additional steps:

one of survivor spaces is examined as well. Live objects from both eden and one of survivor spaces are
copied to second survivor space. This means there is always exactly one free survivor space.

So how are objects ending in tenured generation?

  1. First young objects are copied to one of survivor spaces. 
  2. Then they are copied to the other and again and again. Once given object jumps back and forth
    too many 
    times (configurable, 8 by default), it is promoted to tenured space.
  3. Major GC runs when tenured space is full.

Error: Extension lrcVba was not loaded.

 You are running under secure mode and this extension is not allowed-Error in loading Extension or DLLs while running LG over firewall

When running COM/DCOM scripts either from standalone Controller or from Performance
Center, they fail with 

"Error: Extenstion lrcVba was not loaded. You are running under secure mode and this
extension is not allowed"
The same issue can happen for VB and JAVA user scripts.

To solve this follow these steps:

To be able to run the COM/DCOM scripts on an InjectorOverFireWall machine, or any other
protocol type which is not allowed to run over the firewall by default, do the following:
1. Open the *.usr file, located in the script directory, using notepad and find the value for
    Type=.
2. On the LG machine, go to (pc install dir)\dat\mdrv\lrc_mdrv.dat file and open it in
    notepad.
3. Add the flag "SecurityMode=on" under the relevant section like [lrc], [lrcVba],
    [lrcCreplay], [lrcVbareplay] etc..,
4. Save the changes and restart the agent process or service on the LG machine.
5. Run the test again.It work will fine.