aspnet_state.ex e Internals Info Needed

[MattC]

I noticed when storing large amounts of information in the StateServer
Service that this does not increase in size, the worker process itself seems
to grow.

I set up a test case to try and prove this, I placed a button on a web form
that ran the foloowing code.
string temp = "index";

for(int i = 0; i < 1000000; i++)
{
string index = temp + i.ToString();
Session[index] = "This is a Test";
}

I notices that the aspnet_state.ex e's Mem Usage and VM Size barely grew yet
my W3WP process grew to the point that I had to stop my app (yes my own
fault iterating 1M times).

I thought the State Server actually stored the session data itself, it would
seem from my example that this is not the case and that the memory space
used is that of the W3WP.

Does the State Server only act as a marchalling services pointing requests
for Session info to the correct memory location? If this is the case how
does it persist when an ASP.NET app is recycled.

Is that portion of memory allocated to storing the Session held back while
the ASP.NET app is recycled?

I've been trying to find information on how the State Server works
internally but as yet have found nothing.

TIA

MattC

[Karl Seguin]

Matt:
Thanks for asking, I learnt a lot by trying to find the answer. I strongly
suspected that objects didn't immediatly stream to the state server when
added - but instead were held in memory and only streamed to the state
servrer at a certain point. After doing some digging, I found out this is
what's happening. Here's a breakdown:

-Session state is managed by an HttpModule called SessionStateMod ule
-Items are only truly added to their stores during the ReleaseRequestS tate
event, which as per msdn "Occurs after ASP.NET finishes executing all
request handlers. This event causes state modules to save the current state
data"
-Depending on which type of storage you use, different things happen. In
the case of state server, the session information is serilized into memory
(asp.net) and then some stuff taht confused me happened (presumably the
actual storage to the state server)
So, basically all those objects are stored in memory than serialized (in
memory) and sent to state server. As you can see, a lot is happening in the
asp.net memory (w3wp.exe). However, you'd think that after the page is done
loading that memory consumption would go back down. But it probably
doesn't. This is because the garbage collector hasn't passed yet.
Remember, memory won't be reclaimed until its needed. So if you lower your
loop so that it can finish, you'll see the memory go up and stay up. The
memory goes up because initially all the items are help in-memory, it stays
up because the GC hasn't passed yet.

If you change ur code to:
for (int i = 0; i < 800000; i++)
{
string index = "index" + i.ToString();
Session[index] = "This is a Test";
}
GC.Collect();
GC.WaitForPendi ngFinalizers();
GC.Collect();
GC.WaitForPendi ngFinalizers();
GC.Collect();
GC.WaitForPendi ngFinalizers();

you'll hopefully see better results (but even then it isn't
guaranteed)...d on't do anything for a minute or so and you should see it go
back down :)

Also, don't use task manager..instea d load up perfmon and go to .Net
Memory, select "# of bytes in heap" and select the w3wp.exe process...will
give you a much better idea :)

Hope that helped,
Karl
--
MY ASP.Net tutorials
http://www.openmymind.net/
"MattC" <[e-mail]> wrote in message
news:ux******** ******@TK2MSFTN GP10.phx.gbl...

I noticed when storing large amounts of information in the StateServer
Service that this does not increase in size, the worker process itself seems to grow.

I set up a test case to try and prove this, I placed a button on a web form that ran the foloowing code.
string temp = "index";

for(int i = 0; i < 1000000; i++)
{
string index = temp + i.ToString();
Session[index] = "This is a Test";
}

I notices that the aspnet_state.ex e's Mem Usage and VM Size barely grew yet my W3WP process grew to the point that I had to stop my app (yes my own
fault iterating 1M times).

I thought the State Server actually stored the session data itself, it would seem from my example that this is not the case and that the memory space
used is that of the W3WP.

Does the State Server only act as a marchalling services pointing requests
for Session info to the correct memory location? If this is the case how
does it persist when an ASP.NET app is recycled.

Is that portion of memory allocated to storing the Session held back while
the ASP.NET app is recycled?

I've been trying to find information on how the State Server works
internally but as yet have found nothing.

TIA

MattC

[MattC]

Karl,

Excellent, thanks for your response.

1.) Could you post some of the links for the articles you found.

2.) I am having to persist my viewstate into the session, overloading the
SavePageStateTo PersistenceMedi um and
LoadPageStateTo PersistenceMedi um methods. Even after many many requests the
W3WP process doesnt seem to go down and similarly my aspnet_state.ex e doesnt
seem to rise.

