2010-02-11 3 views

ответ

278

Скомпилированный список возможных источников повышения ниже:

Общие

  • Воспользоваться профайлер, чтобы обнаружить утечки памяти и проблемы с производительностью в вашем приложении. лично я предлагаю dotTrace
  • Запустите свой сайт в режиме деблокирования, а не в режиме отладки, когда в процессе производства, а также во время профилирования производительности. Режим выпуска намного быстрее. Режим отладки может скрыть проблемы с производительностью в вашем собственном коде.

Кэширование

  • Использование CompiledQuery.Compile() рекурсивно избегая перекомпиляции запроса выражения
  • Cache не склонных к изменению содержимого с помощью OutputCacheAttribute для сохранения ненужных и действий казни
  • U как таковые куки для часто обращались, не конфиденциальной информации
  • Использования ETags и срока действия - Написать свой обычай ActionResult методы, если необходимой
  • Рассмотрите возможность использования RouteName организовать ваши маршруты, а затем использовать его для создания ваших ссылок, и стараться не использовать основанный на выражении метод ActionLink.
  • Рассмотрим реализацию стратегии кэширования разрешения маршрута
  • Поместить повторяющийся код внутри вашего PartialViews, во избежание сделать его XXXX раз: если вы в конечном итоге вызывая те же неполные 300 раз в одной и той же точки зрения, наверное, есть что-то неправильно с этим. Explanation And Benchmarks

Routing

безопасности

  • Использование аутентификации с помощью форм, Храните ваши часто используемые секретные данные в билете на аутентификации

DAL

