Оптимизация на приложението, IIS конфигурация
Уеб сървърът на IIS, като среда за изпълнение на уеб приложение, има известно влияние върху цялостната производителност. Например, колкото по-къс е тръбопроводът за обработка на заявки в IIS, толкова по-малко код ще бъде изпълнен и толкова по-бърза ще бъде работата. IIS има механизми, които могат да се използват за подобряване на производителността на приложението чрез намаляване на забавянето и увеличаване на пропускателната способност, както и някои механизми, които, ако са правилно конфигурирани, могат да подобрят цялостната производителност на приложението.
Изходно кеширане
Вече знаем, че ASP.NET поддържа собствен механизъм за кеширане на изхода, защо да използваме друг подобен механизъм в IIS? Отговорът на този въпрос е прост: има и други видове съдържание освен ASP.NET страници, които могат да бъдат кеширани. Например, можем да кешираме често искани статични файлове с изображения или изхода на нашите собствени манипулатори на HTTP заявки. За тази цел можете просто да използвате механизма за кеширане, поддържан от IIS уеб сървъра.
IIS има два механизма за кеширане: кеш на потребителското пространство и кеш на пространството на ядрото.
Кеширане на потребителско пространство
Точно като ASP.NET, IIS уеб сървърът може да кешира отговорите в паметта, така че отговорите на последващи заявки да могат да бъдат изпращани от кеша в паметта, без достъп до статични файлове на диска и без извикване на код от страна на сървъра.
За да настроите кеширане, отворете приложението IIS Manager, изберете вашето уеб приложение, отворете настройката за кеширане на изход, щракнете върху връзката Добавяне в панела с действия, за да добавите ново правило за кеширане или изберете съществуващо правило за редактиране.
За да създадете ново правилокеширане в потребителско пространство, добавете ново правило, въведете разширението на файловете, които искате да кеширате, и поставете отметка в квадратчето за кеширане в потребителски режим в диалоговия прозорец Добавяне на правило за кеширане, както е показано на фигурата по-долу:
Като поставите отметка в квадратчето, ще можете да изберете кога кешираният елемент да бъде премахнат от паметта, след актуализиране на файла на диска или след известно време след кеша. За статични файлове изтриването след актуализация е по-подходящо, докато указването на интервал от време е по-подходящо за динамично съдържание. Като щракнете върху бутона Разширени, можете да получите достъп до настройките, които контролират кеширането на различни версии на изхода (според параметрите в низа на заявката или HTTP заглавките).
След добавяне на правило за кеширане, настройките се съхраняват във файла web.config на приложението, под system.webServer --> кеширане. Например, за правило за кеширане за .aspx страници до 30 минути, като се има предвид HTTP заглавката Accept-Language, следният код ще бъде генериран в конфигурационния файл:
Кеширане на пространството на ядрото
За разлика от механизма за кеширане на потребителското пространство, който съхранява информация в паметта на работния процес на IIS, механизмът за кеширане на пространството на ядрото съхранява информация в паметта на драйвера HTTP.sys. Кеширането в пространството на ядрото осигурява по-бързо време за реакция, но не винаги се поддържа. Например, кеширането в пространството на ядрото не може да се използва, когато заявката съдържа низ от параметри на заявката или когато заявката не е анонимна заявка.
Настройването на правила за кеширане в пространството на ядрото се извършва почти по същия начин като кеширането в пространствотопотребител. В диалоговия прозорец за настройки на правилата поставете отметка в квадратчето Кеширане в режим на ядрото и изберете желания метод за кеширане.
В едно правило е разрешено да се използват и двата режима на кеширане, в пространството на ядрото и в пространството на потребителя. В този случай IIS първо ще се опита да приложи кеширане на пространството на ядрото. Ако опитът е неуспешен, например когато заявката съдържа низ от параметри, се прилага кеширане на потребителско пространство.
Ако опцията за интервално кеширане е избрана както в режимите kernel-space, така и в user-space, и двата интервала трябва да съвпадат, в противен случай и двата режима ще използват интервала, зададен за кеширане в режим на ядрото.
Настройване на набор от приложения
Настройките на набора от приложения определят как IIS ще създава и поддържа работни процеси, в рамките на които ще работи нашият код. По време на инсталирането на IIS и ASP.NET се създават няколко групи приложения, в зависимост от инсталираната версия на .NET, към които можете да добавяте повече групи, докато разгръщате повече уеб приложения. Когато се създаде набор от приложения, той получава някои настройки със стойности по подразбиране, които контролират поведението му. Например всеки пул получава време за изчакване на неактивност, след което този пул от приложения спира.
Разбирането на значението на някои от тези настройки може да ви помогне да настроите фино как работи пула и по този начин да отговорите по-пълно на нуждите на вашето приложение.
рестартирам
Чрез промяна на настройката за конфигурация за рестартиране можете да контролирате кога наборът от приложения рестартира работния процес. Например, можете да организирате рестартиране на работния процес на всеки няколко часаили когато е надвишено ограничение на паметта. Ако уеб приложение започне да консумира големи количества памет с течение на времето (например за съхраняване на обекти), увеличаването на броя на рестартирането може да помогне за поддържане на неговата производителност на високо ниво. От друга страна, ако уеб приложението не показва никакви проблеми, докато работи, намаляването на броя на рестартирането ще предотврати загубата на информация за състоянието.
Можете да използвате брояча на производителността ASP.NET\Worker Process Restarts, за да проверите броя и честотата на рестартирането на набора от приложения. Ако видите твърде много рестартирания без видима причина, опитайте да сравните стойностите, които получавате, с потреблението на памет на приложението и използването на процесора, тъй като рестартирането може да бъде причинено от превишаване на други ограничения, определени от настройките на пула на приложението.
Изчакване на неактивност
По подразбиране наборът от приложения ще се прекрати след 20 минути неактивност. Ако се очакват такива прекъсвания, като например когато всички потребители напуснат за обяд, помислете за увеличаване на времето за изчакване или дори за пълното му отмяна.
Свързване на процеси към процесорни ядра
По подразбиране наборът от приложения е конфигуриран да използва всички налични процесорни ядра. Ако имате специален фонов процес, който използва цялото процесорно време, което ще му бъде разпределено, можете да настроите афинитет към пул за определени ядра, освобождавайки останалото за фоновия процес. Разбира се, това също ще изисква фоновият процес да бъде конфигуриран да се свързва с други процесорни ядра, за да се избегне конкуренцията между него и работния процес за същите ядра.
По подразбиране наборът от приложения стартира един работен процес, обслужващ всички заявки,получени от приложението. Ако работният процес трябва да обработва едновременно множество заявки, които се конкурират за един и същ ресурс, това може да причини забавяне при подготовката на отговорите.
Например, ако дадено приложение използва собствен механизъм за кеширане с ключалки, които предотвратяват едновременното добавяне на елементи към кеша, заявките ще трябва да синхронизират операциите върху тях, което води до забавяния, които са трудни за откриване и коригиране. Понякога е възможно да коригирате кода, за да намалите използването на ключалки, но това не винаги е възможно. Друг начин за елиминиране на конкуренцията за ресурси е да се изпълняват множество работни процеси, работещи с едно и също приложение, като всеки обработва своя собствена подгрупа от заявки, като по този начин се елиминира ненужната конкуренция.
Друг пример, при който може да бъде полезно да имате множество процеси, изпълняващи едно и също уеб приложение, е използването на 64-битов IIS сървър, работещ с 32-битово уеб приложение. 64-битовите сървъри обикновено имат много памет, а 32-битово приложение може да използва не повече от 2 GB, което често води до повишени нива на събиране на боклука и вероятно рестартиране на пула от приложения. Като поддържате два или три работни процеса за 32-битово уеб приложение, можете да постигнете по-добро използване на паметта на сървъра и да намалите честотата на събиране на отпадъци и рестартиране на пула от приложения.
В настройките на IIS на набора от приложения можете да дефинирате максималния брой работни процеси, които могат да бъдат стартирани за обслужване на заявки. Ако зададете този параметър на стойност, по-голяма от 1 (стойността по подразбиране), с увеличаване на натоварването на уеб приложението, за него ще бъдат стартирани допълнителни работни процеси додо определения максимум. Пул от приложения, който има повече от един процес, се нарича "уеб градина". Всеки път, когато се установи връзка с клиент, тя се свързва с работен процес, който ще обслужва заявки от този клиент, като същевременно поддържа равномерно разпределение на потребителските заявки между процесите и намалява излишните разходи за конкуренция.
Имайте предвид, че има недостатъци при използването на уеб градина. Повече работни процеси заемат повече памет, елиминират възможността да се използва механизмът по подразбиране за съхраняване на информация за сесията в паметта на процеса и когато няколко работни процеси работят на един и същ компютър, може да има конкуренция между тях за локални ресурси, например за използване на споделен лог файл.