I have a large ViewState and I've heard I can save the ViewState in a sesison
object. What are the advantages of doing so and how do I do it? I've been
told that I am gettign DNS timeouts because of the ViewState being too large.
I'm trying to avoid writing manual paging routines for now.
--
Tim

Hi Tim,

View State can be customized to be stored in a Session or Cache object. It
is done by overriding the 'SavePageStateToPersistenceMedium' and
'LoadPageStateFromPersistenceMedium' methods. (see code snippet below)


protected override void SavePageStateToPersistenceMedium(Object viewState)
{
string _vskey;
_vskey = "VIEWSTATE_" + base.Session.SessionID + "_" + Request.RawUrl +
"_" + System.DateTime.Now.Ticks.ToString();

Cache.Add(_vskey, viewState, null,
System.DateTime.Now.AddMinutes(Session.Timeout), Cache.NoSlidingExpiration,
CacheItemPriority.Default, null);

RegisterHiddenField("_VIEWSTATE_KEY", _vskey);
}

protected override object LoadPageStateFromPersistenceMedium()
{
string _vskey = Request.Form["_VIEWSTATE_KEY"];

if (_vskey == null)
{
return null;
}
else
{
return Cache[_vskey];
}
}

Advantages: If the ViewState is large, it increases the page size
considerably and results in an increase in response time (page load time).
Saving the ViewState to a session/cache can result in an improved response
time (page size is reduced considerably). On the other hand, it can consume
server resources (which can be handled by improving the hardware).

Regards,
Augustin




"AAOMTim" wrote:

> I have a large ViewState and I've heard I can save the ViewState in a sesison
> object. What are the advantages of doing so and how do I do it? I've been
> told that I am gettign DNS timeouts because of the ViewState being too large.
> I'm trying to avoid writing manual paging routines for now.
> --
> Tim

