Подтвердить что ты не робот

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

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

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

Сайт, работающий в режиме деблокирования, использует около 110 МБ ОЗУ.

Я пробовал использовать SQL Server Express, а не CE, и это не имело особого значения.

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

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

  • Проверьте основы. Удостоверьтесь, что вы скомпилируете в режиме деблокирования и установите отладку компиляции в false в web.config. Легко забыть такие вещи.
  • Используйте символы DEBUG для диагностического кода. Примером этого может быть использование таких инструментов, как NHProf (да, я уже был пойман этим раньше). Самое простое - обернуть такой код в директиве #if DEBUG, чтобы он не был скомпилирован в выпуск вашего приложения.
  • Не забывайте о SQL. ORM слишком легко игнорировать то, как ваше приложение разговаривает с вашей базой данных. Использование SQL Profiler или таких инструментов, как EFProf/NHProf, может показать вам, что именно происходит. В случае с EF вы, вероятно, почувствуете себя немного больным после этого, особенно если вы значительно используете ленивую загрузку. После этого вы можете начать оптимизацию (см. Пункт ниже).
  • Ленивая загрузка удобна, но не должна использоваться в представлениях MVC (IMO). Это было одной из основных причин использования нашей высокой памяти. На домашней странице нашего веб-сайта было создано 59 отдельных запросов из-за ленивой загрузки (SELECT N + 1). Создав конкретную модель просмотра для этой страницы и с нетерпением загрузив необходимые нам ассоциации, мы получили до 6 запросов, выполненных за половину времени.
  • Шаблоны проектирования помогут вам, а не правила разработки вашего приложения. Я стараюсь следовать методу DDD, где это возможно. В этом случае я действительно не хотел раскрывать внешние ключи в моей модели домена. Однако, поскольку EF не обрабатывает ассоциации "один-на-один", а также NH (он выдаст другой запрос только для получения внешнего ключа объекта, который у нас уже имеется в памяти), у меня появился дополнительный запрос (для каждого объекта) отображается на моей странице. В этом случае я решил, что я мог бы смириться с запахом кода (включая FK в моей модели) ради повышения производительности.
  • Общим "решением" является бросить кеширование при проблемах производительности. Важно определить реальную проблему, прежде чем сформулировать стратегию кэширования. Я мог бы просто применить выходное кэширование к нашей домашней странице (см. Примечание ниже), но это не меняет того факта, что у меня есть 59 запросов, ударяющих мою базу данных, когда срок действия кеша истекает.

Заметка о кэшировании вывода: Когда ASP.NET MVC был впервые выпущен, мы смогли выполнить кэширование пончиков, то есть кэширование страницы APART из определенного региона (областей). Тот факт, что это уже невозможно, делает кэширование вывода довольно бесполезным, если у вас есть пользовательская информация на странице. Например, у нас есть статус входа в меню навигации сайта. Это само по себе означает, что я не могу использовать кэширование вывода для страницы, так как он также будет кэшировать статус входа.

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

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

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

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

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

Ответ 2

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

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

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

P.S.S. Просто проверили нашу систему, и сейчас она работает со скоростью 50 мегабайт. Мы используем MVC 2 и EF CTP 4.