Entity Framework 4.1 против корпоративного блока данных приложений Максимальная производительность

Question

Проблема: я хочу использовать EF4.1 без компромиссов со скоростью и надежностью Корпоративной библиотеки Блок доступа к данным, который я знаю и которому доверяю.

Благодаря множеству ссылок Stackoverflow и блогов о настройке производительности EF, я публикую этот способ, среди многих, использовать EF4.1, который соответствует производительности блока доступа к данным ADO / Enterprise Lib (SqlDataReader).

Проект: 1. Нет ссылок на сущности / динамический sql. Я люблю linq, я просто пытаюсь использовать его против объектов в основном. 2. 100% хранимых процедур и без отслеживания, без слияния и, самое главное, никогда не вызывайте .SaveChanges (). Я просто вызываю метод вставки / обновления / удаления DbContext.StoredProcName (params). На данный момент мы исключили несколько элементов быстрой разработки EF, но мне достаточно способа, которым он автоматически создает сложный тип для вашего хранимого процесса.

GetString и подобные методы - это AbstractMapper, который просто проходит ожидаемые типы и преобразует источник данных в тип.

Так что, насколько мне известно, это показатель, который нужно побить. Было бы трудно принять что-то, что я знаю медленнее.

Это МЕДЛЕННО !!! Намного медленнее!

Это больше похоже на это !! Performance Pie Исходя из моих результатов, диаграмма производительности должна увеличить накладные расходы на отслеживание более чем на 1%. Я попытался предварительно скомпилировать представления, и ничто не получило такой большой импульс, как отсутствие отслеживания! Зачем?? Может быть, кто-то может вмешаться в это.

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

Я использую EF для автоматической генерации хранимых процедур, и я использовал Linq для Edmx , чтобы автоматически импортировать все эти узлы функции edmx для сопоставления с сущностями. Затем я автоматически создаю репозиторий для каждой сущности и движка.

Поскольку я никогда не вызываю SaveChanges, я не удосужился потратить время на отображение сохраненных процедур в конструкторе. Это занимает слишком много времени, и это легко сломать и не знать. Поэтому я просто вызываю процы из контекста.

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

Спасибо!

Answer 1

Несколько замечаний:

Пирог производительности На основании моих результатов, что пирог производительности должен увеличить накладные расходы на отслеживание более чем на 1%, я пытался предварительно компиляция взглядов, и ничто не получило такой большой импульс, как отслеживание Почему ??

Сообщение в блоге написано в 2008 году и, следовательно, основано на версии 1 EF и EntityObject производных сущностях. С EF 4.1 вы используете POCO. Отслеживание изменений ведет себя совершенно иначе с POCO. Особенно, когда объект POCO загружается из базы данных в контекст объекта. Entity Framework создает моментальный снимок исходных значений свойств и сохраняет их в контексте. Отслеживание изменений основано на сравнении текущих значений сущностей и исходных значений Snapshop. Создание этого снимка очевидно дорого с точки зрения производительности и потребления памяти. Мои наблюдения состоят в том, что он стоит как минимум 50 процентов (время запроса без отслеживания изменений - это половина времени запроса с отслеживания изменений). Вы, кажется, измерили еще большее влияние.

Проект: 1. Нет ссылок на сущности / динамический sql. Я люблю linq, я просто попробуйте использовать его против объектов в основном. 2. 100% хранимых процедур и нет отслеживание, без слияния и, самое главное, никогда не вызывайте .SaveChanges (). я просто позвоните по процедуре вставки / обновления / удаления DbContext.StoredProcName (PARAMS). На данный момент мы устранили некоторые из быстрых элементов разработки EF, но как он автоматически создает мне достаточно сложного типа для вашего хранимого процесса.

Для меня это выглядит так, будто вы игнорируете, по сути, некоторые из основных функций, почему существует Entity Framework, и сомнительно, почему вы вообще хотите использовать EF для своих целей. Если ваша главная цель - иметь инструмент, который поможет материализовать результаты запроса в сложные объекты, вы можете взглянуть на Dapper , который фокусируется на этой задаче с учетом высокой производительности. (Dapper - это базовая ORM, используемая здесь в Stackoverflow.)

Несколько дней назад здесь был вопрос с отличными ответами о производительности EF. Теперь оно перенесено в «Программисты»:

https://softwareengineering.stackexchange.com/questions/117357/is-entity-framework-suitable-for-high-traffic-websites