Here is a link (http://www.eggheadcafe.com/articles/20040613.asp) to a
customised persistence mechanism that we implement recently.

A number of our customers share 512/128 DSL connections between a number of
staff, and the posting back of large viewstates was causing significant
performance issues for them.

We choose to store the viewstate in a SQL store, and although this incurs an
extra database hit, that hit is significantly less than the round trip of a
large viewstate to the browser and back.


<DIV>&quot;AAOMTim&quot; &lt;(E-Mail Removed)&gt; wrote in
message news:3ED1B2CA-1BBD-4870-AEB2-(E-Mail Removed)...</DIV>>I
have a large ViewState and I've heard I can save the ViewState in a sesison
> object. What are the advantages of doing so and how do I do it? I've
> been
> told that I am gettign DNS timeouts because of the ViewState being too
> large.
> I'm trying to avoid writing manual paging routines for now.
> --
> Tim

Thank you for your response. Can you discuss the merits of saving to a Cache
object instead of to a Session?
--
Tim


"Augustin Prasanna" wrote:

> Hi Tim,
>
> View State can be customized to be stored in a Session or Cache object. It
> is done by overriding the 'SavePageStateToPersistenceMedium' and
> 'LoadPageStateFromPersistenceMedium' methods. (see code snippet below)
>
>
> protected override void SavePageStateToPersistenceMedium(Object viewState)
> {
> string _vskey;
> _vskey = "VIEWSTATE_" + base.Session.SessionID + "_" + Request.RawUrl +
> "_" + System.DateTime.Now.Ticks.ToString();
>
> Cache.Add(_vskey, viewState, null,
> System.DateTime.Now.AddMinutes(Session.Timeout), Cache.NoSlidingExpiration,
> CacheItemPriority.Default, null);
>
> RegisterHiddenField("_VIEWSTATE_KEY", _vskey);
> }
>
> protected override object LoadPageStateFromPersistenceMedium()
> {
> string _vskey = Request.Form["_VIEWSTATE_KEY"];
>
> if (_vskey == null)
> {
> return null;
> }
> else
> {
> return Cache[_vskey];
> }
> }
>
> Advantages: If the ViewState is large, it increases the page size
> considerably and results in an increase in response time (page load time).
> Saving the ViewState to a session/cache can result in an improved response
> time (page size is reduced considerably). On the other hand, it can consume
> server resources (which can be handled by improving the hardware).
>
> Regards,
> Augustin
>
>
>
>
> "AAOMTim" wrote:
>
> > I have a large ViewState and I've heard I can save the ViewState in a sesison
> > object. What are the advantages of doing so and how do I do it? I've been
> > told that I am gettign DNS timeouts because of the ViewState being too large.
> > I'm trying to avoid writing manual paging routines for now.
> > --
> > Tim

Thanks for the response. How would you compare the efficiency of saving your
ViewState to a SQL Store as compared to saving it to Cache?
--
Tim


"Dave Moyle" wrote:

> Here is a link (http://www.eggheadcafe.com/articles/20040613.asp) to a
> customised persistence mechanism that we implement recently.
>
> A number of our customers share 512/128 DSL connections between a number of
> staff, and the posting back of large viewstates was causing significant
> performance issues for them.
>
> We choose to store the viewstate in a SQL store, and although this incurs an
> extra database hit, that hit is significantly less than the round trip of a
> large viewstate to the browser and back.
>
>
> <DIV>"AAOMTim" <(E-Mail Removed)> wrote in
> message news:3ED1B2CA-1BBD-4870-AEB2-(E-Mail Removed)...</DIV>>I
> have a large ViewState and I've heard I can save the ViewState in a sesison
> > object. What are the advantages of doing so and how do I do it? I've
> > been
> > told that I am gettign DNS timeouts because of the ViewState being too
> > large.
> > I'm trying to avoid writing manual paging routines for now.
> > --
> > Tim
>
>

Hi Tim

When we looked at the article I mentioned, we saw that using the cache was
perhaps the most efficient custom store.

For us the potential memory footprint of using the cache was a risk and as a
result we didn't even test the real world response times using the cache. We
run multiple servers in a farm and so our application already used SQL as
the session store, and that gave us immediate scalability.

As I mentioned previously, the saving we made just using the SQL store was
significant, so we have not had the need to try and squeeze any blood from
the stone if you will.

Dave





<DIV>&quot;AAOMTim&quot; &lt;(E-Mail Removed)&gt; wrote in
message news:80D2C46C-A2B8-428A-9E41-(E-Mail Removed)...</DIV>>
Thanks for the response. How would you compare the efficiency of saving
your
> ViewState to a SQL Store as compared to saving it to Cache?
> --
> Tim
>
>
> "Dave Moyle" wrote:
>
>> Here is a link (http://www.eggheadcafe.com/articles/20040613.asp) to a
>> customised persistence mechanism that we implement recently.
>>
>> A number of our customers share 512/128 DSL connections between a number
>> of
>> staff, and the posting back of large viewstates was causing significant
>> performance issues for them.
>>
>> We choose to store the viewstate in a SQL store, and although this incurs
>> an
>> extra database hit, that hit is significantly less than the round trip of
>> a
>> large viewstate to the browser and back.
>>
>>
>> <DIV>"AAOMTim" <(E-Mail Removed)> wrote in
>> message
>> news:3ED1B2CA-1BBD-4870-AEB2-(E-Mail Removed)...</DIV>>I
>> have a large ViewState and I've heard I can save the ViewState in a
>> sesison
>> > object. What are the advantages of doing so and how do I do it? I've
>> > been
>> > told that I am gettign DNS timeouts because of the ViewState being too
>> > large.
>> > I'm trying to avoid writing manual paging routines for now.
>> > --
>> > Tim
>>
>>

Tim,

Cache is a more efficient way of persisting data on the server side. It
exposes many properties that can be used to control the manner in which data
is cached. More than that, if the resources are low, runtime can purge some
of the items that are stored in the cache (which will not happen when session
is used) you can find lots of articles on cache and it's features.

Regards,
Augustin
http://augustinprasanna.blogspot.com

"AAOMTim" wrote:

> Thank you for your response. Can you discuss the merits of saving to a Cache
> object instead of to a Session?
> --
> Tim
>
>
> "Augustin Prasanna" wrote:
>
> > Hi Tim,
> >
> > View State can be customized to be stored in a Session or Cache object. It
> > is done by overriding the 'SavePageStateToPersistenceMedium' and
> > 'LoadPageStateFromPersistenceMedium' methods. (see code snippet below)
> >
> >
> > protected override void SavePageStateToPersistenceMedium(Object viewState)
> > {
> > string _vskey;
> > _vskey = "VIEWSTATE_" + base.Session.SessionID + "_" + Request.RawUrl +
> > "_" + System.DateTime.Now.Ticks.ToString();
> >
> > Cache.Add(_vskey, viewState, null,
> > System.DateTime.Now.AddMinutes(Session.Timeout), Cache.NoSlidingExpiration,
> > CacheItemPriority.Default, null);
> >
> > RegisterHiddenField("_VIEWSTATE_KEY", _vskey);
> > }
> >
> > protected override object LoadPageStateFromPersistenceMedium()
> > {
> > string _vskey = Request.Form["_VIEWSTATE_KEY"];
> >
> > if (_vskey == null)
> > {
> > return null;
> > }
> > else
> > {
> > return Cache[_vskey];
> > }
> > }
> >
> > Advantages: If the ViewState is large, it increases the page size
> > considerably and results in an increase in response time (page load time).
> > Saving the ViewState to a session/cache can result in an improved response
> > time (page size is reduced considerably). On the other hand, it can consume
> > server resources (which can be handled by improving the hardware).
> >
> > Regards,
> > Augustin
> >
> >
> >
> >
> > "AAOMTim" wrote:
> >
> > > I have a large ViewState and I've heard I can save the ViewState in a sesison
> > > object. What are the advantages of doing so and how do I do it? I've been
> > > told that I am gettign DNS timeouts because of the ViewState being too large.
> > > I'm trying to avoid writing manual paging routines for now.
> > > --
> > > Tim