the correct way to profile memory for an ASP.NET application
samvan
Posts: 3
Hi,
I just downloaded the 14 day trial and will begin my first memory profiling tomorrow. I just wanted to know what you suggest as the first step to profile memory usage.
I am thinking about the following and would like some feedback:
1) capture the first snapshot
2) run the site and use it for a while
3) force gc.collect
4) capture the second snapshot
5) compare the snapshots
is there anything wrong with the above steps? Please let me know, thanks!
I just downloaded the 14 day trial and will begin my first memory profiling tomorrow. I just wanted to know what you suggest as the first step to profile memory usage.
I am thinking about the following and would like some feedback:
1) capture the first snapshot
2) run the site and use it for a while
3) force gc.collect
4) capture the second snapshot
5) compare the snapshots
is there anything wrong with the above steps? Please let me know, thanks!
Comments
When you're memory profiling, you really want to see that objects are being freed (garbage collected) when you think they are no longer needed. So take one snapshot after the website loads, do whatever actions on the site you're interested in, and take another snapshot.
In the results, check the 'all classes' tab of the last result set: this is where you can see a count of the instances of each object type. You may also right-click the columns and use the column chooser to add 'new size' and 'removed size' to the panel. These show the changes between the current and previous snapshots and tell you whether the total memory used by those type is going up or down.
Hopefully this explains things a bit.
Thanks a lot. I have a few more questions on interpretation of the result:
Is it correct to assume that if new size = removed size, these objects can be successfully removed by the GC?
I am seeing certain objects' "new size" < "removed size" (8544 v.s. 12672). What does this imply?
I am also seeing DataRow object's "new size" >> "removed size" (1251328 v.s. 215680). Does this mean it is not being cleared by the GC? I didn't Force GC though..
About Total size of all live objects: 15,302,775 bytes.. this means it is about 15MB? (I am seeing a lot more from Task Manager). Does this look right? I used 2 computers to load the pages continuously for about 5 min..
I am storing some objects in ASP.NET's cache. They are probably not gonna be removed by GC until they expire. If so, what should I find on the All Classes panel for these objects I store in Cache?
thanks!
Removed size=the size of all objects that had been removed since the last snapshot
So logically, when new size is less than the removed size, your memory usage for the particular object type is going down. Otherwise it's going up or staying the same.
Note well, you do not need to force Garbage Collection yourself: ANTS Profiler forces a GC for the process before a snapshot is sent, otherwise the results may not be as meaningful. Of course somethimes you have to force GC twice if any objects are in the finalizer queue.
Memory usage reported by ANTS is always less than the total process memory because this memory includes the .NET runtime and other resources. There is a more complete explanationof this.
I was wondering the same thing, can I go somewhere and "see" all of the objects that I have in Cache and how much room different objects occupy. I store lots of things in Cache in my web application and I'd like to know the memory cost of the different classes I'm storing objects of in Cache are.
For the session data, you can work out how much memory you're using in the ANTS Profiler results.
For caching, like when you set it up in your <%Page... directive, I don't think it's possible to see this activity in ANTS Profiler because it's happening in IIS, underneath the managed-code.
If you just want the size and count for the objects cached by IIS, performance counters might be the simplest solution. The Internet Information Services Global object has some cache counters, such as current files cached and current BLOBs cached.