Viewstate compression stops working after first callbacks

2 posts, 0 answers
  1. Matthew Botting
    Matthew Botting avatar
    41 posts
    Member since:
    Apr 2005

    Posted 21 Mar 2012 Link to this post

    Hi,
    I am using the Radcompression module version 2011.2.915 and have enablePostbackCompression set to true along with RadHiddenFieldPageStateCompression in the App_Browsers folder.

    The page in question has a RadGrid sitting within a RadAjaxPanel. The Grids datasource is being persisted in viewstate, hence it can get quite large.

    I have noticed using Fiddler however that only the first callback appears to have its viewstate compressed.
    The bytes sent for the pageload, followed by its subsequent callbacks are as follows with the hiddenfieldpagestatecompression on
    891  21,920  250,414  232,786
    the above is all in bytes
    when disabled however and following the same steps I get as follows
    987  118,592   250,424   233,082

    I would expect the first number (the page request) to be just about the same as there is no viewstate.
    As expected the first call back is significantly larger due to the lack of viewstate compression.
    I was however surprised to see that the subsequent callbacks bytes sent were almost the same. This suggests to me that the viewstate compression has stopped taking place. The page still works fine however so it has not been corrupted which is good.

    I was wondering if anyone else has encountered similar issues or not?
    Thanks
    Matt
  2. Martin
    Admin
    Martin avatar
    811 posts

    Posted 23 Mar 2012 Link to this post

    Hello Matt,

    Let me try explaining some aspects of RadCompression options and features:

    1. When you enable the RadCompression module (through the web.config httpModules section), you actually get the entire response compressed (including the ViewState). Note that RadCompression will automatically detect and compress requests that expect these content response types (as found in the HTTP request's "ContentType" header or "AcceptsTypes" header):
      • application/x-www-form-urlencoded
      • application/json
      • application/xml
      • application/atom+xml
      In case postback compression is also enabled, the same compression process (the entire response including the viewstate) takes place in every postback as well.
      Based on the above, you do not need to enable ViewState compression through a browser file. The viewstate is already compressed as part of the entire response compression.
    2. RadCompression allows compression for the viewstate only (the rest of the response stays intact). This can be achieved by adding the RadHiddenFieldPageStateCompression adapter in a browser file as you have already discovered. Note that this adapter is an overriden version of RadCompression (inherits from RadCompression) that compresses just the viewstate. Therefore to use the adapter you do not need to enable RadCompression module through the web config file as described above. RadHiddenFieldPageStateCompression is designed to be used separately from the RadCompression module in cases where only viewstate compression is needed.
    3. Determining the viewstate size on the client may mislead you. What you actually see is the decompressed viewstate because the browser automatically decompresses it behind the scenes after the response is received. To verify that the compression works correctly, you should examine the response size instead of the viewstate size.

    As to your particular scenario - since you have enabled RadHiddenFieldPageStateCompression as well as RadCompression, you actually get the viewstate compressed twice in some of the requests. As described above you should use only one of those features. Judging by the enabled postback compression, I suggest that you use the RadCompression module only and remove the RadHiddenFieldPageStateCompression adapter from the browser file. This way the entire response (including  the viewstate) will be correctly compressed only once.

    I hope this helps.

    Regards,
    Martin
    the Telerik team
    If you want to get updates on new releases, tips and tricks and sneak peeks at our product labs directly from the developers working on the RadControls for ASP.NET AJAX, subscribe to their blog feed now.
  3. UI for ASP.NET Ajax is Ready for VS 2017
Back to Top