Web config где находится

Файл web.config

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

Важно понимать, что файл web.config в веб-приложении не может переопределять все параметры в файле machine.config. Некоторые параметры в этом файле, такие как параметры модели процессов, не могут изменяться для каждого приложения отдельно. Другие параметры, наоборот, являются специфичными для приложений. Это значит, что их можно устанавливать в файле web.config, который находится в корневом виртуальном каталоге веб-сайта, но нельзя в файлах web.config, расположенных в подкаталогах.

Все содержимое конфигурационного файла ASP.NET находится внутри корневого элемента <configuration>. Этот элемент содержит элемент <system.web>, который используется для параметров настройки ASP.NET. Внутри <system.web> находятся отдельные элементы для каждого аспекта конфигурации. Также имеется элемент <appSettings>, используемый для хранения специальных параметров, и элемент <connectionStrings>, применяемый для хранения строк подключения к базам данных, которые используете вы или на которые полагаются средства ASP.NET.

Ниже показано содержимое простейшего файла web.config, который получается при создании пустого веб-сайта ASP.NET в Visual Studio:

Как и все XML-документы, содержимое файла web.config чувствительно к регистру символов. Каждый параметр использует стиль Camel и начинается с прописной буквы. Это означает, что записывать <System.Web> вместо <system.web> не допускается.

Раздел <system.web> играет центральную роль в конфигурации ASP.NET. Именно внутри него находятся все элементы, отвечающие за настройку функциональных средств ASP.NET. В большинстве приложений ASP.NET также используется раздел <appSettings> для хранения разнообразных конфигурационных деталей, касающихся самого приложения, и раздел <connectionStrings> для хранения строк подключения к базе данных. Кроме того, с помощью раздела <system.webServer> можно расширять конвейер ASP.NET дополнительными обработчиками и модулями HTTP. Ниже показан базовый скелет файла web.config:

Конфигурационный файл для приложений ASP.NET 3.5 имеет более сложную структуру из-за способа, которым ASP.NET 3.5 была выпущена. По сути, ASP.NET 3.5 представляет собой комбинацию, которая состоит из базовой модели ASP.NET 2.0, со средой CLR 2.0, и набора расширений. Как результат, каждое приложение использует файл web.config для подключения новых средств. Однако в ASP.NET 4 такой подход не применяется, и приложения ASP.NET имеют более простое и понятное содержимое. Дополнительные параметры настройки были перемещены в файл machine.config и корневой файл web.config, где им самое место.

Наследование конфигурации

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

Например, рассмотрим веб-запрос http://localhost/A/B/C/MyPage.aspx, где А представляет корневой каталог веб-приложения. Этот запрос подразумевает использование параметров на множестве уровней:

Сначала применяются используемые по умолчанию параметры из файла machine.config.

Далее применяются параметры из файла web.config, находящегося в корневом каталоге компьютера. Этот файл web.config хранится в том же каталоге Config, что и файл machine.config.

Если в корневом каталоге приложения А имеется файл web.config, тогда следующими применяются параметры, указанные в нем.

Если в подкаталоге В имеется файл web.config, тогда следующими применяются параметры, указанные в этом файле.

Если в подкаталоге С есть файл web.config, тогда напоследок применяются параметры из него.

этой последовательности, показанной на рисунке, важно обратить внимание, что подкаталогов может быть сколько угодно, но параметры, применяемые в шагах 1 и 2, имеют особое значение. Причина в том, что некоторые параметры (такие как учетная запись Windows, используемая для выполнения кода) могут применяться только на уровне machine.config, а некоторые (вроде типа аутентификации, используемого веб-приложением) — только на уровне корневого каталога приложения.

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

Если возникает конфликт, параметры из файла web.config, находящегося во вложенном каталоге, всегда переопределяют те, что унаследованы от родителя. Однако существует одно исключение. Можно назначить специальные заблокированные разделы параметров, которые изменять нельзя. Этот прием более подробно описан в следующем разделе.

Если вы разрабатываете веб-проект (а не беспроектный веб-сайт), в состав этого проекта будут также включены файлы web.Debug.config и web.Release.config. Эти файлы предназначены для переключения между параметрами, используемыми при тестировании веб-приложения, и параметрами, которые необходимы во время его развертывания в производственной среде. Однако они не дают никакого эффекта при запуске приложения в Visual Studio, поскольку в этом случае они полностью игнорируются.

Использование элементов <location>

Элемент <location> является расширением, позволяющим определять несколько групп параметров настройки в одном конфигурационном файле. Чтобы определить подкаталог или файл, к которому будут применены параметры настройки, нужно использовать атрибут path в элементе <location>. Например, в следующем файле web.config элемент <location> применяется для создания двух групп параметров настройки — для текущего каталога и для подкаталога Secure:

Этот файл web.config, по сути, играет роль двух конфигурационных файлов. Он приводит к такому же результату, как если бы вы разделили параметры настройки на два отдельных файла web.config и поместили их в подкаталог Secure.

В одном конфигурационном файле может находиться сколько угодно различных элементов <location>. Однако элемент <location> часто не используется, поскольку гораздо проще управлять и обновлять параметры настройки конфигурации, когда они разделены на отдельные файлы. Тем не менее, существует один сценарий, в котором элемент <location> обеспечивает функциональность, которую не удастся получить каким-либо другим способом. Это необходимо тогда, когда требуется заблокировать специфические параметры настройки таким образом, чтобы их нельзя было переопределить.

