Everyone talks about user experience today – it is a key differentiator in the new economy. When most people talk about the user experience of their application, the conversation is generally focused on the aesthetic design of their application, which while important is merely one aspect of the overall user experience. Often people neglect to think about an area of user experience that can have just as strong of an impact on the overall experience of their application as the application’s aesthetics – application performance!
Infragistics takes the user experience of your application very seriously, which means not only focusing on helping you provide a world class visual experience, but also focusing on the performance of the user experience in your application. In this article, you will learn how Infragistics approached the architecture and testing of Infragistics WebDataGrid™ for ASP.NET AJAX, and how it delivers the fastest grid user experience on the market.
Download a free Infragistics WebDataGrid test drive of NetAdvantage® for Web Client: ASP.NET AJAX controls right now to see its blazing speed for yourself.
Performance and User Experience
Why does performance matter so much in the overall user experience?
- Higher Customer Satisfaction
- Improved End User Productivity
- Resource Efficiency in Hardware and Bandwidth
The customer does not want to be, nor should they be bothered with the details of how an application is developed; they just care about their experience when they use an application. They want an application that simply “makes sense”, which translates to an application that provides an intuitive user interface, and performs as the customer would expect – in other words – they shouldn’t notice or think about how it performs. When you choose the Infragistics WebDataGrid, you get a control that allows you to provide that “makes sense” experience to your end users, including the best performance on the market. And this is not at the cost of implementing a custom ORM (object relational mapping) solution or some custom data provider – this is out of the box data binding. No changes to your data access strategies are needed.
Best Practices for Exceptional Performance
During our product life cycle, we test our UI controls at various stages as new features are added or use cases updated. We follow a series of best practices in the Planning, Configuration, Implementation and Review of our performance tests to ensure the controls are tested in the correct scenarios and that the results we generate are accurate.
- Planning. During planning we determine what we are testing against (a previous build, a competitor, etc) and consider the options and tools available for performance testing on the specific platform. We also identify the specific scenarios that we want to test, and how we can create competitive tests that use as equal a configuration as possible.
- Configuration. In this phase we configure a testing environment that simulates as close as possible what customers are using based on the scenarios that describe the product requirements.
- Implementation. We implement the tests outlined in the test plan and execute them many times to generate the performance statistics
- Review. During review, we evaluate the test results for consistency, looking for anomalies that can indicate a problem in the testing environment that could be affecting test results.
Based on the above described best practices we implement and execute automated performance tests against each nightly build of our products. During the testing, performance results are automatically stored and reports are generated. This enables the development team to constantly monitor the performance through the development process.
For NetAdvantage® for Web Client: ASP.NET, the majority of our performance testing was focused on WebDataGrid, primarily because of its use in many data-intensive applications and the large number of features it includes. Because we regularly talk to customers whose applications require data grid controls that can load very large volumes of data at very high refresh rates, when setting our performance goals and designing our tests we are able to consider those real-world scenarios. To begin testing WebDataGrid, the following test environment was created to execute the performance tests:
- Two physical machines (non-virtual), one server and one client – which would simulate a real life scenario.
- Both server and client are running Microsoft Windows Server® 2003 Standard Edition SP2, CPU 2.13GHz, 4 GB of RAM.
- The server machine is running Microsoft SQL Server® 2005 as the backing data store. We used its default settings.
- The server machine is also running IIS 6.0. We used its default settings.
- The client is running Internet Explorer® 7 for its default browser.
- Both server and client are using the same network switch, which is isolated from other corporate network traffic to help us focus on the performance of the grid apart from other performance-inhibiting factors that would be outside of our control.
- Both server and client are configured with a static IP address.
- Both server and client have Windows Update disabled.
To run the tests, we wrote code which ran all of the test scenarios 100 times. The scenarios ranged from simulated user clicks, to complete CRUD (Create, Read, Update, and Delete) operations with SQL Server 2005. Each run used our latest nightly build and the most recent build of competitor controls available. To determine test results, we recorded the time of each operation, and then calculated the differences.
We developed test applications using the latest public bits of our and competitors’ grids. These test applications are designed to ensure to the maximum extent that we compare apples-to-apples, and they simulate real world scenarios found in banks, call centers, insurance companies, etc. During this comparison we used all public information which we found on our competitors’ websites.
The primary scenarios for grids identified the following areas as critical to the overall user experience of using a grid for data display and editing:
- Flat data binding
- Sorting (string, numeric)
- Filtering (string, numeric)
In this article, unless otherwise specified, we are showing the results of tests executing these scenarios using a data set that includes 10 columns (with all main types of data) and 300,000 rows of data.
In all scenarios we use LinqDataSource, because it gets only needed data from SQL Server which is faster than extracting all data from SQL data tables and getting only needed data outside of SQL Server. SQL Server does it for you.
In all scenarios we use pages with paging (10 rows per page) and filtering on each column. We will split testing and results in two major groups:
- ; Single user operations in browser
- Load testing
Single User Operations in Browser
These scenarios include full cycle - browser rendering (Internet Explorer 7) and the corresponding server response time. These tests more closely represent the customer experience when using the tested data grids.
||210 (21% slower)
||447 (157% slower)
||561 (4% slower)
||800 (49% slower)
||576 (4% slower)
||828 (50% slower)
||193 (12% slower)
||491 (185% slower)
||223 (16% slower)
||515 (169% slower)
Table 1. Time duration (in milliseconds) of several single user operations in the browser for Infragistics WebDataGrid and competing ASP.NET AJAX data grids.
So how do we achieve such amazing performance in our WebDataGrid? The simple answer – it’s the rock solid architecture of the Aikido™ Framework on which the WebDataGrid is based. Additionally, our payload size is smaller than our competitors.
What is “payload size”? The intuitive definition: the amount of data exchanged between server (IIS) and client (browser).
Why is a smaller payload size is better for performance? Exchanges of smaller amounts of data will be processed and rendered faster by the browser. Also, if you have a limited bandwidth connection between your client and server, this will be a huge benefit for you – because less data is transported on the wire.
Using Fiddler 2, we monitor the data exchanged between the client and server. In this next table, you see a summary of the bytes sent and received per operation.
|Unset Numeric Filtering
||459,219 (39% More)
||404,379 (22% More)
Table 2. Payload size (in bytes) of representative single user operations in browser for Infragistics WebDataGrid and competing ASP.NET AJAX data grids.
When we saw how big our advantage is with a single user, we decided to see what happens when we load our and competitors’ grids. We repeated the following steps for WebDataGrid and its competitors:
- We used the same environment and pages for load testing as mentioned above. We used a commercial Web loading tool on the client PC to simulate the load, but you can repeat this load testing with one of the many free Web load testing tools available.
- Our test scenario consisted of the following simulated operations:
- Initial request
- Numeric filtering (“Less than”)
- Clear Numeric filtering
- Numeric Sorting
- We simulated a “think time” interval between all operations of 2 seconds.
- We started ramping up by 2 users every 15 seconds, until we reached 50 users.
- After the ramp up, the load tool continues to run the scenario for 1 hour.
All load tests were repeated several times to remove any chance that a transient glitch in the environment skewed results. Server and client PCs were restarted after each test run.
||884,022 (51% More)
||49.01 (15% Less)
Table 3. Load test results under a simulated load of 50 users for 1 hour for Infragistics WebDataGrid and one competing ASP.NET AJAX data grid (Competitor II could not complete the load test without an out of memory error).
*- Amount of throughput (in bytes/second) on the Web server during the load test, where throughput represents the amount of data that the users received from the server at any given second.
**- The number of hits made on the Web server by simulated users during each second of the load test.
As you can see on the first row of Table 3, the Average Throughput of Infragistics WebDataGrid is 51% better than “Competitor I”. This is directly attributable to our excellent payload size.
On the second row of Table 3, you see that by using Infragistics WebDataGrid, your users have around 15% better productivity per unit time.
So from that load test you can conclude that your users will have 15% increases in productivity if they use Infragistics WebDataGrid.
Finally, you should not forget that these results are achieved in environments where both PCs are on one network switch. In real life, often when the client and server are thousands of miles away and the network bandwidth is limited, this percentage will increase because of the amazing payload size of WebDataGrid. These benefits could result in tens of thousands of dollars a week, and potentially millions of dollars per year, in savings.
You can see that by employing a solid performance testing framework, you can further drive value in terms of actual saved time and perceived experience. We achieve this by using a solid AJAX architectural foundation and compact payloads. We also follow strict best practices methodology of setting up and running tests - each test is performed on the latest releases of Infragistics and our competitor’s latest service releases. Using Infragistics WebDataGrid, your applications will not only look better and be easier to use, but they will outperform anything available on the market today. This leads to higher end user satisfaction, and real dollar savings in the end user productivity of the applications that you deploy.
To test drive Infragistics WebDataGrid today, download a free trial of the NetAdvantage for Web Client: ASP.NET AJAX controls right now. See their blazing speed for yourself!
Copyright © 1996-2009 Infragistics, Inc. All Rights Reserved. Infragistics, the Infragistics logo and NetAdvantage are registered trademarks of Infragistics, Inc. Aikido and WebDataGrid are trademarks of Infragistics, Inc. All other trademarks or registered trademarks are the property of their respective owner(s).