L
Larry Epn
I have a web-based application that tries its darndest to work like a windows
form app. It uses lots of objects to retain state across multiple forms, and
all of these complex objects are stored in many session variables whose names
include GUIDs since there are so many of them. In other words, it's a MEMORY
PIG - but it gives the functionality/experience necessary. Also, users tend
to stay in this application for an entire work shift (8-10 hours) and the
session is kept alive via a keep-alive ajax-based timer panel that guarantees
that even if there is no user activity that this keeps the session alive.
All of these session objects are programmatically assigned a timeout duration
at which time they are disposed during a common routine that occasionally
gets triggered.
The problem arises usually late in the day when the memory utilization of
the w3wp.exe process begins banging against that 99% CPU usage, and it stays
there for an eternity. Amazingly, the application continues to function,
albeit noticeably slower. I have gone through with a fine-tooth comb to find
places where I am not disposing or releasing references to these complex
session objects. As much as I may like to think, I obviously haven't found
them all (???)
Is there a way to see specifically why the garbage collector (I ASSUME) is
looping around this memory in a seemingly infinite loop, and then why it
never seems to stop unless I reset the process (and LOSE EVERYONE's SESSION
variables which basically crashes their application - not a good workaround).
I have even attempted to use other session management schemes (SQL and the
session state service), but some of these objects just won't serialize even
though I've attempted to make them serializable (another topic, I guess).
Has anyone else run into this situation? Any ideas?
Thank you,
Larry
form app. It uses lots of objects to retain state across multiple forms, and
all of these complex objects are stored in many session variables whose names
include GUIDs since there are so many of them. In other words, it's a MEMORY
PIG - but it gives the functionality/experience necessary. Also, users tend
to stay in this application for an entire work shift (8-10 hours) and the
session is kept alive via a keep-alive ajax-based timer panel that guarantees
that even if there is no user activity that this keeps the session alive.
All of these session objects are programmatically assigned a timeout duration
at which time they are disposed during a common routine that occasionally
gets triggered.
The problem arises usually late in the day when the memory utilization of
the w3wp.exe process begins banging against that 99% CPU usage, and it stays
there for an eternity. Amazingly, the application continues to function,
albeit noticeably slower. I have gone through with a fine-tooth comb to find
places where I am not disposing or releasing references to these complex
session objects. As much as I may like to think, I obviously haven't found
them all (???)
Is there a way to see specifically why the garbage collector (I ASSUME) is
looping around this memory in a seemingly infinite loop, and then why it
never seems to stop unless I reset the process (and LOSE EVERYONE's SESSION
variables which basically crashes their application - not a good workaround).
I have even attempted to use other session management schemes (SQL and the
session state service), but some of these objects just won't serialize even
though I've attempted to make them serializable (another topic, I guess).
Has anyone else run into this situation? Any ideas?
Thank you,
Larry