Filtering ASP.NET data

[pbz]

I have a web application that I'm trying to profile, but since I got so much data, and I'm completely new to profiling, I decided to start off with a blank project.

So, if I profile a blank project (nothing but the bare bone stuff VS puts in)
1) Start default.aspx
2) Take a snapshot
3) Refresh again
4) Take another snapshot

When I'm looking at new or removed instances I get quite a bit of "stuff". Is there a description somewhere that would explain what all that is and why it's there? How can I filter that stuff out, since there's not much I can do about it? Or can I? Is this because of .NET caching, any way to disable it?

I'm lost in all the data that comes back and don't have the experience to tell what's normal and what's not.

Thanks.

[Andreas Suurkuusk]

The ASP.NET Framework will cause a lot of instances to be created when an ASP.NET page is requested. If you only profile an empty ASP.NET page, there not much you can do with the information presented (except to get a feel for how classes are used by ASP.NET).

Some things you can look for when analyzing snapshots are:

• Focus first on your own types (e.g. by filtering on Namespace). It's easier to notice that a new instance is unexpected if it's your own class, rather than a framework class.
• Look for classes whose instance count increases (Delta instances > 0). Note that type loading, caching, and other things might cause new instances to be created, but this should stabilize quickly if you perform the same action repeatedly (e.g. requesting the same page). Below I have provided some additional information about caching.
• To optimize memory usage and performance, you can also look at classes with a high amount of Live bytes and Allocs/sec.
• Use the dispose tracker to get information about Disposed and Undisposed instances. Disposed instances often indicates a memory leak, and undisposed instances might indiciate bad resource and memory usage.

To find out whether new instances are kept alive by caching, you need to investigate the root paths of the instances.

Both the session state and the data caching are stored using the same mechanism, i.e. as CacheEntries in a Hashtable. But whereas the cached data is stored directly in a CacheEntry instance, the session state is stored in a session state instance (e.g an instance of InProcSessionState) which in turn is stored in a CacheEntry.

The root path below shows what a root path might look like for a cached application data instance. The thing to note in this root path is that the first instance in the root path is a CacheEntry.

System.Web.Caching.CacheEntry #19,182
System.Collections.Hashtable.bucket[] #4,483
System.Collections.Hashtable #4,476
System.Web.Caching.CacheSingle #4,474
System.Web.Caching.CacheSingle[] #4,473
System.Web.Caching.CacheMultiple #4,086
System.Web.HttpRuntime #4,101
System.Web.HttpRuntime _theRuntime

In the root path below the InProcSessionState instance (#19,158) indicates that the data is stored in the session data

System.Collections.Specialized.NameObjectCollectionBase.NameObjectEntry #19,128
System.Object[] #19,191
System.Collections.ArrayList #19,121
System.Web.SessionState.SessionStateItemCollection #19,124
System.Web.SessionState.InProcSessionState #19,158
System.Web.Caching.CacheEntry #4,487
System.Collections.Hashtable.bucket[] #4,483
System.Collections.Hashtable #4,476
System.Web.Caching.CacheSingle #4,474
System.Web.Caching.CacheSingle[] #4,473
System.Web.Caching.CacheMultiple #4,086
System.Web.HttpRuntime #4,101
System.Web.HttpRuntime _theRuntimeBest regards,

To investigate whether the memory usage is caused by the session state or caching, you can try to do the following:

1. In the main Types view, locate a Type that has a significant amount of new instances.
2. Double click this Type and select the "Shortest root paths" page.
3. Sort the root paths by New live instances or New live bytes.
4. If a root path contains the CacheEntry class, then the instances are held by a session state or a cache.
5. If the root path contains the InProcSessionState class (or some other SessionState class), then the instances are held by a session state.

To investigate specific instances, click the "Select instances" button and the double-click one of the selected instances.

I hope this gives you some guidance on how to identify instances that are part of a session state or a cache.