Чтобы получить представление о работе этой технологии, рассмотрим приведенный ниже пример. В нем определены две группы параметров настройки, для одной из которых атрибут allowOverride дескриптора <location> устанавливается в false:

В этом случае переопределить какие-либо параметры настройки в разделе <location> не получится. Если вы попытаетесь это сделать, ASP.NET сгенерирует необработанное исключение при запросе страницы в веб-приложении.

Атрибут allowOverride элемента <location> предназначен в основном для компаний, занимающихся веб-хостингом, которым нужно защитить некоторые параметры настройки от изменения. В этом случае администратору придется модифицировать файл machine.config на веб-сервере и использовать элемент <location> для блокировки различных разделов.

При блокировании параметров настройки в файле machine.config возможны два варианта: первый — заблокировать параметры сразу для всех приложений, опустив в дескрипторе <location> атрибут path, а второй — заблокировать параметры только для конкретного приложения, указав в атрибуте path имя соответствующего веб-приложения.

Элемент <system.web>

В элементе <system.web> содержатся все конфигурационные параметры, касающиеся ASP.NET. Эти параметры отвечают за настройку различных аспектов веб-приложения и включают разные службы, такие как безопасность, управление состоянием и трассировка. Схема раздела <system.web> является фиксированной, т.е. изменять структуру и добавлять собственные элементы нельзя. Однако можно включать сколько угодно конфигурационных разделов.

В таблице ниже перечислены основные дочерние элементы, которые могут присутствовать в <system.web>, с описанием их назначения. Данный список является далеко не полным и предназначен для предоставления лишь общей картины о масштабах конфигурации ASP.NET:

Архитектура конфигурационного файла является стандартом .NET, и приложения другого типа (например, приложения для Windows) тоже могут использовать конфигурационные файлы. По этой причине корневой элемент <configuration> не предназначен для параметров настройки веб-приложения. Вместо этого параметры настройки веб-приложения содержатся внутри выделенного раздела <system.web>.

Раздел <system.webServer>

В этом разделе содержатся параметры, которые оказывают влияние на веб-сервер. Элемент <handlers> внутри этого раздела используется для регистрации специальных обработчиков HTTP, а раздел <modules> — для регистрации модулей HTTP.

Раздел <appSettings>

Специальные параметры настройки в файле web.config добавляются в элемент <appSettings>. Все добавляемые специальные параметры записываются в виде простых строковых переменных.

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

Специальные параметры вводятся с использованием элемента <add>, который идентифицирует уникальное имя переменной (ключ) и ее содержимое (значение). Ниже приведен пример добавления двух новых специальных параметров настройки:

После добавления такой информации .NET позволяет чрезвычайно легко извлекать ее в коде веб-страниц. Все, что понадобится — это просто использовать класс WebConfigurationSettings, который находится в пространстве имен System.Web.Configuration. Этот класс предоставляет статическое свойство AppSettings, в котором содержится динамически генерируемая коллекция всех доступных в текущем каталоге параметров приложения.

Например, если класс страницы ASP.NET, ссылающийся на коллекцию AppSettings, находится в http://localhost/MyApp/MyDirectory/MySubdirectory, то в коллекции AppSettings, вероятно, будут содержаться параметры настройки из трех разных файлов web.config. Коллекция AppSettings делает такую иерархию параметров бесшовной для страницы, которая ее использует.

Для использования класса WebConfigurationSettings сначала необходимо импортировать пространство имен System.Web.Configuration, чтобы иметь возможность ссылаться на этот класс, не указывая его длинное полностью уточненное имя:

Далее останется просто извлечь требуемое значение по имени:

Ниже показана тестовая веб-страница в действии:

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

Значения, содержащиеся в элементе <appSettings> конфигурационного файла, доступны любому классу в приложении, а также любому компоненту, который в нем используется, будь то класс веб-формы, класс бизнес-логики, класс доступа к данным или что-нибудь еще. Во всех этих случаях класс ConfigurationSettings используется абсолютно одинаково.

Настройка веб-сервера из набора IIS, web.config, заголовки HTTP

Напомню, «IIS» (расшифровывается как «Internet Information Services») — это набор серверов для нескольких служб Интернета от компании «Microsoft». Набор серверов «IIS» включен в состав операционной системы «Windows 10 Pro», которая установлена на моём компьютере. Поэтому, собственно, я и стал пользоваться веб-сервером из этого набора. (Актуальная версия «IIS» — 10.0) Тут подробнее:

В предыдущем посте я писал, как начал пользоваться инструментом разработчика «Issues» в браузере «Microsoft Edge» на движке «Chromium».

И этот самый инструмент «Issues» выдал мне по поводу моей тестовой HTML-страницы следующее предупреждение (по-английски «Warning»):

‘content-type’ header charset value should be ‘utf-8’

Вернее, он выдал мне три таких предупреждения — одно по поводу моей HTML-страницы index.html , а еще два — по поводу двух файлов, подключенных к моей HTML-странице — файла style.css с определениями стилей на языке CSS и файла myscript.js со скриптом на языке JavaScript.

О чем идет речь в предупреждении? Обратим внимание на слово «header» (по-русски «заголовок») в тексте предупреждения. Что это за заголовок? Как оказалось, речь тут идет про так называемые «заголовки HTTP»:

