Сайт перепрограммирования производительности в MVC3 с Entity Framework

Question

На данный момент у меня довольно большой веб-сайт с примерно 10 000 посетителей в день.

Это сайт сообщества с новостями / блогами / видео и большим форумом.

Все это работает на самодельном приложении PHP5, производительность которого очень хорошая, имеет хорошую производительность.База данных - это база данных MySQL5.1.

Теперь я нахожусь в питании с PHP и свободно набранной структурой, отсутствием пространства имен и правильной настройкой MVC, поэтому я думаю о переписывании сайта в MVC3 ASP.NET..

Теперь у меня есть опыт работы с этим, но еще не в рамках MVC, и у меня есть несколько вопросов по поводу производительности, особенно Entity Framework: Стоит ли вообще использовать Entity Framework?Это будет стоить много накладных расходов и снижения производительности?Я пока не уверен, стоит ли переходить на MSSQL.

Answer 1

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

Здесь - это хорошая диаграмма с некоторыми оценками от команды Microsoft, которая может послужить основой для принятия решения. Как вы можете видеть, с .NET 4.0 до 4.5 произошел резкий скачок производительности в том, что касается «LINQ to Entities». Это все еще кажется в два раза медленнее, чем прямой SQL. Конечно, LINQ to SQL - самая медленная операция.

ASP.NET MVC - хорошее направление, особенно если вы хотите попробовать что-то другое. EF - не лучшее, что вы можете сделать, если стремитесь к производительности. Написание бизнес-уровня самостоятельно, включая хранимые процедуры SQL, было бы лучше, но потребовало бы намного больше времени.

Answer 2

При использовании ORM, например EF или NHibernate , вам всегда приходится идти на компромисс между производительностью и удобством.Если вы можете жить с относительно плохой производительностью (я думаю, что ваш сайт может быть запущен с ORM) NHibernate, если вы выберете ваш первый выбор, с моей точки зрения, он более зрелый, в то время как EF все еще не хватает поддержки провайдера и у него есть некоторыенедостатки в отношении рабочего процесса develevopment (который вы, вероятно, ожидаете при использовании NHibernate, но не при использовании инструмента MS).

Если вы переключаетесь с PHP на .NET, вам следует подумать о переходе с MySQL на MSSQL только потому, что онидеально вписывается в экосистему MS (и производительность / масштабируемость также должны быть улучшены, это может перевесить снижение производительности, которое вы испытываете при использовании ERM).

Вы также можете взглянуть на LINQ, который может быть альтернативоймежду классической ORM и жестко запрограммированными командами SQL (также в отношении производительности LINQ to SQL довольно быстро , и вы также можете использовать LINQ to Entitiy Framework при использовании EF (это довольно медленно)).LINQ будет соответствовать вашим потребностям, если вы хотите некоторый уровень абстракции без необходимости бесконечной конфигурации и если вам нравится RAD (а кому нет?).

В целом производительность ASP.NET MVC3 довольно хорошая,но вы должны знать, что вам нужен опыт, чтобы настроить приложение и избежать (распространенных) ошибок.Короче говоря, вы должны легко написать приложение ASP.NET, которое будет иметь лучшую производительность, чем PHP-страница со скриптом (по замыслу)

Но вы также должны знать, решите ли вы взять на себя обязательствадля экосистемы MS (.NET, MSSQL w / LINQ / EF) ее сложно выделить, и поставщики для LINQ и EF для СУБД не-MS могут стоить несколько долларов (см. www.devart.com ).

Надеюсь, что это дает вам некоторые рекомендации

---

Дополнительная информация:

• Войны ORM: сравнение nHibernate, LINQ To SQL и Entity Framework
• NHibernate против Entity Framework: тест производительности
• NHibernate против Entity Framework 4.0

Answer 3

Это слишком много общего вопроса, и нет хорошего ответа на него. Я очень рекомендую вам выполнить некоторые тесты с использованием Entity Framework, а также MVC3 и убедиться, что он соответствует вашим потребностям.

Кроме того, и не для того, чтобы быть снисходительным, но 10 000 посетителей в день - это не так много по сравнению с другими сайтами, на которых успешно работают ASP.NET MVC и Entity Framework.

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

Answer 4

Это на 100% зависит от запросов.

Я работал на сайтах с 22 миллионами в месяц с Nhibernate и около 10 миллионов в месяц с Linq to Sql.

Запросы, которые выполняли самые медленные запросы, всегда были такими странными монстрами с совокупным пятикратным объединением. ОРМ дают вам 95% пути. Остальное вам придется оптимизировать. ORM не получает SELECT * FROM из таблицы неправильно. Это выбросы, которые имеют значение.

Answer 5

Это, вероятно, будет закрыто как субъективное / аргументированное в течение следующих пяти минут, но я сделаю попытку:

Вы услышите много разных мнений относительно EF и других ORM, но мойличное мнение состоит в том, что они вызывают больше проблем, чем решают.Запросы должны храниться в базе данных, где они принадлежат.Правильное разделение задач (код SQL в базе данных, код приложения в проекте) избавляет вас от многих проблем в долгосрочной перспективе.

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

Итак, пропустите EF, сосредоточитесь на том, что вы знаете.