IIS MVC 4 memory leak error for each connection

Question

I have an AsyncController to do lengthy polls. All this works fine, but a colleague noticed a memory leak on the server that appears with each new connection.

I have created a small query application from this page thousands of times, and I control the memory usage for the IIS process. Each connection increases memory usage, but does not fall completely back when the client disconnects.

After further research, I found that this is still happening, even when I replace my AsyncController with a standard Controller that does nothing but this:

 public class WaitController : Controller { public JsonResult Member(string oauth_token, int service_id, bool busy = false) { return Json(new { ready = false, }, JsonRequestBehavior.AllowGet); } } 

Although it doesn't use that much memory, the behavior looks exactly the same.

I launched the memory profiler to show the difference between 10,000 connections, and there is almost nothing there. Most of the memory is occupied by instances of ExpiresEntry[] from System.Web.Caching or System.Runtime.Caching , however this does not mean anything compared to increasing the memory. I get an IIS workflow.

My question is , IIS does this by design? Perhaps this was highlighted for the connection flows that hang around, in the end, they are needed later? Is this a bug with IIS, ASP.NET or MVC 4?

It was my decision to use the MVAP 4 WebAPI features for this, because we want it to be flexible, supported, forward looking and accessible through AJAX. It also made sense in terms of development, since we created the website in MVC 4 too.

However, a colleague has now raised this as a critical problem with the architecture of the system, since we (in the future) must connect to thousands of clients. He suggests using WCF instead. So, the bonus question - with WCF, do you solve these problems?

Answer 1

There is an article here from an MS field engineer on this subject. May be helpful.

Answer 2

After additional experiments and testing, I found that this, unfortunately, cannot be prevented. This seems to be either a design or a real deep-rooted issue with IIS.

I changed my method to use a lower level: run IHttpAsyncHandler to do the same. I used the HttpHandler custom route for MVC to allow me to use the same URLs as before. The problem still existed, but on a slightly smaller scale.

Then I tried the completely empty IHttpHandler , which simply returns { ready: false } (as my code will do when the timeout occurs). There is no other code in HttpHandler, but the same problem still occurs.

Then I tried the completely empty WCF service, which also returned { ready: false } . Same problem, but on an even smaller scale this time.

As @rusev's answer says :

Memory fragmentation and other natural degradation cannot be avoided, and recycling ensures that applications are cleaned periodically.

This may be causing the problem. I can imagine that since there is more overhead when using the MVC controller, fragmentation is faster. Using lower-level methods, such as the HttpHandler or WCF service, will use less memory for each connection, hence there will be less fragmentation.