Is there any way I can call to have a particular session insertion
serialized immediately?

I suspect that as my CPU is now working to its maximum due to the fact that
it is having to do HTTP compression and serialize/deserialize plus search
for session data it is having trouble finding the time to a.) Serialize to
the state server, b.) Garbage collect the temporary memory allocated in the
worker process.

My server is an old PIII 730 w/256MB Ram, W2K3 Server, IIS6.

Would this fit your theory?

Finally, can I created a method that is wired to the requesthandlers
complete event?

TIA

MattC
"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:OY******** *****@TK2MSFTNG P15.phx.gbl...

Matt:
Thanks for asking, I learnt a lot by trying to find the answer. I
strongly
suspected that objects didn't immediatly stream to the state server when
added - but instead were held in memory and only streamed to the state
servrer at a certain point. After doing some digging, I found out this is
what's happening. Here's a breakdown:

-Session state is managed by an HttpModule called SessionStateMod ule
-Items are only truly added to their stores during the ReleaseRequestS tate
event, which as per msdn "Occurs after ASP.NET finishes executing all
request handlers. This event causes state modules to save the current
state
data"
-Depending on which type of storage you use, different things happen. In
the case of state server, the session information is serilized into memory
(asp.net) and then some stuff taht confused me happened (presumably the
actual storage to the state server)
So, basically all those objects are stored in memory than serialized (in
memory) and sent to state server. As you can see, a lot is happening in
the
asp.net memory (w3wp.exe). However, you'd think that after the page is
done
loading that memory consumption would go back down. But it probably
doesn't. This is because the garbage collector hasn't passed yet.
Remember, memory won't be reclaimed until its needed. So if you lower
your
loop so that it can finish, you'll see the memory go up and stay up. The
memory goes up because initially all the items are help in-memory, it
stays
up because the GC hasn't passed yet.

If you change ur code to:
for (int i = 0; i < 800000; i++)
{
string index = "index" + i.ToString();
Session[index] = "This is a Test";
}
GC.Collect();
GC.WaitForPendi ngFinalizers();
GC.Collect();
GC.WaitForPendi ngFinalizers();
GC.Collect();
GC.WaitForPendi ngFinalizers();

you'll hopefully see better results (but even then it isn't
guaranteed)...d on't do anything for a minute or so and you should see it
go
back down :)

Also, don't use task manager..instea d load up perfmon and go to .Net
Memory, select "# of bytes in heap" and select the w3wp.exe process...will
give you a much better idea :)

Hope that helped,
Karl
--
MY ASP.Net tutorials
http://www.openmymind.net/
"MattC" <[e-mail]> wrote in message
news:ux******** ******@TK2MSFTN GP10.phx.gbl...

I noticed when storing large amounts of information in the StateServer
Service that this does not increase in size, the worker process itself

seems

to grow.

I set up a test case to try and prove this, I placed a button on a web

form

that ran the foloowing code.
string temp = "index";

for(int i = 0; i < 1000000; i++)
{
string index = temp + i.ToString();
Session[index] = "This is a Test";
}

I notices that the aspnet_state.ex e's Mem Usage and VM Size barely grew

yet

my W3WP process grew to the point that I had to stop my app (yes my own
fault iterating 1M times).

I thought the State Server actually stored the session data itself, it

would

seem from my example that this is not the case and that the memory space
used is that of the W3WP.

Does the State Server only act as a marchalling services pointing
requests
for Session info to the correct memory location? If this is the case how
does it persist when an ASP.NET app is recycled.

Is that portion of memory allocated to storing the Session held back
while
the ASP.NET app is recycled?

I've been trying to find information on how the State Server works
internally but as yet have found nothing.

TIA

MattC

[Karl Seguin]

Hey Matt,
Check out http://www.thecodeproject.com/aspnet...nInternals.asp
it's just a starter...and there's no "part 2" as the author promises. Most
of my research came from digging into the .net code with Reflector and
getting an understanding of the internals.

My initial suspicion is still that the GC simply isn't running, but it's
possible that you do ahve a memory leak (managed or not)...you can check out
http://blogs.msdn.com/akhune/archive...11/153734.aspx as a starting
point for this.

Also, I wouldn't/couldn't say that those are the reasons your CPU is maxing
out (certainly if you are looping 1million times per page hit, that might be
worth investigating too ;) ). I've certainly seen HTTP Compression take a
chunk out of CPU cycles...so simply try turning it off and see if it's any
better? Similarly, simply try to turn off the server-side viewstate and
observe the effect. Your box certainly is old and I would simply suspect
that it'll be able to handle a certain load and no more...if you are trying
to run an application where you feel the need to simulate 1million session
entries, you likely need more hardware...