Казалось бы, для HTML-страницы заголовки HTTP можно настраивать с помощью HTML-элемента meta (об этом сказано на вышеуказанной странице википедии). Например, в данном случае на первый взгляд кажется, что нужно вставить в заголовочную часть HTML-страницы следующее:

Однако, это в моём браузере не работает (кодировку HTML-страницы указывает, но на заголовок HTTP, отсылаемый веб-сервером из набора «IIS», не влияет). Почему? Во-первых, значение «content-type» атрибута http-equiv HTML-элемента meta считается устаревшим (об этом сказано, например, тут), вместо этого для указания кодировки HTML-страницы рекомендуют использовать следующее:

У меня на тестовой HTML-странице уже указан этот короткий вариант, поэтому дополнительное указание HTML-элемента meta с атрибутом http-equiv=»content-type» не требуется (будет считаться дублированием короткого варианта и об этом инструмент разработчика «Issues» браузера выдаст отдельное предупреждение).

Во-вторых (что более важно), как я понимаю (а я не специалист в этом вопросе, можно даже сказать, «чайник») веб-сервер из набора «IIS» вообще не учитывает, что там указано в коде HTML-страницы (возможно, веб-сервер можно как-то настроить, чтобы он учитывал HTML-элементы meta в коде отправляемой HTML-страницы, но я про такое не знаю).

Таким образом, очевидно, что для исправления вышеуказанного предупреждения от инструмента разработчика «Issues» браузера требуется настройка соответствующего заголовка HTTP, формируемого веб-сервером при отправке HTML-страницы (а также при отправке файлов, подключенных к этой HTML-странице).

* * *
Вообще, диалог между веб-сервером и браузером может служить удачной и достаточно простой иллюстрацией работы компьютерных сетей с архитектурой «клиент-сервер». В этом случае веб-сервер, соответственно, выполняет роль «сервера», а браузер выполняет роль «клиента». Оба конца этого диалога (сервер и клиент) являются компьютерными программами. Хотя часто сервером еще называют компьютер, на котором установлена программа (или несколько программ), выполняющая роль «сервера». Это создает некоторую путаницу в головах людей, изучающих компьютерные сети. Подробнее:

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

В рассматриваемом здесь случае веб-сервер из набора «IIS» и мой браузер (клиент) находятся на одном и том же моём компьютере, поэтому я здесь часто называю веб-сервер локальным веб-сервером. Это удобно для изучения, потому что оба участника сетевого диалога находятся под моим контролем, доступны для управления и экспериментов.

* * *
Итак, как произвести нужную мне настройку веб-сервера из набора «IIS»? Это можно сделать минимум двумя способами: 1) внести исправления напрямую в файл, в котором хранятся настройки веб-сервера; 2) открыть графический интерфейс веб-сервера и внести изменения в настройки веб-сервера через него, в результате чего эти настройки попадут в тот же файл, что при первом способе. Как я понимаю, результат при использовании любого из этих способов будет одинаковый.

Файлы настроек веб-сервера (как я понял) бывают разными: есть файлы настроек, которые действуют на все файлы, выдаваемые веб-сервером, а есть файлы настроек, которые действуют только на часть файлов, выдаваемых веб-сервером (например, только на файлы одного веб-сайта или на файлы, находящиеся в одном каталоге). Здесь я рассмотрю только последний случай, а именно я рассмотрю файл настроек веб-сервера, который называется web.config . Этот файл настроек действует только на файлы каталога, в котором он находится, в том числе на файлы, находящиеся во вложенных в текущий каталогах. Подробнее:

Что из себя представляет этот файл? Это текстовый файл, в котором с помощью разметки на языке XML описаны настройки веб-сервера. Правила написания этой разметки можно узнать в соответствующем справочнике:

Файлы моего локального веб-сайта находятся в следующем каталоге (я про это рассказывал в отдельном посте):

В этом каталоге изначально нет файла web.config , что значит, что на файлы в этом каталоге распространяются общие настройки веб-сервера.

Я поместил в этот каталог файл web.config со следующим содержанием:

Затем открыл в своём браузере адрес, который соответствует указанному выше каталогу:
и неожиданно получил сообщение об ошибке «HTTP 500.19 — Internal Server Error».

Почему произошла эта ошибка? Дело в том, что в настройках веб-сервера уже есть определения для трех указанных типов файлов (с расширениями .html , .css , .js ), а мой файл настроек web.config пытается добавить определения для этих же расширений файлов. Правила описания настроек веб-сервера запрещают определения mimeMap с одинаковыми атрибутами fileExtension .

Я этого не знал, поэтому решил попытаться внести нужные мне настройки через графический интерфейс веб-сервера из набора «IIS». Как открыть этот графический интерфейс? Как обычно, в операционной системе «Windows 10 Pro» это можно сделать кучей способов. Я открываю поиск (либо кликнув по иконке с увеличительным стеклом справа от кнопки «Пуск», либо нажав комбинацию клавиш Win+S) и набираю там «Диспетчер служб IIS», а затем открываю этот самый диспетчер.

В открывшемся окне «Диспетчера служб IIS» слева будет часть окна, озаглавленная «Подключения», и в ней будет отображено дерево подключений. В корне этого дерева у меня находится название моего компьютера. Если корень «развернуть», то там у меня открывается два пункта: «Пулы приложений» и «сайты». Я «развернул» пункт «сайты» и в нем оказался единственный сайт с названием «Default Web Site» (этот сайт, как я понимаю, был создан при включении набора «IIS», которое я описывал в отдельном посте). Это и есть сайт, который соответствует каталогу C:\inetpub\wwwroot\ (по умолчанию).

