ASP.NET

Stefan Shakow

• 2.0 Framework assemblies have been NGENed to reduce JIT compilation.  This helps with memory usage when running multiple AppDomains in a single process (multiple applications on a single web server).
• Another new feature new in ASP.NET 2.0 is the AppDomain unloader.  This is configurable by time of inactivity.  If an application is idle for that amount of time, the AppDomain is unloaded to free up memory.  This is configurable in the <hostingEnvironment /> element (idleTimeout setting).  He demonstrated this feature by attaching the EventLog with the health monitoring feature to write an event when the AppDomain unloads.  This feature is great for hosters because it will allow them to serve more customers on a single server (customers who have a small application with light traffic).
• Small assemblies still take up 64k of memory.  Some customers run into problems when loading many, many (hundreds) of small assemblies in a worker process.  This leads to memory waste because there will be unused space lost between assemblies.  This situation is when someone has an application with way too many assemblies.  The real solution is to refactor the solution to collapse code into fewer assemblies, but hosters can’t always compel their customers to do that, so Microsoft is providing a mitigating solution for this scenario. 
• This scenario could also happen with applications that use the App_Code directory many small assemblies are created at runtime.
• SGEN is a new utility to combine assemblies into a fewer number.
• Using Web Application Projects avoid this problem scenario because developer will decide how many assemblies their application needs.
• Large directory structures:  ASP.NET relies on file change notifications.  This can hiccup with large directory structures.  This problem is expanded when the files are on a network share or network-area storage. 
• One thing we can do is change the registry to configure FCN (file-change notifications) to “1”.  This will stop ASP.NET from spamming the network share with FCNs.  A side-effect is that changing the web.config won’t cause an AppDomain recycle automatically.  This is a solution to allowing the application file to be on a network share, but it’s a change to operational behavior.  No longer would the website be recycled, but when changing files, the recycle would have to be done manually.
• For most of us, this problem will never come up, but it does occur with very large directory structures.
• ASP.NET also recycles AppDomains when too many directory changes occur or too many file changes occur.
• Other file-system changes:
• New in ASP.NET 2.0, a directory deletion now causes an app-domain recycle.  Being aware of this can be beneficial if needing to delete directories.
• A workaround for this is to make a directory junction using linkd.  This makes a virtual folder node.  File-change notifications don’t flow over virtual folders, so ASP.NET won’t receive the event, and the app-domain won’t be recycled.
• Asynchronous page processing:  If a page has a long-running task (like calling a web-service of a 3^rd party vendor), the page can set this to run asynchronously.  This releases the current thread back to the threadpool while the long-running call happens.  When the long-running call finishes, the request will grab a thread again and complete.  The allows the thread to be available in the threadpool for other requests when, otherwise, it would be sitting there doing nothing.  This helps application performance on a fewer number of threads.
• Unhandled exception behavior: 
• ASP.NET 1.1 suppressed unhandled exceptions on child threads.
• ASP.NET 2.0:  The process is terminated.  This is a big change.
• If this is a real problem for you:  go to the aspnet.config (in the framework directory) file and set <legacyUnhandledExceptionPolicy enabled=”true” />
• To track down the error, you can trap the unhandled exceptioin event and log what happened before the process shuts down.
• Caching
• ASP.NET sets a limit of cache per process.  This is a problem if you try to shove 1GB of stuff into the cache.  Cache scavenging starts at 90% usage of cache.
• We can use the perf counter to track:  ASP.NET Apps v2.0.50727 – Cache Total Entries.  What might happen is shoving a lot of stuff into the cache, and the system immediately starts to clean it up.  We can also avoid sliding expirations because it can cause stuff to never drop out of the cache.
• Cache limits:  800MB is a normal limit for cache.  As an ASP.NET application is running over many days, virtual memory can become fragmented.  For a 32bit box with 2GB of memory, 800MB is safe for fragmentation.  X64 architecture makes this limit go away.
• You can go into application pool settings for IIS and change the limits.  There is also a new <caching /> config section that can be used.

 [tags: TechEd]