One of my favorite pieces of the Altiris platform is the profiling infrastructure. It all started from a prototype I wrote a couple of years ago, and since we have added so many features that it is hard to mention all of them.

One day a few years ago I got tired of tracking down where various SQL calls originated from using the traditional SQL server profiler. What I wanted was a .Net stack trace displayed next to my SQL statement in the SQL server profiler trace. I also wanted this to work in production to help me isolate performance and other issues in the field.

Luckily, I had introduced a factory pattern a few years earlier for SqlConnection and SqlCommand management, so I had a layer I could intercept using a RealProxy. The concept was, when profiling the database layer returns proxy objects when asked for SqlCommand objects. The proxy objects then have special logic to gather execution statistics and a stack trace, when done they ship the data to another process. The original prototype used remoting to ship the information to another process, the current implementation uses memory mapped files, which are much faster.

Profiling SQL

Say we have the following code:

using (DatabaseContext ctx = DatabaseContext.GetContext())
{
    SqlCommand cmd = (SqlCommand)ctx.CreateCommand("create table #t (id int)");
    cmd.ExecuteNonQuery();
}

When I decide to  profile, the Altiris profiler will show me the following.

The right hand pane shows me the statement that executed and the duration, the left hand pane shows me the .Net stack trace. This makes debugging .Net apps much easier.

Additionally, the Altiris profiler tracks Sql Errors (see the red line in the profiler), transactions, threads and much more.

Profiling Code

After we got the SQL profiling piece built we wanted a mechanism for profiling code in production, the existing profilers at the time relied on ICorProfiler APIs which gets pretty intrusive. Additionally to profile an app you need to restart it. We wanted a system we can turn on and off in production.

The result was our code profiling API, at a high level it allows us to surround code that needs profiling with a using block. The in the profiler app we get duration, stack trace, filtering capabilities and other goodies

So, for the following code:

using (CodeProfiler cp = CodeProfiler.StartProfiling("Test", "Main"))
{
    CreateTable();
    AddRow();
    AddRow();
    ChuckAnError();
    WaitASec();
}

Profiler shows us the following:

I get to see the total duration of this block, stack trace, all child blocks, and … I also get automatic cross correlation with my Sql executions.