If the basic stuff doen't work (although I'm hoping turning off
HttpCompression for testing will ease the cpu a lot), get a profiler and
take a spin in your code. Ant's profiler is my prefered tool, and comes
with a full 14 day trial:
http://www.red-gate.com/code_profiling.htm

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"MattC" <[e-mail]> wrote in message
news:O8******** ******@TK2MSFTN GP15.phx.gbl...

Karl,

Excellent, thanks for your response.

1.) Could you post some of the links for the articles you found.

2.) I am having to persist my viewstate into the session, overloading the
SavePageStateTo PersistenceMedi um and
LoadPageStateTo PersistenceMedi um methods. Even after many many requests the W3WP process doesnt seem to go down and similarly my aspnet_state.ex e doesnt seem to rise.

Is there any way I can call to have a particular session insertion
serialized immediately?

I suspect that as my CPU is now working to its maximum due to the fact that it is having to do HTTP compression and serialize/deserialize plus search
for session data it is having trouble finding the time to a.) Serialize to
the state server, b.) Garbage collect the temporary memory allocated in the worker process.

My server is an old PIII 730 w/256MB Ram, W2K3 Server, IIS6.

Would this fit your theory?

Finally, can I created a method that is wired to the requesthandlers
complete event?

TIA

MattC
"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:OY******** *****@TK2MSFTNG P15.phx.gbl...

Matt:
Thanks for asking, I learnt a lot by trying to find the answer. I
strongly
suspected that objects didn't immediatly stream to the state server when
added - but instead were held in memory and only streamed to the state
servrer at a certain point. After doing some digging, I found out this is what's happening. Here's a breakdown:

-Session state is managed by an HttpModule called SessionStateMod ule
-Items are only truly added to their stores during the ReleaseRequestS tate event, which as per msdn "Occurs after ASP.NET finishes executing all
request handlers. This event causes state modules to save the current
state
data"
-Depending on which type of storage you use, different things happen. In the case of state server, the session information is serilized into memory (asp.net) and then some stuff taht confused me happened (presumably the
actual storage to the state server)
So, basically all those objects are stored in memory than serialized (in
memory) and sent to state server. As you can see, a lot is happening in
the
asp.net memory (w3wp.exe). However, you'd think that after the page is
done
loading that memory consumption would go back down. But it probably
doesn't. This is because the garbage collector hasn't passed yet.
Remember, memory won't be reclaimed until its needed. So if you lower
your
loop so that it can finish, you'll see the memory go up and stay up. The memory goes up because initially all the items are help in-memory, it
stays
up because the GC hasn't passed yet.

If you change ur code to:
for (int i = 0; i < 800000; i++)
{
string index = "index" + i.ToString();
Session[index] = "This is a Test";
}
GC.Collect();
GC.WaitForPendi ngFinalizers();
GC.Collect();
GC.WaitForPendi ngFinalizers();
GC.Collect();
GC.WaitForPendi ngFinalizers();

you'll hopefully see better results (but even then it isn't
guaranteed)...d on't do anything for a minute or so and you should see it
go
back down :)

Also, don't use task manager..instea d load up perfmon and go to .Net
Memory, select "# of bytes in heap" and select the w3wp.exe process...will give you a much better idea :)

Hope that helped,
Karl
--
MY ASP.Net tutorials
http://www.openmymind.net/
"MattC" <[e-mail]> wrote in message
news:ux******** ******@TK2MSFTN GP10.phx.gbl...

I noticed when storing large amounts of information in the StateServer
Service that this does not increase in size, the worker process itself

seems

to grow.

I set up a test case to try and prove this, I placed a button on a web

form

that ran the foloowing code.
string temp = "index";

for(int i = 0; i < 1000000; i++)
{
string index = temp + i.ToString();
Session[index] = "This is a Test";
}

I notices that the aspnet_state.ex e's Mem Usage and VM Size barely grew

yet

my W3WP process grew to the point that I had to stop my app (yes my own
fault iterating 1M times).

I thought the State Server actually stored the session data itself, it

would

seem from my example that this is not the case and that the memory space used is that of the W3WP.

Does the State Server only act as a marchalling services pointing
requests
for Session info to the correct memory location? If this is the case how does it persist when an ASP.NET app is recycled.

Is that portion of memory allocated to storing the Session held back
while
the ASP.NET app is recycled?

