Крім нашого коду, кожен вхідний запит і виходить відповідь обробляються компонентами ASP.NET. Деякі механізми ASP.NET, такі як ViewState, були передбачені для потреб розробки, але вони можуть впливати на загальну продуктивність програми. При тонкій настройці додатків ASP.NET рекомендується змінити поведінку за замовчуванням деяких з цих механізмів, хоча іноді ці зміни можуть зажадати зміни програмного коду програми.
Відключення механізмів трасування і налагодження в ASP.NET
Механізм трасування ASP.NET Tracing дозволяє розробникам отримувати діагностичну інформацію для тієї чи іншої сторінки, наприклад, час виконання і її шлях, стан сеансу і список HTTP-заголовків.
Хоча механізм трасування дозволяє отримувати безцінну інформацію в процесі розробки та налагодження програм ASP.NET, він чинить негативний вплив на загальну продуктивність програми, виконуючи збір даних про кожному запиті. Тобто, якщо підтримка трасування була включена на етапі розробки, відключайте її перед розгортанням свого застосування в експлуатаційної середовищі, для чого достатньо просто змінити параметр trace в файлі web.config:
За замовчуванням, якщо явно не вказано інше, трасування відключена (enabled = "false"), тому, відключити трасування можна також простим видаленням параметра trace з файлу web.config.
Коли створюється нова веб-додаток на основі ASP.NET, в файл web.config автоматично додається конфігураційний розділ system.web -> compilation з атрибутом debug, встановленим в значення true:
Проблема з цим параметром в тому, що розробники часто забувають встановити його в значення false при розгортанні на діючому веб-сервері, або спеціально залишають у значенні true, щоб мати можливість отримання більш докладної інформації в разі появи виключення. Це може призводити до кількох проблем, пов'язаних з продуктивністю:
Сценарії, що завантажуються з використанням обробника WebResources.axd. наприклад, коли в сторінках використовуються перевірки допустимості, що не будуть кешироваться браузером. Коли прапор debug встановлений в значення false, відповіді від цього обробника будуть забезпечуватися заголовками, що допускають можливість кешування, дозволяючи браузерам зберігати результати в кеші для використання в майбутньому.
Коли параметр debug має значення false, тайм-аут на обробку запитів не встановлюється. Хоча це дуже зручно при налагодженні, така поведінка небажано в промисловому оточенні, так як такі запити можуть привести до того, що сервер виявиться не в змозі обслужити інші запити, або навіть викликати надмірне навантаження на процесор, збільшити споживання пам'яті та породити інші проблеми, пов'язані з розподілом ресурсів.
Установка прапора debug в значення false дозволить середовищі виконання ASP.NET визначати тайм-аути для обробки запитів відповідно до настройками httpRuntimeExecutionTimeout (значення за замовчуванням 110 секунд).
Коли параметр debug має значення true, JIT-компілятор буде оптимізувати код. Ці оптимізації є одним з найважливіших переваг середовища .NET і можуть забезпечити значне збільшення продуктивності додатка ASP.NET без зміни його коду. Установка параметра debug в значення false дозволить JIT-компілятор виконати свою роботу, і зробить ваше додаток більш швидким і ефективним.
Змінити цей параметр дуже просто: достатньо повністю видалити атрибут debug з файлу конфігурації або привласнити йому значення false:
Якщо ви боїтеся, що забудете змінити цей параметр при розгортанні додатки на діючому сервері, можна змусити всі програми ASP.NET на сервері ігнорувати параметр debug, наступний фрагмент в файл machine.config на сервері:
Відключення механізму ViewState
Механізм збереження стану уявлення ViewState використовується в додатках ASP.NET Web Forms для збереження стану сторінки в отображаемую розмітку HTML (додатки ASP.NET MVC не використовують цей механізм). Механізм ViewState дозволяє ASP.NET зберігати стан сторінки для відправки його назад користувачем. Дані зберігаються в форматі HTML, шифруються (за замовчуванням шифрування вимкнено), кодуються в рядок Base64 і запам'ятовуються в прихованому полі. Коли користувач відправляє сторінку назад, вміст поля декодируется і перетвориться назад в асоціативний масив. Багато засобів управління сервером використовують механізм ViewState для збереження власної інформації, наприклад, значень своїх властивостей.
Збільшення обсягу сторінок при використанні механізму ViewState зазвичай залишається непоміченим для клієнтів, які звертаються до веб-сервера в локальній мережі. Це пояснюється тим, що локальні мережі зазвичай відрізняються високою швидкістю передачі і транспортування дуже великих сторінок в таких мережах становить мілісекунди (в оптимально побудованої гигабитной локальної мережі пропускна здатність може досягати
40-100 Мбайт / сек, залежно від використовуваного апаратного забезпечення). Однак в більш повільних глобальних мережах, таких як Інтернет, збільшення розмірів сторінок стає більш помітним.
Якщо з додатком не потрібно використовувати цей механізм, його краще відключити. Відключити механізм ViewState можна в файлі web.config, для всього програми цілком:
Якщо його не можна відключити для всього програми, можна заборонити використання механізму ViewState в окремій сторінці і всіх її елементах управління:
Є також можливість відключити підтримку ViewState в окремих елементах управління:
До версії ASP.NET 4 відключення підтримки механізму ViewState в сторінці унеможливлювало її включення в окремих елементах управління на сторінці. Починаючи з версії ASP.NET 4 така можливість була додана. Досягається це за допомогою властивості ViewStateMode. Наприклад, наступний код відключає підтримку механізму ViewState для всієї сторінки, крім елемента управління ListView:
Установка атрибута EnableViewState в значення false має більш високий пріоритет, ніж атрибути ViewStateMode. Тобто, якщо ви припускаєте використовувати атрибути ViewStateMode, обов'язково встановіть атрибут EnableViewState в значення true або просто видаліть його (за замовчуванням він отримує значення true).
Кеш виведення на стороні сервера
Сторінки ASP.NET вважаються динамічними, в сенсі інформаційного наповнення, проте, часто таке динамічний вміст сторінок не змінюється з плином часу. Наприклад, сторінка може приймати ідентифікатор продукту та повертати розмітку HTML з його описом. Сама по собі сторінка є динамічною, тому що може повертати різний опис для різних продуктів, але опис певного продукту не змінюється, принаймні, поки воно не зміниться в базі даних.
В продовження прикладу з продуктом: щоб запобігти виконанню повторних запитів до бази даних щоразу, коли користувачі запитують опис продукту, можна зберегти опис в локальному кеші і забезпечити більш швидке його витяг, але при цьому все ще необхідно генерувати розмітку HTML у відповідь на кожен запит . Замість кешування вихідних даних, ASP.NET надає іншу можливість - механізм ASP.NET Output Cache. де зберігається сама розмітка HTML.
Завдяки цьому механізму з'являється можливість зберігати розмітку HTML, яка автоматично буде повертатися у відповідь на наступні запити, минаючи етап виконання програмного коду, що генерує сторінку. Кеш виведення в ASP.NET підтримується і для додатків на основі Web Forms, де в кеші зберігаються сторінки, і для додатків на основі ASP.NET MVC, де зберігаються результати виконання операцій контролера.
Наприклад, наступний код використовує кеш виведення для збереження уявлення, що повертається операцією контролера ASP.NET MVC на термін до 30 секунд:
Якби операція Index в прикладі вище приймала параметр з ідентифікатором продукту і повертала уявлення з інформацією про певний продукт, нам треба було б кешувати кілька версій виведення для різних ідентифікаторів. Тому кеш виведення підтримує не тільки можливість збереження єдиної версії вихідних даних, але і різних версій даних, що генеруються однією і тією ж операцією, викликаної з різними параметрами.
На додаток до параметрів запиту механізм кешування виведення може також враховувати HTTP-заголовки запиту, такі як Accept-Encoding і Accept-Language. Наприклад, якщо метод контролера може повертати вміст на різних мовах, в залежності від HTTP-заголовка Accept-Language, ви можете налаштувати облік цього заголовка і зберігати в кеші різні версії виведення на різних мовах.
Якщо одні й ті ж настройки хеширования застосовуються до різних сторінках або операціями, можна створити профіль кешування і використовувати його, замість повторення налаштувань знову і знову. Профілі кешування створюються в файлі web.config, в розділі system.web -> caching. Наприклад, наступний фрагмент оголошує профіль кешування, який передбачається використовувати разом з різними сторінками:
Тепер цей профіль можна застосувати до операції Index: