470,590 Members | 2,556 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,590 developers. It's quick & easy.

aspnet_state.exe Internals Info Needed

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.exe'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


Nov 19 '05 #1
6 3443
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 SessionStateModule
-Items are only truly added to their stores during the ReleaseRequestState
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.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();

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

Also, don't use task manager..instead 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" <m@m.com> wrote in message
news:ux**************@TK2MSFTNGP10.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.exe'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

Nov 19 '05 #2
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
SavePageStateToPersistenceMedium and
LoadPageStateToPersistenceMedium methods. Even after many many requests the
W3WP process doesnt seem to go down and similarly my aspnet_state.exe 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*************@TK2MSFTNGP15.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 SessionStateModule
-Items are only truly added to their stores during the ReleaseRequestState
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.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();

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

Also, don't use task manager..instead 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" <m@m.com> wrote in message
news:ux**************@TK2MSFTNGP10.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.exe'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


Nov 19 '05 #3
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" <m@m.com> wrote in message
news:O8**************@TK2MSFTNGP15.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
SavePageStateToPersistenceMedium and
LoadPageStateToPersistenceMedium methods. Even after many many requests the W3WP process doesnt seem to go down and similarly my aspnet_state.exe 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*************@TK2MSFTNGP15.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 SessionStateModule
-Items are only truly added to their stores during the ReleaseRequestState 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.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();

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

Also, don't use task manager..instead 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" <m@m.com> wrote in message
news:ux**************@TK2MSFTNGP10.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.exe'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



Nov 19 '05 #4
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...unless 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" <m@m.com> wrote in message
news:OH**************@TK2MSFTNGP14.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_KEY"; }
}

private string UniqueViewStateKey
{
get{ return NewViewState + Request.UserHostAddress + "_" +
Guid.NewGuid().ToString(); }
}

protected override void SavePageStateToPersistenceMedium(object viewState) {
try
{
if(Conquest.ConfigurationData.ViewStateStorage ==
ViewStateStorage.Session)//if we are implementing our on server viewstate
{
string str = this.UniqueViewStateKey;
LosFormatter oLosFormatter = new LosFormatter();
StringWriter oStringWriter = new StringWriter();
oLosFormatter.Serialize(oStringWriter, viewState);//serialize viewstate into string writer
oLosFormatter = null;

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

RegisterHiddenField(ViewStateKey, str);
RegisterHiddenField("__VIEWSTATE", String.Empty);
}
else
{
base.SavePageStateToPersistenceMedium(viewState);
}
}
catch(Exception e)
{
throw new
ConquestException("PerformancePage.SavePageStateTo PersistenceMedium Failed", null, e);
}
}

protected override object LoadPageStateFromPersistenceMedium()
{
try
{
if(Conquest.ConfigurationData.ViewStateStorage ==
ViewStateStorage.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.StartsWith(NewViewState)) //check the viewstate exists
{
Conquest.Events.WriteToLog("Failed to locate VIEWSTATE KEY: '" + str
+"'");
ViewStatePersistanceFailure(str);//failure
}
else//view state does exist
{
try
{
string tmp = Session[str].ToString();//get the serialize viewstate
from session
viewstate = oLosFormatter.Deserialize(tmp);//deserialize into object oLosFormatter = null;
}
catch(Exception e)//catch all and handle gracefully
{
Conquest.Events.WriteToLog("Failed to Load ViewState from " +
Conquest.ConfigurationData.ViewStateStorage.ToStri ng() +
" " +
ConquestException.HandleConquestException(e),Syste m.Diagnostics.EventLogEntr
yType.Information);
ViewStatePersistanceFailure(str);//Response.Redirect to homepage
}
}
//return what we got from deserialized viewstate
return viewstate;
}
else //use standard viewstate
{
return base.LoadPageStateFromPersistenceMedium();
}
}
catch(Exception e)
{
throw new
ConquestException("PerformancePage.LoadPageStateFr omPersistenceMedium
failed", null, e);
}
}
TIA

MattC
"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:%2****************@TK2MSFTNGP15.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" <m@m.com> wrote in message
news:O8**************@TK2MSFTNGP15.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 SavePageStateToPersistenceMedium and
LoadPageStateToPersistenceMedium methods. Even after many many requests
the
W3WP process doesnt seem to go down and similarly my aspnet_state.exe

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*************@TK2MSFTNGP15.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 SessionStateModule
> -Items are only truly added to their stores during the