I've been trying to find information on how the State Server works
internally but as yet have found nothing.

TIA

MattC

[Karl Seguin]

Matt:
I can't say I can see anything. Is the LosFormatter really necessary? Your
storing the viewstate in the session i wouldn't expect it to need to be
serlialized...u nless the state server can't automatically serialize it
itself...even if it doesn't, not sure LosFormatter is the quickest (though
it very well could be, I'd check both issues).

I noticed that you aren't properly disposing of your StringWriter... but I
doubt that's your problem...

Anyways, atleast I gave you a couple more things to look at :) sorry I
coudlnt' be more help.

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"MattC" <[e-mail]> wrote in message
news:OH******** ******@TK2MSFTN GP14.phx.gbl...

Karl,

Last night I tried runing with server side viewstate off, indeed the server was fine, the processor was much less under pressure, and the memory usage
was constant. Which means there must be a leak in my viewstate persistance code (below).
My problem is that I have a timesheet data entry page for the application.
Users can make entries for each day, selecting an activity, each activity
requires a different set of boxes, this requires a postback. So they may
have 50/60 postbacks per session. All being persisted to the session.

private string NewViewState
{
get{ return "VIEWSTATE_ "; }
}

private string ViewStateKey
{
get{ return "__VIEWSTATE_KE Y"; }
}

private string UniqueViewState Key
{
get{ return NewViewState + Request.UserHos tAddress + "_" +
Guid.NewGuid(). ToString(); }
}

protected override void SavePageStateTo PersistenceMedi um(object viewState) {
try
{
if(Conquest.Con figurationData. ViewStateStorag e ==
ViewStateStorag e.Session)//if we are implementing our on server viewstate
{
string str = this.UniqueView StateKey;
LosFormatter oLosFormatter = new LosFormatter();
StringWriter oStringWriter = new StringWriter();
oLosFormatter.S erialize(oStrin gWriter, viewState);//serialize viewstate into string writer
oLosFormatter = null;

Session[str] = oStringWriter.T oString(); //store in state server
oStringWriter = null;

RegisterHiddenF ield(ViewStateK ey, str);
RegisterHiddenF ield("__VIEWSTA TE", String.Empty);
}
else
{
base.SavePageSt ateToPersistenc eMedium(viewSta te);
}
}
catch(Exception e)
{
throw new
ConquestExcepti on("Performance Page.SavePageSt ateToPersistenc eMedium Failed", null, e);
}
}

protected override object LoadPageStateFr omPersistenceMe dium()
{
try
{
if(Conquest.Con figurationData. ViewStateStorag e ==
ViewStateStorag e.Session)//if we are implementing our on server viewstate
{
object viewstate = null;//return viewstate
string str = Request.Form[ViewStateKey];
LosFormatter oLosFormatter = new LosFormatter();

if (!str.StartsWit h(NewViewState) ) //check the viewstate exists
{
Conquest.Events .WriteToLog("Fa iled to locate VIEWSTATE KEY: '" + str
+"'");
ViewStatePersis tanceFailure(st r);//failure
}
else//view state does exist
{
try
{
string tmp = Session[str].ToString();//get the serialize viewstate
from session
viewstate = oLosFormatter.D eserialize(tmp) ;//deserialize into object oLosFormatter = null;
}
catch(Exception e)//catch all and handle gracefully
{
Conquest.Events .WriteToLog("Fa iled to Load ViewState from " +
Conquest.Config urationData.Vie wStateStorage.T oString() +
" " +
ConquestExcepti on.HandleConque stException(e), System.Diagnost ics.EventLogEnt r
yType.Informati on);
ViewStatePersis tanceFailure(st r);//Response.Redire ct to homepage
}
}
//return what we got from deserialized viewstate
return viewstate;
}
else //use standard viewstate
{
return base.LoadPageSt ateFromPersiste nceMedium();
}
}
catch(Exception e)
{
throw new
ConquestExcepti on("Performance Page.LoadPageSt ateFromPersiste nceMedium
failed", null, e);
}
}
TIA

MattC
"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

Hey Matt,
Check out http://www.thecodeproject.com/aspnet...nInternals.asp it's just a starter...and there's no "part 2" as the author promises.
Most
of my research came from digging into the .net code with Reflector and
getting an understanding of the internals.

My initial suspicion is still that the GC simply isn't running, but it's
possible that you do ahve a memory leak (managed or not)...you can check
out
http://blogs.msdn.com/akhune/archive...11/153734.aspx as a starting point for this.

Also, I wouldn't/couldn't say that those are the reasons your CPU is
maxing
out (certainly if you are looping 1million times per page hit, that might be
worth investigating too ;) ). I've certainly seen HTTP Compression take a
chunk out of CPU cycles...so simply try turning it off and see if it's any better? Similarly, simply try to turn off the server-side viewstate and
observe the effect. Your box certainly is old and I would simply suspect that it'll be able to handle a certain load and no more...if you are
trying
to run an application where you feel the need to simulate 1million session entries, you likely need more hardware...

