In our opinion, the most important thing to know about correlation when working with ASP.Net applications is that there is a “bug”, unacknowledged my Mercury (HP), which prevents viewstate from being captured properly if (and only if) the viewstate is too large.
By default, Visual Studio will leave viewstate on for every control that is dropped onto a web page.
This will result in a viewstate that is so large, that over a WAN the page is almost unusable.
When the viewstate gets this large, LoadRunner will not capture it properly.
Mercury/HP probably does not consider this a bug since proper coding techniques would remove viewstate for all the controls except for the ones which are needed.
However, this single issue has caused more problems in load testing with LoadRunner than any other.
And it is frequently difficult politically to fix because different developers own different pages or parts of pages. It requires managerial co-ordination to review each page and turn viewstate off for all but the controls that need it.
When this is done, your viewstate correlation problems will improve dramatically.
Mercury HP has never wanted to admit that this is a problem, and tech support will not admit this either. There is probably some memory buffer limit in LoadRunner which cannot be set higher or the devs at Mercury/HP just don’t think it should be set higher because no one in their right minds would have a variable as large as the viewstate which occurs when controls are dropped onto ASP.Net pages.
Managers and Dev Leads! Turn Your Viewstate Off!
 |
 |
 |