I would like to know the intended behavior of MiniProfiler under concurrent access. There are two parts to this question.
First I’ve noted that on two separate sessions [and even two separate computers], refreshing the page rapidly on one followed immediately by a refresh on the second computer will show results from both sessions. This happened both locally and on data.stackexchange. Is it intended that users see recent data from other sessions that occur near the same time? This implies some shared data structures.
Secondly I’ve discovered an interesting problem I’m looking for advice on in regard to the MS Sql Profiler and concurrent access. This problem is not inherent in MiniProfiler alone, but rather results from a combination of using MiniProfiler with a shared (static) common Enterprise Library Instance. We are currently using the 2.1 version of MiniProfiler, which I realize is old. Before upgrading [everything to MVC 4] I want to try to find out if the fundamental problem will still exist. I’ve observed under moderate concurrent load using WCAT that “zombie” threads occasionally result. These zombie threads are likely to be responsible for run away resource consumption on servers requiring restarts about twice a week on around 2000 web environments. The zombie threads occur on what appears to end up being a corrupted dictionary when SqlTimings are added (SqlTiming ctor). I also realize SqlTiming logic is not thread safe, and using a shared Enterprise Library instance breaks this assumption.
I’d post pictures and data of all of this, but I am a new user and so I am unable. My conclusions may be wrong. The situation that occurs is that CPU sits at a low variance steady state. Usually 12.5% on the first occurrence on our servers with the offending call stack(s) stuck in a dictionary indirectly utilized by the AddSqlTiming class. I am hypothesizing that our shared enterprise library instance is the culprit. This problem was discovered during load testing. Prior to now normal traffic variance was hiding it.
I realize the SqlTiming bits were refactored/removed. Is MiniProfiler thread-safe for concurrent access into the same Ent Lib Database instance in the newest version? If not any innovative solutions that keep a shared instance are appreciated. We had what appeared to be significant performance increases from using a shared EntLib Database instance, but also would like to keep the DB portion of the profiler.