How and why to save ViewState in a session object

[AAOMTim]

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

[Augustin Prasanna]

Hi Tim,

View State can be customized to be stored in a Session or Cache object. It
is done by overriding the 'SavePageStateT oPersistenceMed ium' and
'LoadPageStateF romPersistenceM edium' methods. (see code snippet below)
protected override void SavePageStateTo PersistenceMedi um(Object viewState)
{
string _vskey;
_vskey = "VIEWSTATE_ " + base.Session.Se ssionID + "_" + Request.RawUrl +
"_" + System.DateTime .Now.Ticks.ToSt ring();

Cache.Add(_vske y, viewState, null,
System.DateTime .Now.AddMinutes (Session.Timeou t), Cache.NoSliding Expiration,
CacheItemPriori ty.Default, null);

RegisterHiddenF ield("_VIEWSTAT E_KEY", _vskey);
}

protected override object LoadPageStateFr omPersistenceMe dium()
{
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

[Dave Moyle]

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;AAOM Tim&quot; &lt;AA*****@dis cussions.micros oft.com&gt; wrote in
message news:3E******** *************** ***********@mic rosoft.com...</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

[AAOMTim]

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 'SavePageStateT oPersistenceMed ium' and
'LoadPageStateF romPersistenceM edium' methods. (see code snippet below)
protected override void SavePageStateTo PersistenceMedi um(Object viewState)
{
string _vskey;
_vskey = "VIEWSTATE_ " + base.Session.Se ssionID + "_" + Request.RawUrl +
"_" + System.DateTime .Now.Ticks.ToSt ring();

Cache.Add(_vske y, viewState, null,
System.DateTime .Now.AddMinutes (Session.Timeou t), Cache.NoSliding Expiration,
CacheItemPriori ty.Default, null);

RegisterHiddenF ield("_VIEWSTAT E_KEY", _vskey);
}

protected override object LoadPageStateFr omPersistenceMe dium()
{
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

[AAOMTim]

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 " <AA*****@discus sions.microsoft .comwrote in
message news:3E******** *************** ***********@mic rosoft.com...</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

[Dave Moyle]

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;AAOM Tim&quot; &lt;AA*****@dis cussions.micros oft.com&gt; wrote in
message news:80******** *************** ***********@mic rosoft.com...</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>"AAOMTi m" <AA*****@discus sions.microsoft .comwrote in
message
news:3E******* *************** ************@mi crosoft.com...</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

[Augustin Prasanna]

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 'SavePageStateT oPersistenceMed ium' and
'LoadPageStateF romPersistenceM edium' methods. (see code snippet below)
protected override void SavePageStateTo PersistenceMedi um(Object viewState)
{
string _vskey;
_vskey = "VIEWSTATE_ " + base.Session.Se ssionID + "_" + Request.RawUrl +
"_" + System.DateTime .Now.Ticks.ToSt ring();

Cache.Add(_vske y, viewState, null,
System.DateTime .Now.AddMinutes (Session.Timeou t), Cache.NoSliding Expiration,
CacheItemPriori ty.Default, null);

RegisterHiddenF ield("_VIEWSTAT E_KEY", _vskey);
}

protected override object LoadPageStateFr omPersistenceMe dium()
{
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