Как уменьшить Платформу Объекта 4 времени компиляции запроса?

Сводка: у нас есть проблемы со временем компиляции запроса EF4 12 + секунды. Кэшируемые запросы только получат нас до сих пор; есть ли какие-либо способы, которыми мы можем на самом деле уменьшить время компиляции? Есть ли что-нибудь, что мы могли бы делать неправильно, мы можем искать?Спасибо!

У нас есть модель EF4, которая выставляется по сервисам WCF. Поскольку каждый наш объект вводит, мы выставляем метод, чтобы выбрать и возвратить целый объект для дисплея / редактирование включая многие дочерние объекты, на которые ссылаются.

Для одного конкретного объекта у нас есть к.Include () 31 таблица / подтаблицы для возврата всех соответствующих данных. К сожалению, это делает компиляцию запроса EF непомерно медленной: это занимает 12-15 секунд для компиляции и создает с 7,800 строками, 300K запрос. Это - бэкенд веб-UI, который должен будет быть более мгновенным, чем это.

Есть ли что-нибудь, что мы можем сделать для улучшения этого? Мы можем CompiledQuery. Скомпилируйте это - который не делает никакой работы до первого использования и так помогает второму и последующему выполнению, но наш клиент возбужден, что первое использование не должно быть медленным также. Так же, если пул приложений IIS, размещающий веб-сервис, будет переработан, то мы потеряем кэшируемый план, хотя мы можем увеличить время жизни для уменьшения этого. Также я не вижу способ предварительно скомпилировать это заранее и / или сериализировать EF скомпилированный кэш запроса (за исключением отражательных приемов). CompiledQuery возражают, только содержит ссылку GUID в кэш, таким образом, это - кэш, о котором мы действительно заботимся. (Пишущий это, мне приходит в голову, что я могу начать что-то в фоновом режиме от app_startup для выполнения всех запросов, чтобы скомпилировать их - который безопасен?)

Однако, даже если мы действительно решаем ту проблему, мы создаем наши поисковые запросы динамично с пунктами LINQ к объектам, на основе которых параметров мы ищем на: Я не думаю, что генератор SQL делает достаточно хорошее задание, что мы можем переместить всю эту логику на уровень SQL, таким образом, я не думаю, что мы можем предварительно скомпилировать наши поисковые запросы. Это менее серьезно, потому что поисковые результаты данных используют меньше таблиц и таким образом, это - компиляция только 3-4 секунд не 12-15, но клиент думает, что все еще действительно не будет приемлемо для конечных пользователей.

Таким образом, мы действительно должны уменьшить время компиляции запроса так или иначе. Какие-либо идеи?

• Профилирование точек к ELinqQueryState. GetExecutionPlan как место для запуска и я попытался ступить в это, но без реальной.NET 4 источника, доступные, я не мог стать очень далеким, и источник, сгенерированный Отражателем, не позволит мне ступить в некоторые функции или установить точки останова в них.
• Проект был обновлен от.NET 3.5, таким образом, я попытался повторно создать EDMX с нуля в EF4 в случае, если было что-то не так с ним кроме этого, не помог.
• Я попробовал утилиту EFProf, рекламируемую здесь, но не похоже, что это помогло бы с этим. Мое выполнение больших запросов разрушает свою программу сбора данных так или иначе.
• Я выполнил сгенерированный запрос посредством настройки производительности sql, и это уже имеет 100%-е индексное использование. Я не вижу ничто плохого с базой данных, которая вызвала бы проблемы с генератором запроса.
• Есть ли что-то, чему O (n^2) в компиляторе плана выполнения - разламывает это на блоки отдельных загрузок данных, а не всех 32 таблиц сразу, вероятно, для помощи? Установка EF к ленивой загрузке не помогла.
• Я купил предварительный выпуск O'Reilly Julie Lerman книга EF4, но я не могу найти, что что-либо там помогает вне 'компиляции Вашим запросам'.

Я не понимаю, почему требуется 12-15 секунд для генерации единственного выбора через 32 таблицы, таким образом, я оптимистичен, что существует некоторый объем для улучшения!

Спасибо за любые предложения! Мы выполняем против SQL Server 2008 в случае, если это имеет значение и XP / 7 / сервер 2 008 использований R2 RTM VS2010.