Each performance engineer has his own style of debugging and
is comfortable one of the approaches. While the following approach doesn’t claim
to be the best approach, it sure helps with an approach for the beginners and
act as a quick reference for the hands on guys as well.
·
One
request at a time - While some go with one concept at a time, this approach
suggests to go with one request / transaction at a time. During the debugging
process, place a return -1 or return 0; after the transaction to ensure that
replay of the script goes only until the transaction that we are currently
working. Apply all the concepts like parameterization, correlation, page verification,
think time and transactions for this transaction and replay to ensure that the
script is working fine until the current transaction.
Note:
return -1 will stop the execution of the script whereas return 0 will stop only
the current iteration. To understand the difference, try setting the Runlogic
to more than 1 iteation.
·
Correlation
Challenges: The most probable reasons that a dynamic data is not captured
is
o
The Left and right boundaries defined in the
correlation function can be wrong – Be sure to check for the additional spaces,
Tab Vs. spaces, escaping the double quotes
o
The placement of correlation function – Majority
of the cases, the dynamic data should be available in previous request’s
response. However, this may not be true always. Be sure to identify the request
that receives the response with dynamic data and the correlation function
should be placed above such request
o
Size matters – if huge dynamic data (Ex:
Viewstate) is to be captured, be sure to specify the max length of the LR
parameter by using the function web_set_max_html_param_len() function before
capturing the dynamic data
o
Ensure dynamic data is generated by server –
While 95% of the cases the dynamic data is received in server response, there
is also a chance that the dynamic data is generated by client side java script
as well (Ex: Hashcode generator). In such cases, the java script code needs to
be identified and integrated with the script using web_js_run() function
·
Headers
are crucial – LoadRunner is able to handle all the standard headers by
default. However, if the request contains custom headers, those need to be
added in the script explicitly with the functions web_add_header() /
web_add_auto_header(). The easiest way to identify if the script is missing on
any custom headers is to compare the snapshot information / Advanced trace in
Log settings with network sniffing data (either from Developer tools or Fiddler
session’s data)
·
Encoding
data – web_url() and web_submit_data are capable of handling URL encoding automatically
whereas the web_custom_request expects the form data as is. Hence, if the raw
data of the request contains the URL encoding, be sure to convert the text into
URL encoded form by using the function web_convert_param()
As long as the request triggered from LoadRunner is same as the one from the browser, the scripts should work fine without any issues. Simulating the exact same request to that of the browser is the key while debugging the script.
As long as the request triggered from LoadRunner is same as the one from the browser, the scripts should work fine without any issues. Simulating the exact same request to that of the browser is the key while debugging the script.