Я выбрал этот сайт, кликнув на него мышкой. После этого в центральной части окна и в правой части окна доступны возможные действия и настройки.

В центральной части окна диспетчера я кликнул мышкой на пункт «Типы MIME». Центральная часть окна диспетчера сменилась на окно выбранной функции. Но возникла ошибка из-за ошибки в написанном мной (см. выше) файле web.config . Я удалил этот файл и снова открыл пункт «Типы MIME». Теперь в центральной части окна диспетчера (теперь уже без ошибки) открылся большой список разнообразных расширений файлов.

Я нашел в этом списке три нужных мне расширения ( .html , .css , .js ) и добавил к определению каждого из этих расширений в графе «Тип MIME» текст ; charset=utf-8 .

После этого я заглянул в каталог моего сайта C:\inetpub\wwwroot\ и увидел, что там появился файл web.config , по-видимому, созданный диспетчером служб «IIS» в ответ на мои вышеописанные действия. Вот содержимое этого файла (я пометил красным цветом отличия от файла, написанного мной ранее):

То есть, если в списке расширений файлов, обрабатываемых веб-сервером, уже есть расширения, настройку обработки которых нужно изменить, то сначала удаляем «старые» определения, а затем добавляем «новые». Таким образом избегаем появления в списке расширений файлов дубликатов.

Оптимизация ASP.NET — практические советы по работе с IIS

В данной публикации речь пойдёт о настройке важных параметров пула ASP.NET-приложений при вызове удалённых веб-сервисов и активной работе с сетью на стороне сервера через стандартные классы .NET.

Введение

Приходилось ли вам когда-нибудь самим настраивать производственные веб-сервера (production servers) под управлением ОС Windows Server 2008 R2/IIS 7.5 и выше? Для системных администраторов, имеющих большой опыт работы с IIS, скорее всего, это тривиальная задача, но вот для веб-разработчиков, которым по различным причинам порой приходится самим участвовать в настройке «боевых» серверов, данная информация может оказаться весьма полезной.

Предыстория

В конце прошлого года в одной крупной организации мы столкнулись с проблемами производительности веб-серверов при резко увеличившейся пользовательской нагрузке. В веб-приложении на тот момент было зарегистрировано более 200 000 клиентов. В обычном режиме одновременно работает около 1000 пользователей, за день примерно 10-15% уникальных посетителей от общего числа зарегистрированных, поэтому нагрузка относительно невысокая. Однако существуют пиковые нагрузки, при которых система оказывается практически неработоспособной.

Веб-администаторы проверили всё, что можно, и никак не могли понять, в чём дело. Ведь несмотря на то, что по всем основным параметрам системы на физическом уровне с производительностью было всё хорошо, возникали сбои с доступностью сервисов, а в пуле собиралась огромная очередь запросов. В организации используется NLB-кластер на 4 узла (Windows Server 2008 R2 + IIS 7.5 + .NET 4.5), есть запас по загрузке ЦП и памяти, сетевые каналы большие, количество используемых портов достаточное. Все проверки указывали на то, что проблемы кроются в недрах IIS и настройке пула ASP.NET. Живой пример, когда администраторам не помешала бы помощь опытных веб-разработчиков…

1. Параметры конфигурации IIS

Начиная с IIS 7, все настройки конфигурации ASP.NET хранятся в XML-файлах (*.config). Они заменили метабазу, которая использовалась в IIS 6.0 и более ранних версиях.

Схема конфигурационных файлов для IIS 7.x и выше выглядит так:

Рис. 1. Схема конфигурационных файлов

На вершине иерархической конфигурации .NET находится файл machine.config. Он определяет глобальные параметры для конкретной машины. В этом файле определяются поддерживаемые разделы конфигурационных файлов, настраивается рабочий процесс ASP.NET и регистрируются поставщики различных модулей. Для оптимизации процесса инициализации файл machine.config был значительно упрощен, и он располагается в каталоге:

Здесь же находится файл machine.config.comments, который позволяет узнать, какие параметры используются по умолчанию. С помощью этих данных в machine.config можно добавить параметры с переопределенными значениями.

Корнем иерархии конфигурации ASP.NET является файл web.config, расположенный в том же каталоге, что и machine.config. Этот файл включает в себя параметры, которые используются для всех приложений ASP.NET.

• для 32-битной — %WINDIR%\System32\inetsrv\config\
• для 64-битной — %WINDIR%\SysWOW64\inetsrv\config\

Прежде чем начинать настройку конфигурации IIS, обратите внимание на счетчики производительности ASP.NET, оцените текущую и пиковую загрузки системы, зафиксируйте имеющиеся показатели. Проверьте логи на наличие ошибки “HTTP Error 503.2 — Service Unavailable”. Постарайтесь определить, не блокируется ли часть запросов в очереди.

Если производительность системы удовлетворяет потребностям заказчика, то лучше оставить параметры по умолчанию, ведь они рассчитаны для большинства ASP.NET приложений.

При конфигурации IIS можно выделить два основных параметра, влияющих на доступность приложения и его производительность.

1. Параметр appConcurrentRequestLimit — максимальное количество одновременных запросов в приложении. Увеличение числа одновременных запросов IIS расширит доступные ресурсы веб-сервера для обслуживания запросов. Значение по умолчанию — 5000.

