Question

I’ve set up mvc-mini-profiler against my Entity Framework-powered MVC 3 site. Everything is duly configured; Starting profiling in Application_Start, ending it in Application_End and so on. The profiling part works just fine.

However, when I try to swap my data model object generation to providing profilable versions, performance slows to a grind. Not every SQL query, but some queries take about 5x the entire page load. (The very first page load after firing up IIS Express takes a bit longer, but this is sustained.)

Negligible time (~2ms tops) is spent querying, executing and “data reading” the SQL, while this line:

var person = dataContext.People.FirstOrDefault(p => p.PersonID == id);

…when wrapped in using(profiler.Step()) is recorded as taking 300-400 ms. I profiled with dotTrace, which confirmed that the time is actually spent in EF as usual (the profilable components do make very brief appearances), only it is taking much longer.

This leads me to believe that the connection or some of its constituent parts are missing sufficient data, making EF perform far worse.

This is what I’m using to make the context object (my edmx model’s class is called DataContext):

var conn = ProfiledDbConnection.Get(
    /* returns an SqlConnection */CreateConnection());
return CreateObjectContext<DataContext>(conn);

I originally used the mvc-mini-profiler provided ObjectContextUtils.CreateObjectContext method. I dove into it and noticed that it set a wildcard metadata workspace path string. Since I have the database layer isolated to one project and several MVC sites as other projects using the code, those paths have changed and I’d rather be more specific. Also, I thought this was the cause of the performance issue. I duplicated the CreateObjectContext functionality into my own project to provide this, as such:

    public static T CreateObjectContext<T>(DbConnection connection) where T : System.Data.Objects.ObjectContext {
        var workspace = new System.Data.Metadata.Edm.MetadataWorkspace(
          GetMetadataPathsString().Split('|'),
          // ^-- returns 
          //  "res://*/Redacted.csdl|res://*/Redacted.ssdl|res://*/Redacted.msl"
          new Assembly[] { typeof(T).Assembly });

        // The remainder of the method is copied straight from the original,
        // and I carried over a duplicate CtorCache too to make this work.
        var factory = DbProviderServices.GetProviderFactory(connection);
        var itemCollection = workspace.GetItemCollection(System.Data.Metadata.Edm.DataSpace.SSpace);
        itemCollection.GetType().GetField("_providerFactory", // <==== big fat ugly hack
            BindingFlags.NonPublic | BindingFlags.Instance).SetValue(itemCollection, factory);
        var ec = new System.Data.EntityClient.EntityConnection(workspace, connection);
        return CtorCache<T, System.Data.EntityClient.EntityConnection>.Ctor(ec);
    }

…but it doesn’t seem to make much of a difference. The problem still exists whether I use the above hacked version that’s more specific with metadata workspace paths or the mvc-mini-profiler provided version. I just thought I’d mention that I’ve tried this too.

Having exhausted all this, I’m at my wits’ end. Once again: when I just provide my data context as usual, no performance is lost. When I provide a “profilable” data context, performance plummets for certain queries (I don’t know what influences this either). What could mvc-mini-profiler do that’s wrong? Am I still feeding it the wrong data?

I think this is the same problem as this person ran into.

Answer 1

I just resolved this issue today.

see: http://code.google.com/p/mvc-mini-profiler/issues/detail?id=43

It happened cause some of our fancy hacks were not cached well enough. In particular:

var workspace = new System.Data.Metadata.Edm.MetadataWorkspace(
     new string[] { "res://*/" },       
     new Assembly[] { typeof(T).Assembly });

Is a very expensive call, so we need to cache the workspace.