Clarity, Technology, and Solving Problems | PracticeThis.com
WP7 App with Key Windows Azure resources – Slides, Videos, How-To’s, and T-shooting – for quick consumption on the go.
LinkedIn
To achieve best performance you need to make decisions based on trade-off between coolness, coding productivity, and personal engineering values. I never thought I would be recommending my customer considering using old fashion Response.Write() in his Internet facing ASP.NET web application in order to significantly improve the application’s performance.
During load/stress testing customer’s ASP.NET web application we identified high CPU utilization (up to 90%). After quick investigation we noticed that %Time in GC performance counter is less than optimal. Our assumption was that the application uses memory allocation techniques that are less than optimal. From GC Performance Counters:
"First thing you may want to look at is “% Time in GC”... What is a health value for this counter? It’s hard to say. It depends on what your app does. But if you are seeing a really high value (like 50% or more) then it’s a reasonable time to look at what’s going on inside of the managed heap."
Another resource we used is timeless patterns & practices’ Chapter 15 — Measuring .NET Application Performance:
.NET CLR Memory\% Time in GC "…The most common cause of a high value is making too many allocations, which may be the case if you are allocating on a per-request basis for ASP.NET applications. You need to study the allocation profile for your application if this counter shows a higher value."
.NET CLR Memory\% Time in GC
"…The most common cause of a high value is making too many allocations, which may be the case if you are allocating on a per-request basis for ASP.NET applications. You need to study the allocation profile for your application if this counter shows a higher value."
So we headed to looking into the code and this is what we found out.
During performance code inspection we identified massive usage of collections. The collections were used to transfer the data between the logical layers and then the collections were transferred into datatables to be bindable for DataGrid (yes, it is .Net 1.1 app).
Eureka! We just spotted 3 performance anti-patterns. Massive memory allocation, massive loops, massive type conversions. I’ve shown it to 4 very respected professionals and everyone was saying the same – current situation is pure performance anti-pattern. Here are few suggestions that came up:
"Use the Response.Write method. It is one of the fastest ways to return output back to the browser."
Case close? Not really...
Secretly I’ve built Visual Studio 2003 project with these implementations and ran simple stress test using TinyGet utility. The results left us all a bit surprised.
The code:
1: //create custom collection
2: MyCollection myCollection = (MyCollection)SampleServices.GenerateCollection(200);
3:
4: //convert collection to datatable
5: DataTable datatable = SampleServices.ConvertCollectionTableIntoDataTalbe(myCollection);
6:
7: //bind datatalbe to dynamically created datagrid
8: datagrid.DataSource = datatable;
9: datagrid.DataBind();
1: MyCollection myCollection = (MyCollection)SampleServices.GenerateCollection(200);
2:
3: //bind datatalbe to dynamically created datagrid
4: datagrid.DataSource = myCollection;
5: datagrid.DataBind();
The stress test:
tinyget.exe -srv:192.168.50.68 -uri:/dynamiccontrolsloadingrelease/UseCustomCollection.aspx -loop:100 -threads:15
The result:
1: string xml = SampleServices.GenerateXml(200);
3: StringReader theReader = new StringReader(xml);
4: DataSet theDataSet = new DataSet();
5: theDataSet.ReadXml(theReader);
7: datagrid.DataSource = theDataSet.Tables[0].DefaultView;;
8: datagrid.DataBind();
tinyget.exe -srv:192.168.50.68 -uri:/dynamiccontrolsloadingrelease/LoadXmlIntoDataTable.aspx -loop:100 -threads:15
1: Xml1.DocumentContent = SampleServices.GenerateXml(200);
2: Xml1.TransformSource=@"xsl.xml";
tinyget.exe -srv:192.168.50.68 -uri:/dynamiccontrolsloadingrelease/XmlXslTransformation.aspx -loop:100 -threads:15
3: // Put user code to initialize the page here
4: Response.Write("<table>");
5:
6: foreach(MyModelItem item in myCollection)
7: {
8:
9: Response.Write("<tr>");
10: Response.Write("<td>" + item.Address + "<td>");
11: Response.Write("<td>" + item.City + "<td>");
12: Response.Write("<td>" + item.Education+ "<td>");
13: Response.Write("<td>" + item.Family + "<td>");
14: Response.Write("<td>" + item.Name + "<td>");
15: Response.Write("</tr>");
16: }
17: Response.Write("</table>");
tinyget.exe -srv:192.168.50.68 -uri:/dynamiccontrolsloadingrelease/ResponseWrite.aspx -loop:100 -threads:15
Interested in testing it yourself? Grab the source code from my SkyDrive here:
After conducting this simple test these are the conclusions I’ve made:
You've been kicked (a good thing) - Trackback from DotNetKicks.com
Really nice. I love how thorough you were in the investigation and in reporting the results.
Thanks for taking the time to put this together.
James, great to hear you found this useful
    In my previous post -  Best ASP.NET Performance Winner For Data Binding - Hands
Well, I see a major flaw in this test since datagrid is not rendered into the pure html table actually.
You'd better test this vs. repeater and even repeater supports a bunch of events like itemdatabound and itemcreated.
Another week of great resources for the .NET developer to take in. Amazing how many are out there. I
Anatoly,
Thanks for the resourceful remark!
My intention was to take customer's code and test it as is. There is simple meta pattern - developers code, end users use, IT guys support. All iwanted is to model what would it feel like for end users and IT guys when developers code the way they code (and as I just witnessed it)
Repeater is another test I should have consider though - thanks for calling it out!
Thanks for an interesting post!
One question; did you exclude using StringBuilder on purpose?
If not, it may be worth testing the "Response.Write" against using a StringBuffer to see how tha compares...
Cheers,
Joakim
Joakim,
Thanks for the insight!
Few folks called this out too. I did not use StringBuilder originally as I was lazy to do so. In any way it would only improve it, right. But then I've built the demo that uses StringBuidler and there were no significant improvements.
Next post is about using Repeater and ItemDataBoubd event as another reader called out Nice results BTW :)
thanks for checking in.
Hi, I think you could make the Response.Write even faster if you avoided the string concat inside of them.
Response.Write("<td>" + item.Address + "<td>");
might be better written as
Response.Write("<td>");
Response.Write(item.Address);
Response.Write("</td>");
I think that might reduce string concat.
Also I think Response.Write just uses a stream which will perform as well or better than StringBuilder. Or at least it should :)
Sam,
Thanks for the insight
few pointed this one out too, see my prev response[.Write ] :)
Just looked at your web site - oh, lala! Bookmarked
Note that Databinding is doing some additional stuff like cross-site-scripting checks, etc. that ideally you'll need to do if you use this method.
Daniel!!
That is perfect remark. Not perf wise but security wise.
Brilliant!
I do not think that applying htmlencoding will add to much burden vs reflection Databinding does, but i must appreciate your comment.
See, security and perf, has never been good friends
Very good catch!
This is not a comparison between datagrid with reponse.write.
Have you profiled it to find out what the real performance bottle neck is? Did you try it with serveral different datatypes?
What is the influence of looping through the datagrid and then casting to myCollection?
You can make a better benchmark to isolate the code before the databind() call and before the foreach loop in the other version.
I have tried this before and I'm sure you will get totally different results!