Faster than “fastest ASP.NET Grid”
Nowadays, component vendors tried to come up with amusing marketing campaigns, and some of them claimed that their ASP.NET Grid is the fastest and they even show a comparison to two industry’s leading Grid product in their live demo, although they didn’t mention the names. Due to the privacy and sensitive nature of this post, I won’t mention that vendor’s name here and I will use an initial “XGrid” to refer their Grid in this post.
At first, we don’t bother to check the accuracy of their claim as it has nothing to do with our products. However, recently, I’ve become aware of several customers who demanded to know the performance comparison between “XGrid” and our WebGrid. In this post, I’m going to share my experience with the performance testing, and learn how we addressed such scenarios for large enterprise-ready usage.
Toward that curiousity, I’m conducting a performance testing, both are using live deployed samples. Here are the results:
Runtime Performance
“XGrid”, claimed to be the fastest Grid and claimed to load 300k data < 2 seconds. The fact is it loads averagely in 6 seconds. See following screenshot.
WebGrid.NET Enterprise 6.0 (coupled with flagship ISDataSource for advanced load-on-demand feature), tested to load 350k data < 2 seconds. See following.
Memory Consumption
Now that you’ve seen the runtime performance comparison, how about the memory consumption? “XGrid” claimed that it took less than 10MB in memory consumption, that’s good enough while other products may take at least 500mb in this kind of operation. The 500mb memory consumption is unavoidable since most Grid products depend on .NET’s DataSet which took around 400MB in a simple “adapter.Fill(dataSet)” syntax.
WebGrid.NET Enterprise 6.0, coupled with ISDataSource 1.0 in the 2008 release significantly reduces memory consumption when loading from such large table. ISDataSource incorporates an advanced load-on-demand technology, which seamlessly connected to WebGrid in order to provide high-performance results.
Surprisingly, our WebGrid took only < 5MB memory consumption for databound operation. The following arethe memory snapshots of the w3wp process after performing 2 times paging, and sorting, respectively.
Data Operation
ISDataSource features unique capabilities and bare-metal architecture which offers greater flexibility and customizability. When used in WebGrid, it extends several advanced functionalities such as ability to perform custom filtering and sorting, custom data aggregation, and so on.
In this sample, sorting, paging, filtering and data aggregation are applied on global data, instead of the paged data. It is made possible with ISDataSource’s flexible architecture and event handling so that extra scenarios can be handled in the provided events.
Conclusion
Our sample is using our unique ClassicPaging feature, combined with Custom Load-on-Demand setting, and Custom Aggregate-Retrieval for ColumnFooter setting. Note that you need the latest WebGrid 6.0 and ISDataSource (2008 R1+) to simulate this test. The comparison is an “apple to apple” measurement and it’s loaded on a table with over 350.000 rows, note that aggregate functions on the column footer are returning all data rows (and not the paged data). And still, our performance is far more faster than “XGrid”, and our memory usage is less than 5 MB (while they took < 10MB). To experience it yourself, point your browser to this sample. Seeing is believing 
Needless to say. It is well proven that our flagship WebGrid.NET Enterprise 6.0 is still the most advanced and innovative ASP.NET Grid, with unmatchable performance and unique capabilities to address enterprise-level data scenarios.
If you’re interested further in learning about performance topic, please write your comments and questions in this post. Hopefully you find this post useful in your evaluation on performance and related topics.
Best Regards,
Jimmy.
Dear Sir,
I have some concerns regarding the Intersoft Grids, they through large HTML code on the client side and they consume all my w3wp.exe process. Is this resolved in the new version ?
Hello Moe,
The HTML codes have been reduced significantly in v6. And furthermore, the w3wp.exe is now consumed properly. You can try to download WebGrid 6.0 and try the live samples that included in it.
Regards,
Jimmy.
webgrid was not able to release memory after several loads or operations. after each load or page operations like sorting, paging the size of the memory used was getting bigger and bigger which was ending with an application crash. Is this solved now?
Or is there any stress test results? Say 100 users are accessing the page with the webgrid that loads 350k data all at the same time. What is the memory usage then and how long does page load take “in average” with that many users?
knowing different aspects of the performance test will help more in further decisions.
thanks
-shane
Is the source code of this sample available to customers?
Shane: The ability to release memory is beyond control’s code. It is managed by .NET Memory Management automatically (also known as Garbage Collector). However, we have tested and clarified that the memory allocated by WebGrid is properly released when .NET performed GC.
We are going to perform some stress-test soon and publish the results. Although I am pretty sure that the WebGrid can handle the large users access with very minimal memory usage. This is made possible because WebGrid v6 is no longer the data provider, but WebGrid is a pure data visualization (UI) which grabs the data from provider, which is ISDataSource in this context. ISDataSource itself is a rock solid data provider built on the top of high performance architecture, which acts as the mediator between database backend and UI.
Regards,
Jimmy.
Iain: We’ll publish the source code of the sample soon in our Support’s Knowledge Base. Our team is waiting to deliver WebGrid 6.0 SP1 which contains a new Charting engine, and other dozens of enhancements, along with the sample.
Thanks for your quick response. Your sample gives me hope. As your grid evolves into more of a BI tool, our customers are expecting to load it up with large data sets, and do analysis. This is presently causing us server loading headaches. It would be nice to be able to provide some lightweight BI on the web, without the server overload.
You mentioned a new charting engine – sounds interesting – can you elaborate?
Yeah Jimmy,
thakns for the quick response. i had this problem with the early versions of webgrid (i think it was version 4.0) and i am sure a lot changed from 4.0 to 6.0.
the problem basically was the memory usage. with 25k data the amount of the memory used was around 300mb, opening the same page in another browser window was making this number jump upto 450mb. Navigating away from the grid page and coming back to it was making it go up more and this is with a couple users only. And after memory usage reached its max GC was doing its job and clearing everthing out which was also causing the session states to be cleared out. And users were redirected to the error page. it was pretty frustrating. The suggestion of using session state for caching and not memory crashed the server in about 30 secs. Was completely impractical.
This is the reason i asked for a stress test. In individual usage the grid may give superior results but does it still perform that well under heavy load with several hundred users?
thanks again
-shane
Iain: As you may aware, WebGrid.NET 6.0 comes with Pivot Charting feature. The Pivot Charting feature is using a third party Charting engine from Nevron as the runtime engine to draw the Chart. In SP1, we will employ a built-in Charting engine (we will try to produce consistent results as close as those in the previous Charting engine).
We will no longer use Nevron Chart starting from SP1, although existing customers who already deploy the Pivot Charting may still use Nevron Chart as the engine (the Grid will have a property that allow you to easily change the engine).
A good thing with the new, internally-developed Charting engine is that it will allow us to provide more enhancements to the Charting engine in the future version.
Regards,
Jimmy.
Shane: Good news, I have managed to run a stress test during the weekend to see the WebGrid performance under heavy load.
The result is very good, which indicates stable memory consumption under 150 users load under 2 minutes constant testing. The test is performed using Visual Studio 2008 Performance Load Test.
% Committed Bytes In Use. Min: 50.5MB, Max: 54.1MB, Avg: 52.7.
After the load test, the w3wp.exe is showing only 64.MB usage. This indicates that the memory counter is showing accurate and believable results.
If you are interested in a screenshot, please let me know your email address and I’ll capture a shot for you.
Regards,
Jimmy.
Jimmy,
sounds very promising and no need for the screen shots. i ll go with your word.
thank you