ASP.NET MVC и EF Code Первое использование памяти

Question

У меня есть приложение, встроенное в ASP.NET MVC 3, которое использует SQL CE для хранения и EF CTP 5 для доступа к данным.

Я развернул этот сайт только на общем хосте, чтобы убедиться, что онпостоянно перерабатываются, поскольку достигают предела в 100 МБ, установленного для их (выделенных) пулов приложений.

Сайт при работе в режиме выпуска использует около 110 МБ ОЗУ.

Я пытался использовать SQLServer Express, а не CE, и это мало что изменило.

Единственное существенное отличие состоит в том, что я полностью удалил EF (используя поддельное репо).Это снизило использование памяти между 30 МБ-40 МБ.Пустой шаблон MVC использует около 20 МБ, так что я подумал, что это не так уж плохо?

Есть ли какие-либо тесты для "стандартных" приложений ASP.NET MVC?

Было бы хорошо узнать, какое использование памяти получают другие пользователи EF CTP, а также несколько советов по инструментам для профилирования памяти (желательно бесплатных).

Стоит упомянуть, как я работаювремя жизни EF ObjectContext.Я использую сеанс для каждого запроса и создаю экземпляр ObjectContext с использованием StructureMap:

For<IDbContext>().HttpContextScoped().Use(ctx => new MyContext("MyConnStringName"));

Большое спасибо, Бен

Answer 1

Нам удалось значительно сократить объем используемой памяти.Рабочий процесс IIS теперь занимает около 50 МБ по сравнению с 100 + МБ ранее.

Ниже приведены некоторые из полезных нам вещей:

• Проверьте основы.Убедитесь, что вы компилируете в режиме выпуска и установите для отладки компиляции значение false в web.config.Такие вещи легко забыть.
• Используйте символы DEBUG для диагностического кода.Примером этого может быть использование таких инструментов, как NHProf (да, я был пойман на этом раньше).Проще всего заключить такой код в директиву DEIFUG, чтобы убедиться, что он не скомпилирован в выпуск вашего приложения.
• Не забывайте о SQL.ORM упрощают игнорирование того, как ваше приложение взаимодействует с вашей базой данных.Использование SQL Profiler или таких инструментов, как EFProf / NHProf, может точно показать, что происходит.В случае EF вы, вероятно, почувствуете себя немного плохо после этого, особенно если вы используете ленивую нагрузку.Как только вы справитесь с этим, вы можете начать оптимизацию (см. Пункт ниже).
• Ленивая загрузка удобна, но ее не следует использовать в представлениях MVC (IMO).Это было одной из основных причин высокого использования памяти.Домашняя страница нашего веб-сайта создавала 59 отдельных запросов из-за отложенной загрузки (ВЫБЕРИТЕ N + 1).После создания специальной модели представления для этой страницы и активной загрузки необходимых нам ассоциаций мы получили 6 запросов, которые выполняются в два раза быстрее.
• Шаблоны проектирования предназначены для того, чтобы направлять вас, а не управлять разработкой вашего приложения.Я склонен следовать подходу DDD, где это возможно.В этом случае я действительно не хотел выставлять внешние ключи на моей модели домена.Однако, поскольку EF не так хорошо обрабатывает сопоставления «многие-к-одному», как NH (он выдаст другой запрос, чтобы получить внешний ключ объекта, который у нас уже есть в памяти), в результате я получил дополнительный запрос (для каждого объекта)отображается на моей странице.В этом случае я решил, что я мог бы смириться с небольшим запахом кода (включая FK в моей модели) ради повышения производительности.
• Распространенным «решением» является использование кеширования при проблемах производительности.Важно определить проблему real , прежде чем сформулировать стратегию кэширования.Я мог бы просто применить кеширование вывода на нашу домашнюю страницу (см. Примечание ниже), но это не меняет того факта, что у меня 59 запросов, попадающих в мою базу данных, когда срок действия кеша истекает.примечание о кэшировании вывода : Когда впервые был выпущен ASP.NET MVC, мы смогли выполнить кэширование пончиков, то есть кэширование страницы APART из определенного региона (-ов).Тот факт, что это больше невозможно, делает кеширование вывода довольно бесполезным, если на странице есть информация о пользователе.Например, у нас есть статус входа в меню навигации сайта.Это само по себе означает, что я не могу использовать кеширование вывода для страницы, так как это также кеширует состояние входа в систему.

  В конечном счете, нет строгого и быстрого правила, как оптимизировать приложение.Наибольшее улучшение производительности нашего приложения произошло, когда мы прекратили использовать ORM для построения наших ассоциаций (для общедоступной части нашего сайта) и вместо этого загрузили их вручную в наши модели просмотра.Мы не могли использовать EF для их быстрой загрузки, поскольку было слишком много ассоциаций (что приводило к грязному запросу UNION).

  Примером является наш механизм тегирования.Такие объекты, как BlogPost и Project, могут быть помечены.Теги и тегируемые объекты имеют отношение многие ко многим.В нашем случае было лучше извлечь все теги и кэшировать их.Затем мы создали проекцию linq для кэширования ключей ассоциации для наших тегируемых объектов (например, ProjectId / TagId).При создании модели представления для нашей страницы мы могли бы создать теги для каждого тегируемого объекта, не затрагивая базу данных.Опять же, это было характерно для нашего приложения, но оно дало значительное улучшение производительности и снижение использования памяти.

  Некоторые из ресурсов / инструментов, которые мы использовали на этом пути:

  • EFProf - для мониторинга запросов, сгенерированных Entity Framework (доступна бесплатная пробная версия)
  • ANTS Memory Profiler (доступна бесплатная пробная версия)
  • Монитор производительности Windows (perfmon)
  • Блог Тесс Феррандез
  • Много кофе:)

  Пока мы делали улучшения, которые потребовали бы насВ рамках ограничений на пул приложений хостинговой компании (Arvixe) я чувствую обязанность посоветовать людям, которые смотрят на их планы Windows Reseller, что такие ограничения существуют (поскольку Arvixe нигде не упоминает об этом при рекламе плана).Поэтому, когда что-то выглядит слишком хорошо, чтобы быть правдой (неограниченно x, y, z), обычно это так.

Answer 2

Самое смешное, я думаю, что они получили свою оценку по этому URL:

http://blog.whitesites.com/w3wp-exe-using-too-much-memory-and-resources__633900106668026886_blog.htm

PS Это отличная статья, чтобы проверить и убедиться, что вы делаете что-то, что пареньописывает.(Например, кэширование ваших страниц)

PSS Только что проверил нашу систему, и она работает на 50 мегабайтах в настоящее время.Мы используем MVC 2 и EF CTP 4.