If the basic stuff doen't work (although I'm hoping turning off
HttpCompression for testing will ease the cpu a lot), get a profiler and
take a spin in your code. Ant's profiler is my prefered tool, and comes
with a full 14 day trial:
http://www.red-gate.com/code_profiling.htm

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"MattC" <[e-mail]> wrote in message
news:O8******** ******@TK2MSFTN GP15.phx.gbl...

Karl,

Excellent, thanks for your response.

1.) Could you post some of the links for the articles you found.

2.) I am having to persist my viewstate into the session, overloading the SavePageStateTo PersistenceMedi um and
LoadPageStateTo PersistenceMedi um methods. Even after many many requests

the

W3WP process doesnt seem to go down and similarly my aspnet_state.ex e

doesnt

seem to rise.

Is there any way I can call to have a particular session insertion
serialized immediately?

I suspect that as my CPU is now working to its maximum due to the fact

that

it is having to do HTTP compression and serialize/deserialize plus

search for session data it is having trouble finding the time to a.) Serialize
to
the state server, b.) Garbage collect the temporary memory allocated in

the

worker process.

My server is an old PIII 730 w/256MB Ram, W2K3 Server, IIS6.

Would this fit your theory?

Finally, can I created a method that is wired to the requesthandlers
complete event?

TIA

MattC
"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:OY******** *****@TK2MSFTNG P15.phx.gbl...
> Matt:
> Thanks for asking, I learnt a lot by trying to find the answer. I
> strongly
> suspected that objects didn't immediatly stream to the state server
> when
> added - but instead were held in memory and only streamed to the state > servrer at a certain point. After doing some digging, I found out this is

> what's happening. Here's a breakdown:
>
> -Session state is managed by an HttpModule called SessionStateMod ule
> -Items are only truly added to their stores during the

ReleaseRequestS tate

> event, which as per msdn "Occurs after ASP.NET finishes executing all
> request handlers. This event causes state modules to save the current
> state
> data"
> -Depending on which type of storage you use, different things happen.

In

> the case of state server, the session information is serilized into

memory

> (asp.net) and then some stuff taht confused me happened (presumably

the > actual storage to the state server)
>
>
> So, basically all those objects are stored in memory than serialized
> (in
> memory) and sent to state server. As you can see, a lot is happening
> in
> the
> asp.net memory (w3wp.exe). However, you'd think that after the page is > done
> loading that memory consumption would go back down. But it probably
> doesn't. This is because the garbage collector hasn't passed yet.
> Remember, memory won't be reclaimed until its needed. So if you lower > your
> loop so that it can finish, you'll see the memory go up and stay up.

The

> memory goes up because initially all the items are help in-memory, it
> stays
> up because the GC hasn't passed yet.
>
> If you change ur code to:
> for (int i = 0; i < 800000; i++)
> {
> string index = "index" + i.ToString();
> Session[index] = "This is a Test";
> }
> GC.Collect();
> GC.WaitForPendi ngFinalizers();
> GC.Collect();
> GC.WaitForPendi ngFinalizers();
> GC.Collect();
> GC.WaitForPendi ngFinalizers();
>
> you'll hopefully see better results (but even then it isn't
> guaranteed)...d on't do anything for a minute or so and you should see
> it
> go
> back down :)
>
> Also, don't use task manager..instea d load up perfmon and go to .Net
> Memory, select "# of bytes in heap" and select the w3wp.exe

process...will

> give you a much better idea :)
>
> Hope that helped,
> Karl
> --
> MY ASP.Net tutorials
> http://www.openmymind.net/
>
>
> "MattC" <[e-mail]> wrote in message
> news:ux******** ******@TK2MSFTN GP10.phx.gbl...
>> I noticed when storing large amounts of information in the StateServer >> Service that this does not increase in size, the worker process itself > seems
>> to grow.
>>
>> I set up a test case to try and prove this, I placed a button on a web > form
>> that ran the foloowing code.
>> string temp = "index";
>>
>> for(int i = 0; i < 1000000; i++)
>> {
>> string index = temp + i.ToString();
>> Session[index] = "This is a Test";
>> }
>>
>> I notices that the aspnet_state.ex e's Mem Usage and VM Size barely
>> grew
> yet
>> my W3WP process grew to the point that I had to stop my app (yes my
>> own
>> fault iterating 1M times).
>>
>> I thought the State Server actually stored the session data itself, it > would
>> seem from my example that this is not the case and that the memory

