Tips to Reproduce the Performance Issues

23 May

Whenever the performance tester logs an incident for performance issues, the first questions ,development team asks is “ how to we reproduce the incident “ and sometimes they often refuse to agree that there exists any performance issues in the application for the simple reason that incident highlighted is often not reproducible in their environment.

There exists a norm in software development industry that if the incident logged cannot be reproduced by the tester or by the person highlighting it, then it cannot be resolved or solved for the simple reason that not enough information is available to resolve the issue or understand the issue.

I believe that performance incidents are hard to reproduce and do not often occur under functional or manual environments, so it becomes real hard to say as what really happened to the application under load. But however there are some features which most load testing tools provide which can help the performance engineers to reproduce the defect and to know as what the inputs were given to the application at that point that triggered the issues to surface under load test.

In order reproduce the incidents, performance engineer’s needs to have understanding of the functionality of the application along with technical details of the application. In case if the information is not available, then he needs to ask this information with relevant stakeholders before logging an incident. This really helps so that everyone involved stays in the same page. So in this post I would be highlighting some of the features which LoadRunner provides which when used effectively can be helpful in reproducing the incidents.

LoadRunner provides rich set of features which can be used for reproducing incidents which often cannot be reproduced manually, below are some the setting,

  • Enable Snapshot on Error: This feature I believe was introduced in 8.x versions of LoadRunner. Whenever the error occurs, it takes the snapshot of the page and saves it in Vuser logs. However it needs to be enabled in the run time setting of the script. Often snapshot or screenshot are the ones development team requires to believe that error has indeed occurred. So I suggest this feature needs to enabled if you believe that you have some performance issues in the application. However please do keep in mind that enabling this also consumes the LG’s resources.
  • Logging Functions: LoadRunner provides rich set of functions that can be used to log messages to file. However I prefer to use out put message function and disable logging completely. By using output message function (lr_output_message) function, I don’t need to have complete logging enabled, and I see all information which I want to see. I also suggest logging all the correlated values along with user defined parameters using output message function for the reason that under load, one can really find out as what values were given ,what values were captured from the server response and what values were not captured. Once we have the data from output message function, we can reuse the same data and try to reproduce it manually.
  • Extended logging: LoadRunner also provides us the features wherein we can see client request made and server response received from the servers. There might be some cases where in we would like to see as what request client has send that triggered the error in the application under load, in such a cases extended logging can be enabled. However please do note that it impacts response time and consumes lot of load generator resources. Extended logging in LoadRunner helps us to see as what used defined data parameters were used, what response was send by the server and extended trace of the function calls made by the LoadRunner. In short, it shows you the complete trace as what flows in the wire for the user. However this requires the performance engineer have sufficient knowledge to read and interpret the data captured.
  • Iteration Number: LoadRunner provides the feature wherein users can log the iteration number. Under load, each user does many iteration and uses many data points from the user defined data files; it becomes really confusing to know what data was used in which iteration while reproducing the error. So I suggest that one needs to log iteration number along with parameter used in the script either in the beginning of the action block or depending on the requirement. Iteration number along with logged information when correlated with snapshot on errors helps in most of the cases to come out with clear knowledge of the issue found.

However there are some cases of incidents where in spite of having all information, one might not be able to reproduce the incident. For such cases, I suggest that you isolate the scenario and run it having the relevant stakeholders monitoring at their respective ends.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: