LR Script running very slowly

342 views
Skip to first unread message

Priyanka Tiwari

unread,
Aug 13, 2012, 8:44:04 AM8/13/12
to LoadRunner
Hi All,

I have prepared a script which is running very slow in LR Vugen
machine but manually application is not that slow.
Script contains multiple actions which are called in accordance to a
particular parameter.and a large amount of C programming is added in
the script for handling the data present in the server response.

Could you please suggest what can be prabable reason of this issue?

laxmi narayana

unread,
Aug 13, 2012, 9:50:09 AM8/13/12
to lr-loa...@googlegroups.com
May be problem with proxy.. chk with both options enable/disable


--
You received this message because you are subscribed to the Google "LoadRunner" group.
To post to this group, send email to LR-Loa...@googlegroups.com
To unsubscribe from this group, send email to
LR-LoadRunne...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/LR-LoadRunner?hl=en

James Pulley

unread,
Aug 13, 2012, 10:10:48 AM8/13/12
to lr-loa...@googlegroups.com
Turn down/off logging

Disable animated replay

Disable run time browser

Remove think time from between transaction markers

Remove complex looping structures from between transaction markers

Examine your code for resource leaks. Free memory as soon as it is not
needed. Free resource handles as soon as they are not needed.

Look for external dependencies on writes to disk on a local or network basis
that can be eliminated. Same holds for network data flows such as calls to
third party components which will not be included in the performance tests
(filters)

String processing is computationally expensive. The less you need to do of
this the better off you are. Examine very carefully your number of
comparisons, especially within loops. Playing "moving the pointer" is
always cheaper than creating a new string item if you are parsing a string
apart.

In the run time settings additional attributes section add a value for
"sensitivity" with a value of either 0 or 9. Both should be faster than
vugen default.

Examine your apples vs oranges comparison. You are referring to items at
the top of the OSI application layer, the GUI interface (top of layer 7), as
being faster than the OSI application layer protocol interface, which is at
the boundary layer of layers 6 & 7. Are you comparing a partial page load
to a full page load, visible portions available but items still be loaded
under the covers or below the visible portion of the page (scroll area)?
Is your browser benefitting directly from cached portions of the page where
your script is not? Clear your local browser cache and see if this pattern
repeats? If you comment out your code is it running at a speed expected?

'Pulley

James Pulley

unread,
Aug 13, 2012, 10:15:09 AM8/13/12
to lr-loa...@googlegroups.com
And I forgot to add....

Are you running on a supported operating system for your version of
LoadRunner? If so, reconcile to a correct environmment

Are you running locally or using remote desktop (or equivalent) to access
VUGEN from another location? If so, then try locally

Are you running inside of a virtual machine? If so, try with a native
machine installation

You should expect to see VUGEN a bit slower for development and debugging
purposes. If you want to experience what it would be like in the
controller you can always take advantage of the MDRV command line interface.
You can look at the popup help for the MDRV flags by going to the \bin
subdirectory of your LoadRunner installation (assuming this is not already
part of your PATH environment variable) and typing 'mdrv'

James Pulley

unread,
Aug 13, 2012, 4:21:44 PM8/13/12
to LR-Loa...@googlegroups.com
Picking one randomly should be very light.  if you have to pick a specific one which matches highly selected/matched criteria then you may want to consider altering your initial array capture to include only items which have a high criteria match and then select randomly from the set.   Or, my preference, better manage your data.

Consider the problem you have also just highlighted.   if you select one item then you may have a 1000 matched records show up.   If you select another item then perhaps five show up.   if you are timing the returned results in a transaction then how are normalizing the behavior of the five record return with that of the 1000 record return in order to understand that you have an app slowness rather than a natural slowness related to data volume?

'Pulley

On Monday, August 13, 2012 2:03:15 PM UTC-4, Priyanka Tiwari wrote:

Thanks a lot James for your valuable suggestions....

I have changed the RTS as u mentioned ,now script run speed in much better.
 
In the test scenario ther will be a large number of entries in the screen and I need to check for the required entry among all the data which is getting populated.
 
Due to this ,there are large number of loopings and comparison in the script to choose a particular data in the screen.
This process is taking a lot of time ...Could you please suggest a way to avoid these comparison.
Since there can be a situation when more than 1000 records are present in the screen and i need to choose one entry from all those entries.
Reply all
Reply to author
Forward
0 new messages