балансировки нагрузки

  • Использование обратных прокси-серверов, чтобы распределить нагрузку клиента по экземпляру приложения. (Переполнение стека использует HAProxy (MSDN).

  • Использование Asynchronous Controllers осуществлять действия, которые зависят от обработки внешних ресурсов.

стороне клиента

  • Оптимизация на стороне клиента, используйте инструмент, такой как YSlow для предложения для повышения производительности
  • Используйте AJAX для обновления компонентов вашего пользовательского интерфейса, избегайте целого обновления страницы, когда это возможно.
  • Рассмотрите возможность реализации архитектуры pub-sub -i.e. Comet - для доставки контента против перезагрузка, основанная на таймаутах.
  • Переместите графику и логику генерации графа на клиентскую сторону, если это возможно. Генерация графика - это дорогостоящее мероприятие. Откладывая на стороне клиента ваш сервер от ненужной нагрузки и позволяя вам работать с графиками локально, не создавая нового запроса (т. Е. Диаграммы Flex, jqbargraph, MoreJqueryCharts).
  • Использование CDN для скриптов и медиа-контента для повышения нагрузки на стороне клиента (т.е. Google CDN)
  • Минимизировать - Compile - ваш JavaScript для того, чтобы улучшить ваш размер сценария
  • Держите размер печенья небольшой, так как куки отправляются сервер по каждому запросу.
  • Рассмотрите возможность использования DNS and Link Prefetching, когда это возможно.

Глобальной конфигурация

  • Если вы используете бритву, добавьте следующий код в вашем Global.asax.cs, по умолчанию, Asp.Net MVC делает с ASPX двигателем и двигателем бритвы , Это использует только RazorViewEngine.

    ViewEngines.Engines.Clear(); ViewEngines.Engines.Add(new RazorViewEngine());

  • Добавить GZIP (сжатие HTTP) и статический кэш (изображения, CSS, ...) в вашем web.config <system.webServer> <urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="true"/> </system.webServer>

  • Удалить неиспользуемые модули HTTP
  • Промойте ваш HTML как в ближайшее время, как она создается (в вашем web.config) и отключить ViewState, если вы не используете его <pages buffer="true" enableViewState="false">
+6

Ожидайте, что вы имеете в виду, что я теряю производительность, когда я, например. иметь представление, которое отображает результат, вызывая раздражение через IList и вызывает Render.PartialView («Строка», элемент) для каждого элемента списка? сколько я теряю? или как я могу измерить прирост производительности? –

+0

@SDReyes - в чем смысл ** pub-sub architecture **? – xameeramir

+0

Это круто. Однако ссылка Uber Profiler мертва. Следует ли это связать с одним из профилировщиков ORM? – shanabus

6

Не потрясающая оптимизация, но я думал, что выброшу ее там - Use CDN's for jQuery, etc..

Цитата из самого ScottGu: Microsoft Ajax CDN позволяет значительно повысить производительность ASP.NET Web Forms и приложений ASP.NET MVC, использующих ASP.NET AJAX или jQuery. Услуга предоставляется бесплатно, не требует никакой регистрации и может использоваться как в коммерческих, так и некоммерческих целях.

Мы даже используем CDN для наших веб-сайтов в Моссе, которые используют jQuery.

10

Основное предложение следовать REST principles и следующие моменты связывает некоторые из этих руководителей в рамках ASP.NET MVC:

  1. Сделайте контроллеры stateless - это больше "Web производительность/масштабируемость »(в отличие от производительности микро/машинного уровня) и основное дизайнерское решение, которое повлияет на ваши приложения в будущем - особенно в том случае, если оно станет популярным или, если вам нужна некоторая отказоустойчивость, например.
    • Не используйте Sessions
    • Не используйте TempData - которая использует сеансы
    • Не пытайтесь 'кэш' все 'преждевременно'.
  2. Использование Forms Authentication
    • Держите часто используемых конфиденциальных данных в билете аутентификации
  3. Использование куки для часто обращались, не конфиденциальной информации
  4. сделать ваш resources cachable на веб
    • Utilize ETags
    • Использование истечения
    • Напишите свои собственные классы ActionResult при необходимости
    • Использование reverse proxies
  5. Скомпилируйте JavaScript. There is Closure compiler library, чтобы сделать это (обязательно there are others, just search for 'JavaScript compiler')
  6. Используйте CDN (сеть доставки контента) - особенно для ваших больших медиафайлов и так далее.
  7. Рассмотрим различные типы хранения данных, например, файлы, ключ/значение магазины и т.д. - не только SQL Server
  8. Последнее, но не в последнюю очередь, проверить свой веб-сайт для выполнения
10

Code Climber и this blog entry предоставляют подробные способы повышения производительности приложения.

Скомпилированный запрос увеличит производительность вашего приложения, но он не имеет ничего общего с ASP.NET MVC. Это ускорит каждое приложение db, так что это не совсем о MVC.

6

При доступе к данным с помощью LINQ полагаться на IQueryable ...

Why use AsQueryable() instead of List()?

... и leverge хороший Repository картина:

Loading Subrecords in the Repository Pattern

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

6

Также, если вы используете NHibernate, вы можете включить и настроить кеш второго уровня для запросов и добавить к области запросов и тайм-ауту. И есть профайлер для задницы для EF, L2S и NHibernate - http://hibernatingrhinos.com/products/UberProf. Это поможет настроить ваши запросы.

+0

Недавно Айенде рассказал о том, как EF Profiler помог ему настроить образец приложения MVC: http://ayende.com/Blog/archive/2010/05/17/analyzing-the-mvc-music-store-data-access.aspx –

4

В дополнение ко всей большой информации об оптимизации вашего приложения на стороне сервера, я бы сказал, что вы должны взглянуть на YSlow. Это превосходный ресурс для улучшения производительности сайта на стороне клиента.

Это относится ко всем сайтам, а не только к ASP.NET MVC.

3

Один очень простой способ сделать это - асинхронно думать, обращаясь к данным, которые вы хотите для страницы. Независимо от того, читаете ли вы из веб-службы, файла, базы данных или чего-то еще, используйте как можно больше асинхронную модель. Хотя это не обязательно поможет какой-либо одной странице быть быстрее, это поможет вашему серверу работать в целом.

7

Это может показаться очевидным, но запустите ваш сайт в режиме деблокирования, а не в режиме отладки, когда на производстве, а также во время профилирования производительности. Режим деблокирования много быстрее. Режим отладки может скрыть проблемы с производительностью в вашем собственном коде.

3

Я также добавить:

  1. Используйте Sprites: Спрайты большая вещь, чтобы уменьшить запрос. Вы объединяете все свои изображения в один и используете CSS, чтобы получить часть спрайта . Microsoft предоставляет хорошую библиотеку для этого: Sprite and Image Optimization Preview 4.

  2. Кэш Ваш объект сервера: Если у вас есть списки ссылок или данные, которые будут редко меняться, вы можете кэшировать их в память, а не запрашивать базу данных каждый раз.

  3. Использование ADO.NET вместо Entity Framework: EF4 or EF5 велики, чтобы сократить время разработки, но это будет болезненным для оптимизации. Проще оптимизировать stored procedure, чем объект Framework. Поэтому вы должны максимально использовать процедуры хранилища. Dapper обеспечивает простой способ запроса и сопоставления SQL с очень хорошим качеством .

  4. Страница кэширования или частичная страница: MVC предоставляет некоторый простой фильтр для кэширования страницы в соответствии с некоторыми параметрами, поэтому используйте ее.

  5. Уменьшить вызовы базы данных: Вы можете создать уникальный запрос базы данных, который возвращает несколько объектов. Проверьте сайт Dapper.

  6. Всегда иметь чистую архитектуру: Иметь чистую архитектуру n-уровня, даже в небольшом проекте. Это поможет вам сохранить ваш код в чистоте, и при необходимости его будет проще оптимизировать.

  7. Вы посмотрите на этот шаблон «Neos-SDI MVC Template» , который создаст чистую архитектуру для вас с большим количеством улучшения производительности по умолчанию (проверить MvcTemplate сайт) может.

+0

Считаете ли вы, что лучше запустить одну хранимую процедуру, которая возвращает больше наборов результатов, а затем запустить более хранимые процедуры в асинхронном режиме? – Muflix

2

1: Получить сроки. Пока вы не знаете, где происходит замедление, вопрос слишком широк, чтобы ответить. У проекта, над которым я работаю, есть эта точная проблема; Там нет регистрации, чтобы даже знать, как долго некоторые вещи берут; мы можем только догадываться о медленных частях приложения, пока не добавим тайминги к проекту.

2: Если у вас есть последовательные операции, не бойтесь слегка многопоточности. ОСОБЕННО, если задействованы операции блокировки. PLINQ - ваш друг здесь.

3: Pregenerate ваших MVC Просмотров когда издательство ... Это поможет с некоторыми из «первой страницы хита»

4: Некоторые утверждают, для хранимой процедуры/ADO преимущества скорости. Другие утверждают, что скорость развития EF и более четкое разделение ярусов и их цель. Я видел очень медленные проекты, когда SQL и обходные пути используют Sprocs/Views для извлечения и хранения данных. Кроме того, ваша трудность в тестировании повышается. Наша нынешняя кодовая база, которую мы конвертируем из ADO в EF, не хуже, а в некоторых случаях лучше, чем старая модель Hand-Rolled.

5: Это сказало, подумайте о приложении Warmup. Часть того, что мы делаем, чтобы помочь устранить большую часть наших проблем с производительностью EF, заключалась в том, чтобы добавить специальный метод разминки. Он не прекомпилирует какие-либо запросы или что-то еще, но это помогает с большей частью загрузки/генерации метаданных. Это может быть еще более важно при работе с моделями Code First.

6: Как говорили другие, не используйте сеансовое состояние или ViewState, если это возможно. Они не обязательно являются оптимизацией производительности, о которой думают разработчики, но как только вы начинаете писать более сложные веб-приложения, вам нужна отзывчивость. Состояние сеанса исключает это. Представьте длинный запрос. Вы решили открыть новое окно и попробовать менее сложную. Ну, вы можете также ждать с состоянием сеанса, потому что сервер будет ждать, пока первый запрос не будет выполнен, прежде чем перейти к следующему для этого сеанса.

7: Минимизировать круглые поездки в базу данных. Сохраните материал, который вы часто используете, но не сможете реально изменить ваш .Net Cache. По возможности старайтесь вставлять свои вставки/обновления.

7.1: Избегайте использования кода доступа к данным в вашем представлении «Бритва» без на то причин. Я бы не сказал этого, если бы не увидел его. Они уже получали доступ к своим данным при объединении модели, почему, черт возьми, они не включали ее в модель?

1

В своем требовании для оптимизации клиентской стороны не забывайте о слое базы данных. У нас было приложение, которое длилось от 5 секунд, чтобы загрузить до 50 секунд в одночасье.

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

1
  1. Внедрение Gzip.
  2. Используйте асинхронный рендеринг для частичных представлений.
  3. Свернуть базы данных хитов.
  4. Используйте скомпилированный запрос.
  5. Запустите профайлер и найдите ненужные удары. Оптимизируйте все хранимые процедуры, которые занимают более 1 секунды, чтобы вернуть ответ.
  6. Используйте кеширование.
  7. Использование bundling minification оптимизации.
  8. Используйте утилиты HTML 5, такие как кеш сеанса и локальное хранилище для содержимого только для чтения.
0

После вещи, чтобы сделать

  1. режим Cache Режим ядра
  2. Pipeline
  3. Удалить неиспользуемые модули
  4. runAllManagedModulesForAllRequests
  5. Не писать в Wwwroot
  6. Удалить неиспользуемое вид двигатели и язык
0

Использование Bundling and Minification также помогает вам улучшить производительность. Это в основном снижает время загрузки страницы.

2

Просто хотел добавить свои 2 цента. Мощный эффективный способ оптимизации генерации URL-адреса в приложении MVC ... не генерирует их вообще.

Большинство из нас более или менее знают, как URL-адреса генерируются в наших программах в любом случае, так просто используя статические Url.Content("~/Blahblah") вместо Url.Action() или Url.RouteUrl(), где это возможно, превосходит все другие методы почти в 20 раз и даже больше.

PS. Я провел контрольную отметку в несколько тысяч итераций и опубликовал результаты on my blog, если это интересно.

Смежные вопросы