A few weeks ago, I showed you how you can use the new RadCompression HttpModule found in the RadControls for ASP.NET AJAX Q3 2008 SP2 (and later) to easily (as in, automatically) compress your Ajax and JSON web service communication. While that technique is great for improving the performance of modern web apps that do lots of processing client-side, that’s not the only thing RadCompression can do. It can also automatically compress ViewState! This week, I’ll show you how you can quickly enable ViewState compression and show you the effects it has on overall ViewState size and server performance.
HOW DO I ENABLE VIEWSTATE COMPRESSION?
Enabling ViewState compression with the RadCompression module really couldn’t be easier. It requires no changes to your code, no changes to your markup, and not even a change to your web.config (assuming you’ve already added the required HttpModule references from the previous article). The only thing you need to do is add a new Browser file to your web project (or modify your Browser file if you’re already using one). To add a new Browser file, follow these simple steps:
- Right-click on your web project, select “Add…” > “Add ASP.NET Folder…” > “App_Browsers”
- Right-click in your new App_Browsers folder, select “Add…” > “Add New Item…” > “Browser File”
- The new browser file will have some default values, feel free to delete everything and then add this code:
XML (in your .browser file)
<browsers>
<browser refID="Default">
<controlAdapters>
<adapter controlType="System.Web.UI.Page" adapterType="Telerik.Web.UI.RadHiddenFieldPageStateCompression" />
<!--Uncomment the following line to use SessionStateCompression and remove ViewState from the page-->
<!--<adapter controlType="System.Web.UI.Page" adapterType="Telerik.Web.UI.RadSessionPageStateCompression" />-->
</controlAdapters>
</browser>
</browsers>
And that’s it! Really. Run your project at this point and you’ll discover that the RadCompression module is now automatically compressing your ViewState.
HOW MUCH DOES THE COMPRESSION HELP?
ViewState, as you probably know, is just a serialized string of data. By default, it’s not compressed, it’s not encrypted, and it’s often a bloated piece of string data that gets passed back and forth with every request to the server (even Ajax requests if you’re using UpdatePanels). Compressing this data is an easy way to reduce your page size and reduce the number of bytes you must send and receive from the server.
To demonstrate RadCompression’s effectiveness, I created a simple page with a RadGrid that loads data from the AdventureWorks Employees table. I bound my grid declaratively (which means all bound data will end-up in ViewState) to an EntityDataSource and I slowly started “cranking-up” my Grid’s page size- from 10 records to 240 per page. As I cranked-up page size, obviously my ViewState grew. I ran 7 tests with and without RadCompression and the results are below:
RadCompression Efficiency
The blue bars represent the ViewState size (in KB) with RadCompression. The green bars represent the difference in the original ViewState size (i.e. total size with no compression). And the red numbers indicate the compression “efficiency” at each step (for instance, “53%” means the compressed ViewState was 53% smaller than the original). You should note a few things about this chart:
- As the original ViewState grew, the compression became even more “efficient” (ranging from 47% to 75% compression ratios)
- In the first two tests, there was no difference between the original and the “compressed” output – more on this in a moment
- On average, RadCompression reduced ViewState size by 61%! (omitting the “0” tests)
So why are the first two tests “0%”? RadCompression actually has a “threshold” that must be passed before compression will kick-in. For smaller ViewState sizes, it doesn’t make sense to apply compression- the overhead of the processing and compression header/footer offset the small gains in overall state size. Currently, this threshold is 8KB. If your original ViewState is smaller than 8KB, RadCompression will automatically skip over it. Bigger than that, and RadCompression will automatically kick-in.
WHAT IS THE EFFECT ON SERVER PERFORMANCE?
Many people will often say, “Sure you can compress ViewState, but doesn’t that add significant processing overhead on the web server?” It is true that adding compression represents extra CPU cycles and it does have an effect on server performance. With RadCompression, though, that impact is relatively small. Internally, RadCompression uses Deflate compression to compress and decompress state, which is much faster than Gzip compression. And thanks to the optimizations of the compression APIs in .NET, the overall effect on server processing time is low.
To test this, I took our same test page and used a .NET Stopwatch (System.Diagnostics.Stopwatch) to test the time it took the server to process our page. I started the timer in OnPreInit and stopped it at the end of OnRender- a cycle the fully captures the loading and saving of ViewState. I then ran 6 tests and measured the server time (in milliseconds) with and without RadCompression enabled. For testing purposes, I chose to test the page configuration that had “70%” efficiency since this should represent a fairly large amount of compression work. Here are the results:
The blue bars represent the original server time; the green represent the server time with compression enabled. (NOTE: This is not page load time, which I often test in these Optimization Tips. This is strictly a measurement of the effect on server processing time.) What you can gather from this graph is that there is no clear disadvantage to using compression. Sometimes a page with compression processes faster than a page without. Sometimes the reverse is true. When you crunch the numbers, compression turns-out to only impact server processing time by 10% on average. In absolute terms, we’re talking about a difference of 10 milliseconds.
And remember, this is server time. The page with compression- which has shaved ViewState size by 70%- should ultimately beat the original page’s overall load time because it has less data to send over the wire and less data for the browser to process. You will have to run your own tests to determine if the server cost is worth the savings in page state size for your site, but based on these tests, you are likely to come-out ahead with compression.
TIP SUMMARY
This may be one of the easiest ways to help reduce your page size, and in turn, help improve your page performance. By simply registering the RadCompression HttpModule and adding a .browser file to your project, you can see reductions of over 70% in your ViewState size with little impact on your server performance. Clearly, as developers we should all be taking active steps to reduce our ViewState size, but if you’ve already done everything you can (or at least everything you have time for) and you want to squeeze a few more KB out of your page, RadCompression is ready and waiting for you in your Telerik toolbox.
Enjoy!