Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeUsing DNN Platf...Using DNN Platf...Performance and...Performance and...Moving the viewstate to the server with a PageAdapterMoving the viewstate to the server with a PageAdapter
Previous
 
Next
New Post
6/24/2014 9:56 AM
 

I'm next to test a solution to move Viewstate to disk/cache/db with a page adapter overriding the HiddenFieldPageStatePersister

Now my doubt is... I saw there are already several .browser files in App_browser so if I create a new one for "default" browser to override the page will this break things up? Should I add  the lines in all the existing .browser files?
 
New Post
6/24/2014 6:45 PM
 
Max, keeping viewstate just on the server means that client side code cannot access it and make use of it, If you are following the trend of moving more and more computing on the client side, this doesn't makes sense. And I am glad that for DNN 7.3 the dev team finally took care of reducing the viewstate - of course, there are still a number of extensions, which still have to follow this route.

Cheers from Germany,
Sebastian Leupold (Microsoft MVP)

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
6/25/2014 5:04 AM
 
Hallo Leupold! Usually I agree with you but in this case, even if I agree that more resources are moved to the client and that's good, reguarding the viewstate I think the default Microsoft implementation is awful. The viewstate is only needed on the server but is always sent back and forward on each post between the client and the server, so you'll have 300/600/1000 KB of data (and relative download/upload time) going back and forward between client and server for a resource that is only needed on the server.
The idea is to move this permanently on the server (file system, cache, distributed cache, database) and tie it to the page with a unique Id, so the client will only be sendind and receiving a bunch of bytes instead 300+ KB.
This is quite a common optimization in ASP.Net, just like the Page Output Cache one and you can find plenty of articles and examples on it. The main "problem" is that most of them resort to writing a base page class and having all the pages inherit from that one, to override the methods that handle the viewstate, but a workaround is infac to to exploit the page adapter (or httpmodule but this is even more complex in this scenario) so you con leave DNN base code intact.

As always I'll keep you notified on my progress on this (as well as on the Output Cahce).
 
New Post
6/25/2014 5:55 AM
 
Max, with DNN 7.3, the core viewstate has been reduced to a few bytes per page, now module developers should check their modules to reduce viewstate as well, and it shouldn't be a big issue any more.

Cheers from Germany,
Sebastian Leupold (Microsoft MVP)

dnnWerk - The DotNetNuke Experts   German Spoken DotNetNuke User Group

Speed up your DNN Websites with TurboDNN
 
New Post
6/25/2014 6:11 AM
 
I didn't check yet but I guess that overall it would be always around 300KB as a minimum + the modules you add. I think it's a well worth solution
 
Previous
 
Next
HomeHomeUsing DNN Platf...Using DNN Platf...Performance and...Performance and...Moving the viewstate to the server with a PageAdapterMoving the viewstate to the server with a PageAdapter


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.

Content Layout

Subscribe to DNN Digest

DNN Digest is our monthly email newsletter. It highlights news and content from around the DNN ecosystem, such as new modules and themes, messages from leadership, blog posts and notable tweets. Keep your finger on the pulse of the ecosystem by subscribing.  


Copyright 2017 by DNN Corp Terms of Use Privacy
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out