Наиболее быстро изменить параметр appConcurrentRequestLimit можно утилитой appcmd.exe через командную строку. Сделать это можно как глобально для всех сайтов IIS через файл ApplicationHost.config, так и для отдельного сайта (приложения).

Выполняем команду, затем открываем в IIS раздел «Configuration Editor» для корневого каталога и проверяем новое значение установленного параметра appConcurrentRequestLimit. Причём здесь же можно вручную изменить это значение.

Рис. 2. Установка параметра appConcurrentRequestLimit

Для установки данного параметра наиболее часто используется формула:
<usersCount * 1.5>, где usersCount — количество одновременно работающих пользователей.

2. Параметр QueueLength — максимальное количество запросов, которые драйвер Http.sys размещает в очереди пула приложений. Когда очередь заполнена, новые запросы получают ошибку «503.2 — Service Unavailable». Значение по умолчанию — 5000.

• глобально для .NET на уровне сервера через machine.config, секция processModel/requestQueueLimit;
• на уровне IIS через ApplicationHost.config: system.web/httpRuntime -> appRequestQueueLimit;
• задать значение параметра queueLength для конкретного пула.

Выполняем команду, затем открываем в IIS раздел «Application Pools», выбираем в списке пул «DefaultAppPool », заходим в меню «Advanced Settings» и проверяем.

Рис. 3. Установка параметра queueLength

В диспетчере IIS выберите узел сервера в дереве, затем нажмите на иконку «Worker Processes»:

Рис. 4. Меню Worker Processes в диспетчере IIS

В появившемся списке вы можете видеть загрузку всех запущенных в текущий момент пулов.

Рис. 5. Просмотр работающих пулов через Worker Processes

При нажатии “View Current Request” появляется таблица со списком адресов обрабатываемых страниц и другими полезными параметрами. Для обновления списка можно нажимать F5 на экране. Таким образом, вы сможете найти «подвисшие» запросы:

Рис. 6. Список текущих запросов в пуле

Для просмотра показателей производительности, конечно, лучше использовать счётчики Performance Monitor, но они не покажут вам, как Requests Monitor, URL-адреса текущих запросов.

2. Настройка ASP.NET

ASP.NET ограничивает число рабочих потоков и потоков портов завершения вызова, используемых для выполнения запросов. Если веб-приложение на стороне сервера активно использует вызовы внешних веб-сервисов, стандартные классы из пространства имён System.NET для организации запросов по сети, то могут возникнуть конфликты низкой производительности и взаимоблокировок. Вначале часть запросов может просто “подвисать”, время выполнения будет значительно возрастать. В худшем случае, если используется классический режим настройки пула (classic pipeline), это вообще может привести к перезагрузке пула (recycle). Обнаружение взаимоблокировки ASP.NET не выполняется для пула, запущенного в integrated mode (по умолчанию в IIS 7 и выше).

Работа пулов приложений в интегрированном режиме имеет несколько преимуществ по сравнению с работой в классическом режиме. Рекомедуется запускать пулы приложений в integrated mode.

На рисунке ниже наглядно видно, как происходит обработка запросов в ASP.NET и какие параметры имеют наиболее важное значение:

Рис. 7. Процесс обработки запросов в ASP.NET

Для оптимальной работы веб-приложений по умолчанию включен режим автоконфигурации настроек пула. В этом случае, cвойство autoConfig равно «true» для секции <processModel> в файле machine.config, а другие ключевые параметры не заданы вообще.

• maxConnection
• maxWorkerThreads / minWorkerThreads
• maxIoThreads / minIoThreads
• minFreeThreads
• minLocalRequestFreeThreads

Таким образом, на сервере с 4-х ядерным процессором максимальное кол-во одновременных подключений к конечному IP-адресу равно 48=12*4 (по умолчанию).

Самый простой способ обойти данное ограничение — это прямо в коде своего ASP.NET приложения в методе Application_Start в файле global.asax указать следующее:

Более гибко настраивать maxconnection лучше через конфигурационные файлы на уровне домена приложения (web.config) или веб-сервера (applicationHost.config). Секция <system.net> содержит параметры, которые определяют, как .NET Framework подключается к сети.

Важно: Схема для адреса параметра maxconnection должна быть такой:

Увеличение maxconnection позволяет делать больше одновременных вызовов к удаленным сервисам. Этот атрибут не влияет на локальные вызовы веб-служб! Необходимо понимать, что недостаточно только обойти ограничение на количество одновременных подключений к сервису. Так как увеличение числа одновременных вызовов приводит к увеличению использования потоков CLR, которые используются для создания удаленных и обработки обратных вызовов.

ASP.NET через параметр maxWorkerThreads устанавливает ограничения потоков на рабочем процессе w3wp.exe (начиная с IIS 7). В связи с тем, что ASP.NET встроена в IIS, процессы ASP.NET формируют запросы на рабочих потоках. Из-за недостаточного количества потоков в CLR ThreadPool запросы будут становиться в очередь и “подвисать”.

Аттрибуты, заданные в секции <processModel>:
1. Параметр maxWorkerThreads — указывает максимальное количество рабочих потоков для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.

2. Параметр maxIoThreads — указывает максимальное количество потоков ввода/вывода для каждого процессора в пуле потоков среды CLR. Значение по умолчанию — 20. Максимальное значение — 100.

