It turned out that I ran out of connections in my database connection pool which caused every additional request to run into a timeout. The timeout manifested itself as an exception that was thrown by the ADO.NET Driver after waiting 90 seconds for a free connection from the connection pool. The following PurePath shows a request that ran into the timeout:

 

ADO.NET Driver throws a timeout exception after 90 seconds because no connection was available from the pool

Tracking down the .NET resource problem

In order to analyze this problem I created an extended memory dump that allowed me to see all objects on the heap including the references to other objects. With that information I started looking for my connection objects which were obviously leaking as I couldn’t get any additional connections from the connection pool.

Shows all 55 Connection Objects on Heap

From this view I can either analyze the reference tree of a single instance of my Connection object or I can get an aggregated overview of the reference tree of all instances.

Reference Tree of Connection Object shows who is referencing the object

The reference tree showed me that 55 instances of my DBConnection class held all the references to the Connection – which was not suprising. It was however surprising that some of my DBConnection objects were referenced by the ASP.NET Session State (so somebody put in the object in the Session State object) and others (the majority) were referenced by my business class implementation.
The business class implements Web Services that requires an ASP.NET Session. So - for every session that was opened the .NET Framework created a business class instance. Each business class instance opened a connection at the beginning and didn’t close it till the object was disposed – which was when the session expired.

Conclusion

My implementation basically required one open database connection per active session – which is of course a stupid thing to do – but – things often seem more logical after you identified a problem than when you actually create the problem.

Using dynaTrace’s capabilities to analyze objects on the heap – including the complete reference tree allowed me to track down the resource problem that I had.

Related posts:

1. Memory Leak in EntityDataSource when controlling lifetime of your ObjectContext The EntityDataSource is a control you can use on your...
2. Demystify encrypted ASP.NET Web Resource Requests Web Resources have been introduced in ASP.NET 2.0. You can...
3. VS2010 Load Testing for Distributed and Heterogeneous Applications powered by dynaTrace Visual Studio 2010 is almost here – Microsoft just released...
4. Performance Antipatterns in AJAX Applications Several years ago JavaScript was seen as a „playground“ due...
5. Performance Considerations in Distributed Applications Distribution and communication between applications and services is a central...