How To Enhance ASP.NET Application Responsiveness and Scalability using Garbage Collection Notifications

Introduction 

This article expresses a simple idea of how to enhance web application performance using Garbage Collection notifications. No implementation so far. If anyone will have enough time to implement the approach described below, I will be happy to receive results and feedback.

public static int Main(string[] args){... //method for main ideas 

What is the main problem of all web applications written today using .NET Framework or Java? IMHO, this is Garbage Collection. In order to perform GC, background GC thread needs to suspend all managed threads. And this can take a while, especially on 64-bit platform, where managed heap size can be pretty large. This means longer response time for the application users. You can ask “But what can we do here?”. We can react in a proper way. In .NET Framework 3.5 SP1, there is a new interesting feature – Garbage Collection notifications. More information can be found on MSDN here.

How to react? Let’s consider a typical server scenario with load balancer:

Here we can see several+ servers with load balancer in front. IIS 6 is used in this scenario as the most widely used web server, IMHO, for ASP.NET applications. As is displayed in the image, we can, for instance, subscribe for GC notifications during application startup in Global.asax. Now let’s consider possible solutions depending on the feature set of load balancer.

1. Load balancer can accept notifications from the server nodes. In this case, our approach is rather easy. When GC is about to happen, we notify load balancer with message “Hey, I will be overloaded with GC” and after GC - with “Ok, ready to fire!”. 
2. Time interval, which LB uses for server polling, is bigger, than possible time required for GC. In this case we can implement custom ISAPI filter which each time will be notified about GC. In case of ongoing GC, ISAPI filter can redirect requests back to load balancer, so load balancer can re-schedule its execution on a different server, or return some custom HTTP code which basically will mean the same for properly configured load balancer. The possible problem here is that due to IIS 6 process model, custom ISAPI filter and our ASP.NET application will be hosted in separate processes. This can be easily solved with inter-process communication, memory-mapped files, WinAPI which allows to run particular method/function in particular process, etc. You can ask, why ISAPI, but not HTTP module, for instance. The answer is that during GC, all managed threads are suspended, so we need an unmanaged one to succeed with our mission.
3. Time interval, which LB is used for server polling, is pretty small. In this case, we can configure load balancer to poll custom ISAPI extension. Why not HTTP handler? The answer is the same as in the case of “ISAPI filter vs HTTP module”. Here we’ll also need to communicate between separate processes. Load Balancer will constantly poll our custom ISAPI filter to get known about GCs happening on server side.

Summary

I have described three basic possible approaches. Of course there can be much more sophisticated ones. If you’ll find a better one – please let me know.

History 

• 25^th May, 2009: Initial post