3. Параметр minWorkerThreads — указывает минимальное количество рабочих потоков для каждого процессора, которые могут быть предоставлены немедленно для обслуживания удаленного запроса. Значение по умолчанию — 1.

4. Параметр minIoThreads — указывает минимальное количество потоков ввода/вывода для каждого процессора, которые могут быть предоставлены немедленно для обработки обратного вызова. Значение по умолчанию — 1.

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

Аттрибуты, заданные в секции <httpRuntime>:
1. Параметр minFreeThreads — определяет количество потоков, которые могут быть использованы для работы, кроме обработки входящих запросов к рабочему процессу. Этот параметр не дает процессу ASP.NET использовать потоки из пула для обработки нового HTTP-запроса, если общее число потоков в пуле опустится ниже этого предела. Значение по умолчанию — 8.

2. Параметр minLocalRequestFreeThreads — определяет минимальное количество свободных потоков, которые ASP.NET держит доступными для выполнения новых локальных запросов. Значение по умолчанию — 4.

Обратите внимание, параметры maxWorkerThreads, minWorkerThreads, maxIoThreads, minIoThreads неявно умножаются на число процессоров, а параметры minFreeThreads и minLocalRequestFreeThreads — нет.

ASP.NET не будет выполнять более, чем следующее количество одновременных запросов:
(maxWorkerThreads * число ЦП) — minFreeThreads

Обратите внимание: на весь пул приложения, то есть на каждый рабочий процесс w3wp.exe, обслуживающий пул, имеется один пул потоков CLR ThreadPool. Для всех доменов приложений (сайтов), настроенных на один пул, используется общий набор потоков. Следовательно, для требовательных к ресурсам приложений лучше использовать отдельные пулы.

3. Рекомендации по оптимизации базовой конфигурации

Прежде всего, необходимо точно определить количество процессоров на веб-сервере. Как вариант, можно посмотреть TaskManager -> вкладка «Performance». Если процессор поддерживает режим HyperThreadingTechnology (HTT), значит половина ядер логические (Logical processors), а не физические (Cores). Например, при включенном режиме HTT процессор с 4-мя физическими ядрами будет работать как 8 логических ядер:

Рис. 8. Окно загрузки процессоров в TaskManager

Также можно попробовать воспользоваться следующими командами в командной строке:

или
Например, на сервере с 4-мя процессорами и свойством autoConfig ASP.NET будет иметь следующие параметры по умолчанию:
maxConnection – 48; maxWorkerThreads – 80; maxIoThreads – 80, minFreeThreads – 8, minLocalRequestFreeThreads – 4.

Если веб-страница на backend-части делает несколько сетевых вызовов для каждого запроса, то MSDN рекомендует использовать следующие настройки конфигурации:

1. maxWorkerThreads = 100 | minWorkerThreads = maxWorkerThreads / 2 = 50
2. maxIoThreads = 100
3. maxConnection = 12 * N
4. minFreeThreads = 88 * N
5. minLocalRequestFreeThreads = 76 * N, где N — количество процессоров.

Изменения в секцию <processModel> разрешено вносить только в файле machine.config из-за установленного там же атрибута allowDefinition при добавлении секции processModel.

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Machine.config:

Чтобы иметь возможность устанавливать значения секции processModel для каждого приложения в отдельности через web.config, необходимо установить свойство allowDefinition .

Важно: после внесения изменений требуется обновить Application pools.

Помните, что увеличивать данные параметры нужно только в случае необходимости при наличии достаточного количества ресурсов ЦП.

Для анализа производительности веб-серверов рекомендую настроить счётчики ASP.NET через Performance Monitor:

• ASP.NET Applications\Requests/Sec
• Web Service\ISAPI Extension Requests/sec
• ASP.NET\Requests Current
• ASP.NET\Requests Queued
• ASP.NET\ Requests Rejected
• ASP.NET Applications\Requests Executing
• ASP.NET Applications\Requests Timed Out
• ASP.NET\ Request Execution Time

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

Дополнительно

Для лучшего понимания работы IIS рекомендую ознакомиться, как происходит процесс обработки запроса от браузера пользователя до конечного пула приложения ASP.NET в этой полезной статье «Основы архитектуры IIS, или запросопровод для ASP.NET».

Если вы используете IIS8 — не будет лишним обратить внимание на «Полноценное регулирование нагрузки CPU (CPU Throttling)».

Заключение

Для сайтов, которые не совершают частые сетевые запросы на стороне сервера, стандартных настроек пула должно хватать (processModel/autoConfig=“true”). При этом IIS выставит ограничение в 20 рабочих потоков и 12 удаленных соединений на ядро. При превышении этих значений запросы начнут становиться в очередь и производительность веб-приложения упадёт.

Если ваш сайт работает хорошо и вы можете оценить предполагаемую нагрузку на систему, то не стоит ничего менять. Если же у вас начинаются “зависания” при обработке запросов к различным сервисам — не следует сразу винить во всем железо! Лучше внести изменения в базовую конфигурацию ASP.NET. Имейте в виду, что изменение базовых параметров пула приложений непременно приведёт к увеличению загрузки процессора. Оптимальная балансировка всех параметров системы — ключ к стабильной и производительной работе оборудования. Как говорится, “предупрежден — значит вооружен”.

Приглашаю всех поделиться вашим опытом настройки и оптимизации работы производственных веб-серверов на платформе Windows Server.