space

>> used is that of the W3WP.
>>
>> Does the State Server only act as a marchalling services pointing
>> requests
>> for Session info to the correct memory location? If this is the

case how

>> does it persist when an ASP.NET app is recycled.
>>
>> Is that portion of memory allocated to storing the Session held back
>> while
>> the ASP.NET app is recycled?
>>
>> I've been trying to find information on how the State Server works
>> internally but as yet have found nothing.
>>
>> TIA
>>
>> MattC
>>
>>
>>
>>
>
>

[MattC]

No, you were more than helpful, sometimes having someone else backup your
suspicons is as valuable as an answer.

Thanks a lot.

MattC

"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:uS******** ********@TK2MSF TNGP14.phx.gbl. ..

Matt:
I can't say I can see anything. Is the LosFormatter really necessary?
Your
storing the viewstate in the session i wouldn't expect it to need to be
serlialized...u nless the state server can't automatically serialize it
itself...even if it doesn't, not sure LosFormatter is the quickest (though
it very well could be, I'd check both issues).

I noticed that you aren't properly disposing of your StringWriter... but I
doubt that's your problem...

Anyways, atleast I gave you a couple more things to look at :) sorry I
coudlnt' be more help.

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"MattC" <[e-mail]> wrote in message
news:OH******** ******@TK2MSFTN GP14.phx.gbl...

Karl,

Last night I tried runing with server side viewstate off, indeed the

server

was fine, the processor was much less under pressure, and the memory
usage
was constant. Which means there must be a leak in my viewstate

persistance

code (below).
My problem is that I have a timesheet data entry page for the
application.
Users can make entries for each day, selecting an activity, each activity
requires a different set of boxes, this requires a postback. So they may
have 50/60 postbacks per session. All being persisted to the session.

private string NewViewState
{
get{ return "VIEWSTATE_ "; }
}

private string ViewStateKey
{
get{ return "__VIEWSTATE_KE Y"; }
}

private string UniqueViewState Key
{
get{ return NewViewState + Request.UserHos tAddress + "_" +
Guid.NewGuid(). ToString(); }
}

protected override void SavePageStateTo PersistenceMedi um(object

viewState)

{
try
{
if(Conquest.Con figurationData. ViewStateStorag e ==
ViewStateStorag e.Session)//if we are implementing our on server viewstate
{
string str = this.UniqueView StateKey;
LosFormatter oLosFormatter = new LosFormatter();
StringWriter oStringWriter = new StringWriter();
oLosFormatter.S erialize(oStrin gWriter, viewState);//serialize

viewstate

into string writer
oLosFormatter = null;

Session[str] = oStringWriter.T oString(); //store in state server
oStringWriter = null;

RegisterHiddenF ield(ViewStateK ey, str);
RegisterHiddenF ield("__VIEWSTA TE", String.Empty);
}
else
{
base.SavePageSt ateToPersistenc eMedium(viewSta te);
}
}
catch(Exception e)
{
throw new
ConquestExcepti on("Performance Page.SavePageSt ateToPersistenc eMedium

Failed",

null, e);
}
}

