ASP .NET performance testing tips
Submitted by Ainars Galvans on Mon, 26/03/2007 - 11:43.
performance testing | Visual Studio .NET
Just finished a performance testing in a pilot project completely based on a plain ASP .NET technology. I wanted to share two lessons learned during that project but doing more search on internet I learned a new lesson: you could and you actually should find on internet the technology-specific performance issues even before you start testing (especially given that you have a time for that: while code is not complete/functionally stable).
Details follow
I was occasionally (part-time in parallel to my current project functional tests) assigned to the pilot WEB application project (initiated/sponsored by some huge, well-known company that I’m not going to mention here, because it does not matter) as performance tester. That was the first project I tested that is completely based on a plain ASP .NET technology (+ MS SQL server). What I wanted to talk about – how the technology influence performance testing.
There was two major surprises for me:
1) Huge size (up to 10 000 characters) variable
Viewstate send from server and back to it on almost every call. The summary of this phenomena: server-side state is not saved on server, it is serialized and sent to client via this variable. When client submit the next request it send the state back, which is deserialized on server. This was a problem for Load Runner capture-playback tool as it’s capturing capabilities somehow unreliable recognized such a huge data correlations.
2) Some caching issues (not working cache). javascripts and dynamic objects that does not changes too frequently (for example image rendered that represent current org. structure) are not always cached in browser. There are differenc resons for that such as debug mode turned on or missing usage of cache control extentions
However what surprised me that those issues are already described for in ASP.NET 10 Tips for Writing High-Performance Web Applications . 3 out of 10 are about caching, one about viewstate variable and other 6 universal topics such as compression and suggestion not to do a single row select in a loop (rather return them all in one result-set).
To illustrate why those are generic issues - the last issue I mentioned was the major (but solved) issue in another project using JAVA + hibernate as a technology. There was another issue however in that project: limited capabilities for hibernate to optimize the SQL statement generation that was reason for dev. team to drop using this technology, but that’s completely another story about another technology.
So the bottom line - something depend on technology purely and you could learn it without even starting the developing, not to mention testing.
Details follow
I was occasionally (part-time in parallel to my current project functional tests) assigned to the pilot WEB application project (initiated/sponsored by some huge, well-known company that I’m not going to mention here, because it does not matter) as performance tester. That was the first project I tested that is completely based on a plain ASP .NET technology (+ MS SQL server). What I wanted to talk about – how the technology influence performance testing.
There was two major surprises for me:
1) Huge size (up to 10 000 characters) variable
Viewstate send from server and back to it on almost every call. The summary of this phenomena: server-side state is not saved on server, it is serialized and sent to client via this variable. When client submit the next request it send the state back, which is deserialized on server. This was a problem for Load Runner capture-playback tool as it’s capturing capabilities somehow unreliable recognized such a huge data correlations.
2) Some caching issues (not working cache). javascripts and dynamic objects that does not changes too frequently (for example image rendered that represent current org. structure) are not always cached in browser. There are differenc resons for that such as debug mode turned on or missing usage of cache control extentions
However what surprised me that those issues are already described for in ASP.NET 10 Tips for Writing High-Performance Web Applications . 3 out of 10 are about caching, one about viewstate variable and other 6 universal topics such as compression and suggestion not to do a single row select in a loop (rather return them all in one result-set).
To illustrate why those are generic issues - the last issue I mentioned was the major (but solved) issue in another project using JAVA + hibernate as a technology. There was another issue however in that project: limited capabilities for hibernate to optimize the SQL statement generation that was reason for dev. team to drop using this technology, but that’s completely another story about another technology.
So the bottom line - something depend on technology purely and you could learn it without even starting the developing, not to mention testing.