Web.config Guides

The web.config is a configuration file utilised by Windows servers to alter a websites functionality.

Create a web.config file

1. Open a text editor such as Notepad ++.

2. From the View menu, ensure that Word Wrap is unchecked.

3. Click File > Save As.

4. Set the file type to All Types.

5. Name the file web.config and click Save.

Uploading your web.config via Filezilla

1. If you do not have a copy already, download & install Filezilla.

2. Open Filezilla and connect to your ftp account.

3. From the left hand menu, open the directory that contains your web.config file.

4. From the right hand open the web directory you wish to upload the web.config file to.

Viewing the web.config in Filezilla

Web.config is a hidden file by default, so an FTP client must be configured to view hidden files in order to make future edits to the web.config file.

1. Open Filezilla and select Server > Force showing hidden files.

2. Your web.config will now be viewable in Filezilla.

Editing the web.config file in Filezilla

Once you have found the code you wish to implement in your web.config, you will need to place it into your file.

1. Open Filezilla and connect to your FTP account.

2. Navigate to the directory the contains your web.config file.

3. Right click the web.config file and select View/Edit to open the file in your default text editor.

4. Input the code you wish to implement on your domain and select File > Save.

5. Within Filezilla a window prompt will appear. Select Yes to upload the changes made to your web.config file to the server.

Web.config Useful Code

Web.config files can be used to alter the configuration of your accounts Windows Server.

Enabling Gzip in your web.config file

Gzip is a file format used for file compression and decompression. The most common text based files are HTML, CSS, XML and Javascript. The main thing about Gzip is that it helps to increase the speed of a website.

For example jquery-1.11.0.js uncompressed is 276 KB however with Gzip enabled it’s 82 KB, providing a compression of 70%. This can dramatically decrease the websites loading times and also helps you save bandwidth.

1. Create your web.config file.

2. Then add the following code:

The above code will compress text files, HTML, CSS , XML and JavaScript files.

Redirecting HTTP to HTTPS using web.config

1. Create your web.config file.

2. Place the following lines into your web.config file:

The above lines will ensure any request to a domain using http:// will be redirected to https://

Why redirect to HTTPS?

One of the reasons to redirect your visitors over to HTTPS is due to Google now using this as a ranking indicator. We cover this in greater detail in our Google’s new SSL ranking blog post.

Using HTTPS also provides visitors with another layer of security, encrypting their communication with the website. This is highly recommended when the data being sent to your website need to be handled in a secure way, this includes but isn’t limited to bank account details and login details.

Protecting WP-Admin using web.config

1. Find out what your IP address is. You can do this by using Pipe Ten’s IP lookup tool

2. Create your web.config file.

3. Once you have done that, insert this code inside the file:

Simply replace the IP Address 192.168.0.1 with your own IP address and upload it to your WP-Admin folder in your FTP. This will now allow you sole access to the WP-Admin page.

You can add more IP’s by copying line 6 and replacing the IP.

Beating the 250k web.config 250k limit

To help us split up our config files we will be using the configSource option within the web.config file, below is a very basic web.config which has it’s own file setup for the connection string:

Now as well as the web.config file, we also have a file named connections.config, this is where the connection string details are stored, an example of this can be seen below:

The above method can be used for the other sections of the web.config file as well.

Blocking referer link spam with web.config

Why would you block referer links?Most people have some form of analytics linked to their domain so they can see where their visitors are coming from. Spammers have now taken to using referer links to try getting you to visit their website.

Blocking the spam referer links

1. Create your web.config file.

2. Enter the following code:

The above web.config stops two example spam referer’s, the first one being domain.com and the second one being domain2.co.uk. The web.config also works for any subdomains for both of the domains.

A request that has one of the two domains as its referer link will get a 403 repose back from the server.

You can add new referer’s to the list by adding another line like the one below:

The following line would block referers from the domain domain3.org and any sub domains.

Caching static files with a web.config file

What to do

Enabling static file caching is very simple, all it requires is a few lines adding within the section of your web.config file. Below we have provided an example to cache the static content for 14 days:

You can set the cache max age to anything you would like, the key line and format can be seen below:

Why would you want to cache the static content for your domain?

When someone browses to your domain they have to download all its resources, this includes static web pages, images, any media clips etc. This happens each time they visit your domain and uses up bandwidth to do so, caching the static content helps prevent unneeded bandwidth usages

Is there any downside to caching your static content?

If your domains content changes frequently and you have set cacheControlMaxAge high this will cause people revisiting your site to possible see older content on your domain dude to the cache content.

Removing file extensions using a web.config file

In the following example we are going to be removing the .html extension from our pages. This can be edited, just change the text html on line 13 to your desired extension, eg, asp, aspx, php.

1. Create your web.config file.

2. Enter the following code:

That’s it, now your pages will be accessible without using the .html extension.

Using a web.config file to block IP addresses

1. Create your web.config file.

2. I will break this into 2 parts, blocking specific IP addresses and blocking all access and only allowing specific IP addresses.