protected override object LoadPageStateFr omPersistenceMe dium()
{
try
{
if(Conquest.Con figurationData. ViewStateStorag e ==
ViewStateStorag e.Session)//if we are implementing our on server viewstate
{
object viewstate = null;//return viewstate
string str = Request.Form[ViewStateKey];
LosFormatter oLosFormatter = new LosFormatter();

if (!str.StartsWit h(NewViewState) ) //check the viewstate exists
{
Conquest.Events .WriteToLog("Fa iled to locate VIEWSTATE KEY: '" +
str
+"'");
ViewStatePersis tanceFailure(st r);//failure
}
else//view state does exist
{
try
{
string tmp = Session[str].ToString();//get the serialize viewstate
from session
viewstate = oLosFormatter.D eserialize(tmp) ;//deserialize into

object

oLosFormatter = null;
}
catch(Exception e)//catch all and handle gracefully
{
Conquest.Events .WriteToLog("Fa iled to Load ViewState from " +
Conquest.Config urationData.Vie wStateStorage.T oString() +
" " +

ConquestExcepti on.HandleConque stException(e), System.Diagnost ics.EventLogEnt r
yType.Informati on);

ViewStatePersis tanceFailure(st r);//Response.Redire ct to homepage
}
}
//return what we got from deserialized viewstate
return viewstate;
}
else //use standard viewstate
{
return base.LoadPageSt ateFromPersiste nceMedium();
}
}
catch(Exception e)
{
throw new
ConquestExcepti on("Performance Page.LoadPageSt ateFromPersiste nceMedium
failed", null, e);
}
}
TIA

MattC
"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:%2******** ********@TK2MSF TNGP15.phx.gbl. ..

> Hey Matt,
> Check out http://www.thecodeproject.com/aspnet...nInternals.asp > it's just a starter...and there's no "part 2" as the author promises.
> Most
> of my research came from digging into the .net code with Reflector and
> getting an understanding of the internals.
>
> My initial suspicion is still that the GC simply isn't running, but
> it's
> possible that you do ahve a memory leak (managed or not)...you can
> check
> out
> http://blogs.msdn.com/akhune/archive...11/153734.aspx as a starting > point for this.
>
> Also, I wouldn't/couldn't say that those are the reasons your CPU is
> maxing
> out (certainly if you are looping 1million times per page hit, that might > be
> worth investigating too ;) ). I've certainly seen HTTP Compression take > a
> chunk out of CPU cycles...so simply try turning it off and see if it's any > better? Similarly, simply try to turn off the server-side viewstate
> and
> observe the effect. Your box certainly is old and I would simply suspect > that it'll be able to handle a certain load and no more...if you are
> trying
> to run an application where you feel the need to simulate 1million session > entries, you likely need more hardware...
>
> If the basic stuff doen't work (although I'm hoping turning off
> HttpCompression for testing will ease the cpu a lot), get a profiler
> and
> take a spin in your code. Ant's profiler is my prefered tool, and
> comes
> with a full 14 day trial:
> http://www.red-gate.com/code_profiling.htm
>
> Karl
>
> --
> MY ASP.Net tutorials
> http://www.openmymind.net/
>
>
> "MattC" <[e-mail]> wrote in message
> news:O8******** ******@TK2MSFTN GP15.phx.gbl...
>> Karl,
>>
>> Excellent, thanks for your response.
>>
>> 1.) Could you post some of the links for the articles you found.
>>
>> 2.) I am having to persist my viewstate into the session, overloading the >> SavePageStateTo PersistenceMedi um and
>> LoadPageStateTo PersistenceMedi um methods. Even after many many requests > the
>> W3WP process doesnt seem to go down and similarly my aspnet_state.ex e
> doesnt
>> seem to rise.
>>
>> Is there any way I can call to have a particular session insertion
>> serialized immediately?
>>
>> I suspect that as my CPU is now working to its maximum due to the fact
> that
>> it is having to do HTTP compression and serialize/deserialize plus search >> for session data it is having trouble finding the time to a.)
>> Serialize
>> to
>> the state server, b.) Garbage collect the temporary memory allocated
>> in
> the
>> worker process.
>>
>> My server is an old PIII 730 w/256MB Ram, W2K3 Server, IIS6.
>>
>> Would this fit your theory?
>>
>> Finally, can I created a method that is wired to the requesthandlers
>> complete event?
>>
>> TIA
>>
>> MattC
>>
>>
>> "Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
>> net>
>> wrote in message news:OY******** *****@TK2MSFTNG P15.phx.gbl...
>> > Matt:
>> > Thanks for asking, I learnt a lot by trying to find the answer. I
>> > strongly
>> > suspected that objects didn't immediatly stream to the state server
>> > when
>> > added - but instead were held in memory and only streamed to the state >> > servrer at a certain point. After doing some digging, I found out this > is
>> > what's happening. Here's a breakdown:
>> >
>> > -Session state is managed by an HttpModule called SessionStateMod ule
>> > -Items are only truly added to their stores during the
> ReleaseRequestS tate
>> > event, which as per msdn "Occurs after ASP.NET finishes executing
>> > all
>> > request handlers. This event causes state modules to save the
>> > current
>> > state
>> > data"
>> > -Depending on which type of storage you use, different things
>> > happen.
> In
>> > the case of state server, the session information is serilized into
> memory
>> > (asp.net) and then some stuff taht confused me happened (presumably the >> > actual storage to the state server)
>> >
>> >
>> > So, basically all those objects are stored in memory than serialized
>> > (in
>> > memory) and sent to state server. As you can see, a lot is
>> > happening
>> > in
>> > the
>> > asp.net memory (w3wp.exe). However, you'd think that after the page is >> > done
>> > loading that memory consumption would go back down. But it probably
>> > doesn't. This is because the garbage collector hasn't passed yet.
>> > Remember, memory won't be reclaimed until its needed. So if you lower >> > your
>> > loop so that it can finish, you'll see the memory go up and stay up.
> The
>> > memory goes up because initially all the items are help in-memory,
>> > it
>> > stays
>> > up because the GC hasn't passed yet.
>> >
>> > If you change ur code to:
>> > for (int i = 0; i < 800000; i++)
>> > {
>> > string index = "index" + i.ToString();
>> > Session[index] = "This is a Test";
>> > }
>> > GC.Collect();
>> > GC.WaitForPendi ngFinalizers();
>> > GC.Collect();
>> > GC.WaitForPendi ngFinalizers();
>> > GC.Collect();
>> > GC.WaitForPendi ngFinalizers();
>> >
>> > you'll hopefully see better results (but even then it isn't
>> > guaranteed)...d on't do anything for a minute or so and you should
>> > see
>> > it
>> > go
>> > back down :)
>> >
>> > Also, don't use task manager..instea d load up perfmon and go to
>> > .Net
>> > Memory, select "# of bytes in heap" and select the w3wp.exe
> process...will
>> > give you a much better idea :)
>> >
>> > Hope that helped,
>> > Karl
>> > --
>> > MY ASP.Net tutorials
>> > http://www.openmymind.net/
>> >
>> >
>> > "MattC" <[e-mail]> wrote in message
>> > news:ux******** ******@TK2MSFTN GP10.phx.gbl...
>> >> I noticed when storing large amounts of information in the StateServer >> >> Service that this does not increase in size, the worker process itself >> > seems
>> >> to grow.
>> >>
>> >> I set up a test case to try and prove this, I placed a button on a web >> > form
>> >> that ran the foloowing code.
>> >> string temp = "index";
>> >>
>> >> for(int i = 0; i < 1000000; i++)
>> >> {
>> >> string index = temp + i.ToString();
>> >> Session[index] = "This is a Test";
>> >> }
>> >>
>> >> I notices that the aspnet_state.ex e's Mem Usage and VM Size barely
>> >> grew
>> > yet
>> >> my W3WP process grew to the point that I had to stop my app (yes my
>> >> own
>> >> fault iterating 1M times).
>> >>
>> >> I thought the State Server actually stored the session data itself, it >> > would
>> >> seem from my example that this is not the case and that the memory
> space
>> >> used is that of the W3WP.
>> >>
>> >> Does the State Server only act as a marchalling services pointing
>> >> requests
>> >> for Session info to the correct memory location? If this is the case > how
>> >> does it persist when an ASP.NET app is recycled.
>> >>
>> >> Is that portion of memory allocated to storing the Session held
>> >> back
>> >> while
>> >> the ASP.NET app is recycled?
>> >>
>> >> I've been trying to find information on how the State Server works
>> >> internally but as yet have found nothing.
>> >>
>> >> TIA
>> >>
>> >> MattC
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>

[MattC]

I've placed a GC.Collect() call when users log out (after Session.Abandon )
to flush any rubbish left over from session viewstate storage, we'll see how
that fairs.

MattC

"MattC" <[e-mail]> wrote in message
news:ux******** ******@TK2MSFTN GP10.phx.gbl...

I noticed when storing large amounts of information in the StateServer
Service that this does not increase in size, the worker process itself
seems to grow.

I set up a test case to try and prove this, I placed a button on a web
form that ran the foloowing code.
string temp = "index";

for(int i = 0; i < 1000000; i++)
{
string index = temp + i.ToString();
Session[index] = "This is a Test";
}

I notices that the aspnet_state.ex e's Mem Usage and VM Size barely grew
yet my W3WP process grew to the point that I had to stop my app (yes my
own fault iterating 1M times).

I thought the State Server actually stored the session data itself, it
would seem from my example that this is not the case and that the memory
space used is that of the W3WP.

Does the State Server only act as a marchalling services pointing requests
for Session info to the correct memory location? If this is the case how
does it persist when an ASP.NET app is recycled.

Is that portion of memory allocated to storing the Session held back while
the ASP.NET app is recycled?

I've been trying to find information on how the State Server works
internally but as yet have found nothing.

TIA

MattC