ReleaseRequestState
> 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.WaitForPendingFinalizers();
> GC.Collect();
> GC.WaitForPendingFinalizers();
> GC.Collect();
> GC.WaitForPendingFinalizers();
>
> you'll hopefully see better results (but even then it isn't
> guaranteed)...don't do anything for a minute or so and you should see
> it
> go
> back down :)
>
> Also, don't use task manager..instead 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" <m@m.com> wrote in message
> news:ux**************@TK2MSFTNGP10.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.exe'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
>>
>>
>>
>>
>
>



Nov 19 '05 #5
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****************@TK2MSFTNGP14.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...unless 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" <m@m.com> wrote in message
news:OH**************@TK2MSFTNGP14.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_KEY"; }
}

private string UniqueViewStateKey
{
get{ return NewViewState + Request.UserHostAddress + "_" +
Guid.NewGuid().ToString(); }
}

protected override void SavePageStateToPersistenceMedium(object

viewState)
{
try
{
if(Conquest.ConfigurationData.ViewStateStorage ==
ViewStateStorage.Session)//if we are implementing our on server viewstate
{
string str = this.UniqueViewStateKey;
LosFormatter oLosFormatter = new LosFormatter();
StringWriter oStringWriter = new StringWriter();
oLosFormatter.Serialize(oStringWriter, viewState);//serialize

viewstate
into string writer
oLosFormatter = null;

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

RegisterHiddenField(ViewStateKey, str);
RegisterHiddenField("__VIEWSTATE", String.Empty);
}
else
{
base.SavePageStateToPersistenceMedium(viewState);
}
}
catch(Exception e)
{
throw new
ConquestException("PerformancePage.SavePageStateTo PersistenceMedium

Failed",
null, e);
}
}

protected override object LoadPageStateFromPersistenceMedium()
{
try
{
if(Conquest.ConfigurationData.ViewStateStorage ==
ViewStateStorage.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.StartsWith(NewViewState)) //check the viewstate exists
{
Conquest.Events.WriteToLog("Failed to locate VIEWSTATE KEY: '" +
str
+"'");
ViewStatePersistanceFailure(str);//failure
}
else//view state does exist
{
try
{
string tmp = Session[str].ToString();//get the serialize viewstate
from session
viewstate = oLosFormatter.Deserialize(tmp);//deserialize into

object
oLosFormatter = null;
}
catch(Exception e)//catch all and handle gracefully
{
Conquest.Events.WriteToLog("Failed to Load ViewState from " +
Conquest.ConfigurationData.ViewStateStorage.ToStri ng() +
" " +

ConquestException.HandleConquestException(e),Syste m.Diagnostics.EventLogEntr
yType.Information);

ViewStatePersistanceFailure(str);//Response.Redirect to homepage
}
}
//return what we got from deserialized viewstate
return viewstate;
}
else //use standard viewstate
{
return base.LoadPageStateFromPersistenceMedium();
}
}
catch(Exception e)
{
throw new
ConquestException("PerformancePage.LoadPageStateFr omPersistenceMedium
failed", null, e);
}
}
TIA

MattC
"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:%2****************@TK2MSFTNGP15.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" <m@m.com> wrote in message
> news:O8**************@TK2MSFTNGP15.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 >> SavePageStateToPersistenceMedium and
>> LoadPageStateToPersistenceMedium methods. Even after many many requests > the
>> W3WP process doesnt seem to go down and similarly my aspnet_state.exe
> 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*************@TK2MSFTNGP15.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 SessionStateModule
>> > -Items are only truly added to their stores during the
> ReleaseRequestState
>> > 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.WaitForPendingFinalizers();
>> > GC.Collect();
>> > GC.WaitForPendingFinalizers();
>> > GC.Collect();
>> > GC.WaitForPendingFinalizers();
>> >
>> > you'll hopefully see better results (but even then it isn't
>> > guaranteed)...don't do anything for a minute or so and you should
>> > see
>> > it
>> > go
>> > back down :)
>> >
>> > Also, don't use task manager..instead 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" <m@m.com> wrote in message
>> > news:ux**************@TK2MSFTNGP10.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.exe'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
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>
>



Nov 19 '05 #6
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" <m@m.com> wrote in message
news:ux**************@TK2MSFTNGP10.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.exe'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

Nov 19 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by | last post: by
3 posts views Thread by Eric Barr | last post: by
2 posts views Thread by atef shehata | last post: by
reply views Thread by MattC | last post: by
1 post views Thread by llevi | last post: by
2 posts views Thread by Mehdi | last post: by
reply views Thread by Andrew Morton | last post: by
reply views Thread by Mr. Monk Goo | last post: by
8 posts views Thread by Grizlyk | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.