Відповіді:
Складений список можливих джерел удосконалення знаходиться нижче:
Загальні
Кешування
CompiledQuery.Compile()
рекурсивно, уникаючи перекомпіляції виразів запитівOutputCacheAttribute
для збереження непотрібних та діїActionResultпри необхідності запишіть свої власні методиRouteNameщоб організувати ваші маршрути, а потім використовувати їх для генерування ваших посилань, і намагайтеся не використовувати метод ActionLink на дереві виразів.PartialViews, уникайте повторення xxxx разів: якщо ви в кінцевому підсумку викликаєте той самий частковий 300 разів в одному і тому ж представленні, ймовірно, в цьому щось не так. Пояснення та орієнтириМаршрутизація
Використовуйте Url.RouteUrl("User", new { username = "joeuser" })для вказівки маршрутів. ASP.NET MVC Перфоманс Руді Бенковича
Розв’язання маршруту кешу за допомогою цього помічника UrlHelperCached ASP.NET MVC Perfomance від Руді Бенковича
Безпека
DAL
Балансування навантаження
Використовуйте зворотні проксі-сервери, щоб розповсюдити завантаження клієнта по вашому екземпляру програми. (Переповнення стека використовує HAProxy ( MSDN ).
Використовуйте асинхронні контролери для реалізації дій, які залежать від обробки зовнішніх ресурсів.
Сторона клієнта
Глобальна конфігурація
Якщо ви використовуєте Razor, додайте наступний код у ваш 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>
<pages buffer="true" enableViewState="false">Основна пропозиція полягає у дотриманні принципів REST, а наведені нижче пункти пов'язують деякі з цих принципів у рамках ASP.NET MVC:
Code Climber і цей запис у блозі надають детальні способи підвищення продуктивності програми.
Складений запит підвищить продуктивність вашої програми, але він не має нічого спільного з ASP.NET MVC. Це пришвидшить кожен db-додаток, тому мова йде не про MVC.
Це може здатися очевидним, але запускайте свій сайт у режимі випуску, а не в режимі налагодження, коли ви працюєте, а також під час профілювання продуктивності. Режим випуску набагато швидший. Режим налагодження може приховати проблеми з продуктивністю у власному коді.
Під час доступу до даних через LINQ покладайтеся на IQueryable ...
Навіщо використовувати AsQueryable () замість List ()?
... і використовуйте хороший зразок сховища:
Завантаження підзаписів у шаблоні репозиторію
Це дозволить оптимізувати доступ до даних, щоб забезпечити завантаження лише необхідних даних і тоді, коли вони потрібні.
Не оптимізація, що руйнує землю, але я подумав, що я викину це туди - Використовуйте CDN для jQuery тощо .
Цитата від самого СкотГу: CDN Microsoft Ajax дозволяє значно підвищити продуктивність ASP.NET Web Forms та ASP.NET MVC-додатків, які використовують ASP.NET AJAX або jQuery. Послуга доступна безкоштовно, не потребує жодної реєстрації і може використовуватися як для комерційних, так і для некомерційних цілей.
Ми навіть використовуємо CDN для своїх веб-частин в Moss, які використовують jQuery.
Крім того, якщо ви використовуєте NHibernate, ви можете увімкнути та налаштувати кеш другого рівня для запитів та додати до області запиту область та час очікування. А ще є профайлер для подушок для EF , L2S та NHibernate - http://hibernatingrhinos.com/products/UberProf . Це допоможе налаштувати ваші запити.
Я також додам:
Використовуйте спрайт : спрайти - це чудова річ, щоб зменшити запит. Ви об’єднуєте всі свої зображення в одне ціле і використовуєте CSS, щоб дістатися до хорошої частини спрайту. Microsoft надає хорошу бібліотеку для цього: спрайт та оптимізація зображень Preview 4 .
Кеш об'єкта вашого сервера : Якщо у вас є деякі списки посилань або дані, які змінюватимуться рідко, ви можете кешувати їх у пам'ять, а не запитувати базу даних кожен раз.
Використовуйте ADO.NET замість Entity Framework : EF4 or EF5чудово скорочують час розробки, але оптимізувати буде болісно. Оптимізувати збережену процедуру простіше, ніж Entity Framework. Тож слід якомога більше використовувати магазинні процедури. Dapper пропонує простий спосіб запиту та картографування SQL з дуже хорошою продуктивністю.
Сторінка кешу або часткова сторінка : MVC надає простий фільтр для кешування сторінки за деякими параметрами, тому використовуйте її.
Зменшення кількості дзвінків на базі даних : Ви можете створити унікальний запит до бази даних, який повертає кілька об'єктів. Перевірте на веб-сайті Dapper.
Завжди мати чисту архітектуру : мати чисту n-ярусну архітектуру навіть у невеликому проекті. Це допоможе вам зберегти чистий код, і його буде простіше оптимізувати, якщо потрібно.
Ви можете ознайомитись із цим шаблоном " Neos-SDI MVC Template ", який створить для вас чисту архітектуру з великими поліпшеннями роботи за замовчуванням (перегляньте веб-сайт MvcTemplate ).
Одна дуже проста річ - це мислити асинхронно, отримуючи доступ до потрібних даних для сторінки. Чи читайте з веб-сервісу, файлу, бази даних чи чогось іншого, максимально використовуйте модель async. Хоча це не обов'язково допоможе будь-якій одній сторінці бути швидшою, але це допоможе вашому серверу краще працювати в цілому.
1: Отримайте таймінги. Поки ви не знаєте, де знаходиться уповільнення, питання занадто широке, щоб відповісти. Проект, над яким я працюю, має цю точну проблему; Немає реєстрації, щоб навіть знати, скільки часу займають певні речі; ми можемо лише здогадуватися про повільні частини програми, поки не додамо хронології до проекту.
2: Якщо у вас є послідовні операції, не бійтеся злегка багатопотоково. ОСОБЛИВО, якщо задіяні операції блокування. PLINQ - ваш друг тут.
3: Підготуйте перегляди MVC під час публікації ... Це допоможе в деяких "зверненнях до першої сторінки"
4: Деякі аргументи щодо збереженої процедури / ADO переваги швидкості. Інші стверджують, що швидкість розвитку EF та більш чітке розділення рівнів та їх призначення. Я бачив дійсно повільні проекти, коли SQL і обхідні шляхи використовують Sprocs / Views для пошуку та зберігання даних. Крім того, ваші труднощі з тестуванням зростають. Наша нинішня база коду, яку ми перетворюємо з ADO в EF, не працює гірше (а в деяких випадках і краще), ніж стара модель Hand-Rolled.
5: Це сказав: Подумайте про програму Warmup. Частиною того, що ми робимо для усунення більшості наших неприємностей щодо ефективності, було додавання спеціального методу розминки. Він не попередньо компілює запити чи що-небудь інше, але це допомагає при завантаженні / генерації метаданих. Це може бути ще важливішим при роботі з моделями Code First.
6: Як уже говорили інші, не використовуйте стан сесії або ViewState, якщо можливо. Вони не обов'язково розробляють оптимізацію продуктивності, але коли ви починаєте писати складніші веб-додатки, ви хочете реагувати. Стан сесії це виключає. Уявіть тривалий запит. Ви вирішили відкрити нове вікно і спробувати менш складне. Що ж, можливо, ви дочекалися ввімкнення стану сеансу, тому що сервер буде чекати, поки буде виконаний перший запит, перш ніж перейти до наступного для цього сеансу.
7: Мінімізуйте туди і назад до бази даних. Збережіть речі, які ви часто використовуєте, але реально не зміняться у вашому .Net Cache. Спробуйте додати вставки / оновлення, де це можливо.
7.1: Уникайте коду доступу до даних у своїх видах Razor без чортово вагомих причин. Я б не сказав цього, якби не бачив. Вони вже отримували доступ до своїх даних, коли складали модель, чому, чорт, не включили їх у модель?
Просто хотів додати свої 2 копійки. НАЙБІЛЬШИЙ ефективний спосіб оптимізувати генерацію маршруту URL у додатку MVC - це… не генерувати їх взагалі.
Більшість з нас більш-менш знають, як генеруються URL-адреси в наших додатках, тому просто використовуючи статичні Url.Content("~/Blahblah")замість Url.Action()або, Url.RouteUrl()де це можливо, б'є всі інші методи майже в 20 разів і навіть більше.
PS. Я провів орієнтир у декількох тисячах ітерацій та опублікував результати у своєму блозі, якщо зацікавився.
Намагаючись оптимізувати сторону клієнта, не забувайте про рівень бази даних. У нас був додаток, який тривав від 5 секунд для завантаження до 50 секунд протягом ночі.
Під час огляду ми внесли цілу купу змін в схему. Як тільки ми оновили статистику, вона раптом стала такою ж чуйною, як і раніше.
Далі слід зробити щось
Якщо ви запускаєте додаток ASP.NET MVC на Microsoft Azure (IaaS або PaaS), то зробіть наступне, принаймні, до першого розгортання.
Я зробив усі відповіді вище, і це просто не вирішило моєї проблеми.
Нарешті, я вирішив проблему з повільним завантаженням сайту, встановивши PrecompileBeforePublish у профілі публікації на true . Якщо ви хочете використовувати msbuild, ви можете використовувати цей аргумент:
/p:PrecompileBeforePublish=trueЦе дійсно дуже допомагає. Тепер мій MVC ASP.NET завантажується в 10 разів швидше.