Существует ли конкретная проблема с производительностью Entity Framework + GUID PK? - PullRequest
Новая
       39

Существует ли конкретная проблема с производительностью Entity Framework + GUID PK?

0 голосов
/ 19 февраля 2010

В моей компании есть базовая SOA, использующая Entity Framework для доступа к базе данных.Один из наших сервисов должен взаимодействовать с устаревшей базой данных, которая использует uniqueidentifier первичные ключи в базе данных.Производительность хорошая во время модульного и интеграционного тестирования.

Однако под нагрузкой затронутая служба начинает создавать отставание в очереди запросов.Эту очередь можно устранить, удалив разделы кода, которые используют Entity Framework для сопоставления строк с помощью уникального идентификатора PK.Затем служба снова становится производительной, сопоставляя строки по целому числу PK как часть одних и тех же подпрограмм, используя тот же ObjectContext.

Таблица базы данных хорошо выполняет запросы унаследованного приложения, для которого она была разработана.Поэтому я не считаю, что эта проблема связана с фрагментацией в базе данных / индексе.

В показанном примере кода domain представляет собой Entity Framework ObjectContext, MetaSetting относится к отображенному EntityObject и match.ObjectId является Guid. 

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

1 Ответ

2 голосов
/ 19 февраля 2010

Использовать профилировщик

Вы проверили TSQL, отправленный на сервер с помощью Profiler? Намного легче будет выявить любые узкие места TSQL, возникающие при получении данных.

Но, глядя на ваш код, этот простой LINQ должен быть таким же быстродействующим, как прямой вызов БД. EF требует некоторых дополнительных затрат на преобразование, но оно должно быть незначительным, поскольку вы преобразуете одну запись в один экземпляр объекта.

Вы столкнетесь с проблемами при использовании вызовов Include (), поскольку они могут раздувать скрипт TSQL и приводить к его повреждению. У меня были проблемы с ним, когда свойство навигации *: 1 переведено в LEFT OUTER JOIN вместо INNER.

...