• • • Blocking specific IP addresses
    1. 1. • Deny all, but allow specific IPs or networks

       Canonical (preferred) 301 redirect with a web.config file

       If your website can be reached from more than one URL, for example http://yourdomain.co.uk/home or http://home.yourdomain.co.uk, for SEO (Search Engine Optimisation) purposes it is better to just pick one of these URLs as the preferred way to access your website.

       1. Create your web.config file.

       2. Enter in the following code:

       3. Replace domain.com in the above code with your domain name and save within the configuration section of your web.config file.

       Adding MIME types to a web.config file

       Some media types require adding MIME types to your Web.config file to support playing. This is because this content is not served by IIS by default and needs to be added to support serving these.

       1. Create your web.config file.

       2. Enter in the following code:

       3. Between the two staticContent’s add your required MIME types. Please see the example below:

       Bad Bot Blocking

       This part of the guide will help show you how to prevent unwanted bots from crawling your site using your Web.config file .

       First, you’ll need to find or create your Web.config file over FTP using your preferred FTP client. Depending on your application, the code may look a little different, but should be able to be put in a similar place without being too dependent on which application you’re using.

       Place the code below towards the bottom of the <system.webServer> section of your Web.config file . You can see an example of where the intended location is in the screenshot below. This was performed on an Umbraco website, so the code may look a little different to your own.

       

       Once you’ve done this, upload your Web.config file with the new code within to your website’s root directory.

       You can add multiple lines of the <add input=”” pattern=”^NameofBotHere” /> code specifying different bot/crawler names if you have a problem with more than one.

       Testing the Bot is Blocked

       If you’re not sure whether the code is correct and doing what it should be doing, you can check this using a feature within popular web browsers that allows you to spoof your User Agent.

       The browser used in this example is Google Chrome and Chrome’s Dev Tools is what allows you to perform the testing.

       1. Open your web browser and browse to your website.

       2. In Chrome, press F12 or Ctrl + Shift + I to bring up the Dev Tools Console. If you’re on a device that runs MacOS , this would be Command(⌘) + Option(⌥) + I .

       3. Click on the three vertical dots shown in the image below above the Console to bring up some additional tools. Click on the Network conditions option.

       

       4. You’ll then be shown a menu where you can enable/disable Caching, Network Throttling or automatic User Agent selection. You’ll want to untick the Select automatically box to allow you to input your own User Agent.

       

       5. Once this has been unticked, you should be able to select a specific User Agent to use from the drop down menu. You’ll need to select Custom if you wish to input your own to replicate the bot you’re trying to block.

       

       6. After inputting your custom user agent you wish to test with, press Ctrl + F5 to perform a hard refresh of your website. This should show a 403 status code mentioning how access has been forbidden. If your site still loads or shows a 500 error, you will need to do some troubleshooting.

       

       This is a very good way to prevent bots/crawlers from taking up your bandwidth/traffic limits on your hosting account. Leaving this not monitored could cost you a hefty bill if not dealt with promptly. Blocking bad bots/crawlers is also a good security practice to ensure your site isn’t being crawled for vulnerabilities, as well as other information that can be used maliciously. This includes things such as email addresses, phone numbers and vulnerable form URLs.

       Classification: Public
       Last saved: 2021/07/29 at 14:37 by Jamie

       5

       «Fast Reliable HTTP2 Services»

       I’ve been thinking about making the jump to a private cloud server for some time due to the expense and the seemingly more complicated setup. The Pipe Ten team did the website transfers and setting up the domains as part of the optional support package. I am very pleased with the page speeds and the future-proof hardware.

       5

       «Helpful as always!»

       As always, a pleasure to deal with and more than accommodating to help us resolve our issues.

       Funbox Media Ltd — 06/01/2023

       5

       «The Guys were brilliant»

       The Guys were brilliant ! They supported me as a novice through the process with patience and understanding, cant thank them enough

       5

       «Domain Moving»

       Hi I recently had to move domain to new hosting within Pipe10 and then to install WordPress and upload a new site. Jamie at Pipe10 made this all so easy and supported me all the way. What might have been quite stressful was made comfortable with the help I got. Much appreciated.

       5

       «I’ve been using Pipe Ten’s services for over 16 years»

       I’ve been using Pipe Ten’s services for over 16 years and although I don’t need their support very often, they are always absolutely superb — answering even low priority support requests very quickly. Highly Recommend them

       5

       «Top level support»

       I recently needed to change a web domain from .uk to .com. I had no previous experience in this so it was quite daunting. The support member who was helping me, Jamie, provided great answers and guidance with my long list of questions. PipeTen support provided responsive and clear advice and I cannot recommend them enough.

       5

       «Pipe Ten Web Hosting Excellent Customer Service»

       I’ve used Pipe Ten for a number of years now for web hosting. I’ve found customer support has always been extremely good with numerous issues where I’ve needed help. Recently I’ve added a couple more domains and Jamie has been great sorting out the difficult installations of the Content Management System software I’m using. This is complex stuff for me. But once it’s installed I can usually build a satisfactory website. I have every confidence in Pipe Ten and find they are conscientious in working to find solutions. The ticket raising system and communication I have found to be excellent and well managed with very reasonable response times. A great company.

       5

       «Amazing customer service»

       Amazing customer service, really fast and patient

       5

       «These guys are amazing»

       These guys are amazing. Always so attentive and helpful, they understand the value of customer service, they look after their systems really well but without being obstructive, they just explain very well as to why things need to be done in a particular way to keep things secure. I’ve never felt patronised or an inconvenience like I have done with many hosting companies. I’ve been with them for many years now and I would still highly recommend them as one of the best.

       5

       «Excellent, stable, hosting provider»

       Used Pipeten for years and they’ve been the most stable hosting company I’ve ever used.