views:

90

answers:

1

My company has a basic SOA, using Entity Framework for database access. One of our services must interface with a legacy database which uses uniqueidentifier primary keys in the database. Performance is good during unit and integration testing.

However, under load, the affected service starts to produce a backlog of queued requests. This queue can be eliminated by removing the code sections which use Entity Framework to match rows by uniqueidentifier PK. The service then becomes performant again, matching rows by integer PK as part of the same routines, using the same ObjectContext.

The database table performs well being queried by the legacy application which it was designed for. I therefore do not believe this problem to be related to fragmentation within the database/index.

In the code sample shown, domain is an Entity Framework ObjectContext, MetaSetting relates to the mapped EntityObject and match.ObjectId is a Guid.

metaSettings = domain.MetaSetting.Where(
    ms => ms.AppUID.Equals(match.ObjectId)  
).ToList();
+2  A: 

Use Profiler

Have you checked TSQL sent to the server using Profiler? It will be much easier to pinpoint any TSQL bottlenecks that happen while getting data.

But looking at your code this simple LINQ should be just as performant as a direct call to the DB. There is some overhead by EF though to do the transformation but it should be minor since you're transforming a single record to a single object instance.

You will run into problems when using Include() calls, because those may bloat TSQL script and cripple it down. I've had issues with it when a *:1 navigation property translated to LEFT OUTER JOIN instead of an INNER one.

Robert Koritnik
Thanks for the suggestion. However, this appears to be a strange issue regarding re-releasing request threads back to the thread pool upon completion of the request. For some reason, EF seems to not let go of the thread easily if I use a uniqeidentifier key. Very weird.
goofballLogic