Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Служба IIS 10.0 входит в состав Windows Server 2022. В нем используется модель процессов, аналогичная модели процессов IIS 8.5 и IIS 7.0. Веб-драйвер в режиме ядра (http.sys) получает и направляет HTTP-запросы и удовлетворяет запросам из кэша ответов. Рабочие процессы регистрируются для подобластей URL, и http.sys перенаправляет запрос в соответствующий процесс (или набор процессов для пулов приложений).
HTTP.sys отвечает за управление подключениями и обработку запросов. Запрос может быть отдан из кэша HTTP.sys или передан в рабочий процесс для дальнейшей обработки. Можно настроить несколько рабочих процессов, что обеспечивает изоляцию по сниженной стоимости. Дополнительные сведения о том, как работает обработка запросов, см. на следующем рисунке:
HTTP.sys включает кэш ответа. Если запрос соответствует записи в кэше ответа, HTTP.sys отправляет ответ кэша непосредственно из режима ядра. Некоторые платформы веб-приложений, такие как ASP.NET, предоставляют механизмы, позволяющие кэшировать динамическое содержимое в кэше режима ядра. Обработчик статических файлов в IIS 10.0 автоматически кэширует часто запрашиваемые файлы в http.sys.
Так как веб-сервер имеет компоненты в режиме ядра и пользовательском режиме, оба компонента должны быть настроены для оптимальной производительности. Поэтому настройка IIS 10.0 для определенной рабочей нагрузки включает настройку следующих компонентов:
HTTP.sys и связанный кэш режима ядра
Рабочие процессы и службы IIS в пользовательском режиме, включая конфигурацию пула приложений
Некоторые параметры настройки, влияющие на производительность
В следующих разделах описывается настройка аспектов режима ядра и пользовательского режима IIS 10.0.
Параметры режима ядра
Параметры, связанные с производительностью HTTP.sys, делятся на две широкие категории: управление кэшем и подключение и управление запросами. Все параметры реестра хранятся в следующей записи реестра:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters
Заметка Если служба HTTP уже запущена, необходимо перезапустить ее, чтобы изменения вступили в силу.
Параметры управления кэшем
Одним из преимуществ HTTP.sys является кэш в режиме ядра. Если ответ находится в кэше режима ядра, вы можете полностью удовлетворить HTTP-запрос из режима ядра, что значительно снижает затраты ЦП на обработку запроса. Однако кэш в режиме ядра IIS 10.0 основан на физической памяти, а расход памяти на запись — это память, которую она занимает.
Запись в кэше полезна только в том случае, если она используется. Однако запись всегда потребляет физическую память, независимо от того, используется ли запись. Необходимо оценить полезность элемента в кэше (экономия от того, чтобы обслуживать его из кэша) и его затраты (занятая физическая память) за время существования записи, учитывая доступные ресурсы (ЦП и физическую память) и требования к рабочей нагрузке. HTTP.sys старается хранить в кэше только полезные, активно используемые элементы, но вы можете повысить производительность веб-сервера, настроив кэш HTTP.sys для конкретных рабочих нагрузок.
Ниже приведены некоторые полезные параметры для кэша режима ядра HTTP.sys.
UriEnableCache Значение по умолчанию: 1
Ненулевое значение включает ответ в режиме ядра и кэширование фрагментов. Для большинства рабочих нагрузок кэш должен оставаться включённым. Рассмотрите возможность отключения кэша, если ожидается очень низкий ответ и кэширование фрагментов.
UriMaxCacheMegabyteCount Значение по умолчанию: 0
Ненулевое значение, указывающее максимальную память, доступную для кэша в режиме ядра. Значение по умолчанию 0 позволяет системе автоматически настраивать объем памяти, доступный для кэша.
Заметка Указание размера устанавливает только максимальное значение, и система может не позволить кэшу увеличиваться до установленного максимального размера.
Â
UriMaxUriBytes Значение по умолчанию: 262144 байт (256 КБ)
Максимальный размер записи в кэше режима ядра. Ответы или фрагменты больше, чем это, не кэшируются. Если у вас достаточно памяти, попробуйте увеличить предел. Если объем памяти ограничен, а большие записи вытесниют меньшие, это может оказаться полезным для снижения предела.
UriScavengerPeriod Значение по умолчанию: 120 секунд
Кэш HTTP.sys периодически сканируется сборщиком мусора, и записи, к которым не обращаются между сканированиями сборщика, удаляются. Установка интервала скавенджера на большое значение уменьшает количество сканирований скавенджера. Однако использование памяти кэша может увеличиться, так как старые, менее часто доступные записи могут оставаться в кэше. Установка слишком низкого периода приводит к более частым сканированиям скавенгера и может вызывать повышенную частоту сбросов, а также нестабильность кэша.
Параметры управления запросами и подключениями
В Windows Server 2022 HTTP.sys автоматически управляет подключениями. Следующие параметры реестра больше не используются:
МаксСоединения
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnections
IdleConnectionsHighMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMark
IdleConnectionsLowMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMark
IdleListTrimmerPeriod (Период бездействия)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriod
RequestBufferLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepth
InternalRequestLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\InternalRequestLookasideDepth
Параметры пользовательского режима
Параметры в этом разделе влияют на поведение рабочих процессов IIS 10.0. Большинство этих параметров можно найти в следующем XML-файле конфигурации:
%SystemRoot%\system32\inetsrv\config\applicationHost.config
Используйте Appcmd.exe, консоль управления IIS 10.0, WebAdministration или командлеты PowerShell IISAdministration, чтобы изменить настройки. Большинство параметров обнаруживаются автоматически и не требуют перезапуска рабочих процессов IIS 10.0 или сервера веб-приложений. Дополнительные сведения о файле applicationHost.config см. в разделе "Общие сведения о ApplicationHost.config".
Идеальный параметр ЦП для оборудования NUMA
Начиная с Windows Server 2016, IIS 10.0 поддерживает автоматическое оптимальное распределение ЦП для потоков пула задач, что повышает производительность и масштабируемость на архитектуре NUMA. Эта функция включена по умолчанию и может быть настроена с помощью следующего ключа реестра:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu
С включенной функцией диспетчер потоков IIS делает все возможное, чтобы равномерно распределять потоки пула потоков IIS по всем ЦП во всех узлах NUMA на основе их текущих загрузок. Как правило, рекомендуется сохранить этот параметр по умолчанию без изменений для оборудования NUMA.
Заметка Идеальный параметр ЦП отличается от параметров назначения узла NUMA рабочего процесса (numaNodeAssignment и numaNodeAffinityMode), представленных в параметрах ЦП для пула приложений. Идеальный параметр ЦП влияет на распределение потоков пула потоков IIS, а параметры назначения узла NUMA рабочего процесса определяют, на каком узле NUMA запускается рабочий процесс.
Параметры поведения кэша в режиме пользователя
В этом разделе описаны параметры, влияющие на поведение кэширования в IIS 10.0. Кэш пользовательского режима реализуется как модуль, который прослушивает глобальные события кэширования, создаваемые интегрированным конвейером. Чтобы полностью отключить кэш пользовательского режима, удалите модуль FileCacheModule (cachfile.dll) из списка установленных модулей в разделе конфигурации system.webServer/globalModules в applicationHost.config.
system.webСервер/кэширование
Свойство | Описание | По умолчанию |
---|---|---|
Включен | Отключает кэш IIS в пользовательском режиме, если задано значение False. Если скорость попадания кэша очень мала, можно полностью отключить кэш, чтобы избежать затрат, связанных с путем кода кэша. Отключение кэша пользовательского режима не отключает кэш режима ядра. | Верно |
Включить кеш ядра | Отключает кэш режима ядра при значении False. | Верно |
максимальный размер кеша | Ограничивает размер кэша в пользовательском режиме IIS указанным размером в Мегабайтах. IIS настраивает значение по умолчанию в зависимости от доступной памяти. Тщательно выбирайте значение в зависимости от размера набора часто используемых файлов по сравнению с объемом ОЗУ или адресным пространством процесса IIS. | 0 |
максимальный размер ответа | Кэширует файлы до указанного размера. Фактическое значение зависит от количества и размера крупнейших файлов в наборе данных и доступной ОЗУ. Кэширование больших, часто запрашиваемых файлов может снизить использование ЦП, доступ к диску и связанные задержки. | 262144 |
Параметры поведения сжатия
IIS начиная с версии 7.0 сжимает статическое содержимое по умолчанию. Кроме того, сжатие динамического содержимого включено по умолчанию при установке DynamicCompressionModule. Сжатие уменьшает использование пропускной способности, но увеличивает использование ЦП. Сжатое содержимое кэшируется в кэше режима ядра, если это возможно. Начиная с версии 8.5 служба IIS позволяет управлять сжатием независимо для статического и динамического содержимого. Статическое содержимое обычно относится к содержимому, которое не изменяется, например GIF-файлы или HTM. Динамическое содержимое обычно создается скриптами или кодом на сервере, то есть ASP.NET страницами. Вы можете настроить классификацию любого конкретного расширения как статического или динамического.
Чтобы полностью отключить сжатие, удалите StaticCompressionModule и DynamicCompressionModule из списка модулей в разделе system.webServer/globalModules в applicationHost.config.
system.webServer/httpCompression
Свойство | Описание | По умолчанию |
---|---|---|
статическое_сжатие-Включить_ИспользованиеЦП staticCompression-ОтключитьИспользованиеЦП ДинамическоеСжатие-ВключитьИспользованиеЦП ОтключитьИспользованиеЦП-дляДинамическогоСжатия |
Включает или отключает сжатие, если текущее процентное использование ЦП превышает или ниже указанных ограничений. Начиная с IIS 7.0, сжатие автоматически отключается, если нагрузка на ЦП в устойчивом состоянии превышает порог отключения. Сжатие включено, если ЦП снижается ниже порогового значения включения. |
50, 100, 50 и 90 соответственно |
каталог | Указывает каталог, в котором сжатые версии статических файлов временно хранятся и кэшируются. При частом доступе к этому каталогу рекомендуется переместить этот каталог с системного диска. | %SystemDrive%\inetpub\temp\IIS Временные сжатые файлы |
Ограничение места на диске | Указывает, существует ли ограничение для объема дискового пространства всех сжатых файлов. Сжатые файлы хранятся в каталоге сжатия, указанном атрибутом каталога . | Верно |
максимальное использование дискового пространства | Указывает количество байтов места на диске, которое сжатые файлы могут занимать в каталоге сжатия. Этот параметр может потребоваться увеличить, если общий размер всего сжатого содержимого слишком велик. |
100 МБ |
system.webServer/urlCompression
Свойство | Описание | По умолчанию |
---|---|---|
DoStaticCompression | Указывает, сжимается ли статическое содержимое. | Верно |
doDynamicCompression | Указывает, сжимается ли динамическое содержимое. | Верно |
Замечание
Для серверов, работающих под управлением IIS 10.0 с низким уровнем среднего использования ЦП, рекомендуется включить сжатие динамического содержимого, особенно если ответы большие. Сначала это необходимо сделать в тестовой среде, чтобы оценить влияние на использование ЦП от исходного уровня.
Настройка списка документов по умолчанию
Модуль документов по умолчанию обрабатывает HTTP-запросы для корневого каталога и преобразует их в запросы для определенного файла, например Default.htm или Index.htm. В среднем около 25 процентов всех запросов в Интернете проходит через стандартный путь документа. Это значительно зависит от отдельных сайтов. Если HTTP-запрос не указывает имя файла, модуль документов по умолчанию ищет список разрешенных документов по умолчанию для каждого имени в файловой системе. Это может негативно повлиять на производительность, особенно если достичь содержимого требуется выполнить круговую поездку по сети или коснуться диска.
Вы можете избежать накладных расходов, выборочно отключив документы по умолчанию и уменьшая или упорядочив список документов. Для веб-сайтов, использующих документ по умолчанию, необходимо уменьшить список до только используемых типов документов по умолчанию. Кроме того, упорядочьте список так, чтобы он начинался с наиболее часто используемого имени файла документа по умолчанию.
Вы можете выборочно задать поведение документа по умолчанию для определенных URL-адресов, настроив конфигурацию внутри тега расположения в applicationHost.config или вставив файл web.config непосредственно в каталог содержимого. Это позволяет использовать гибридный подход, который позволяет использовать документы по умолчанию только в тех случаях, когда они необходимы, и задает список правильным именем файла для каждого URL-адреса.
Чтобы полностью отключить документы по умолчанию, удалите DefaultDocumentModule из списка модулей в разделе system.webServer/globalModules в applicationHost.config.
system.webServer/defaultDocument
Свойство | Описание | По умолчанию |
---|---|---|
Активирован | Указывает, что использование документов по умолчанию разрешено. | Верно |
элемент <files> |
Указывает имена файлов, настроенные в качестве документов по умолчанию. | Список по умолчанию — Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htmи Default.aspx. |
Центральное двоичное логирование
Если в сеансе сервера есть множество групп URL-адресов, процесс создания сотен форматированных файлов журнала для отдельных групп URL-адресов и записи данных журнала на диск может быстро использовать ценные ресурсы ЦП и памяти, тем самым создавая проблемы с производительностью и масштабируемостью. Централизованное двоичное ведение журнала сводит к минимуму объем системных ресурсов, используемых для ведения журнала, в то же время предоставляя подробные данные журнала для организаций, которым это требуется. Для анализа журналов двоичного формата требуется средство последующей обработки.
Вы можете включить централизованное двоичное ведение журнала, задав для атрибута centralLogFileMode значение CentralBinary и установив атрибут enabled в значение True. Рекомендуется переместить расположение центрального файла журнала с системного раздела и на выделенный диск ведения журнала, чтобы избежать конфликтов между действиями системы и действиями ведения журнала.
system.applicationHost/лог
Свойство | Описание | По умолчанию |
---|---|---|
centralLogFileMode | Задает режим ведения журнала для сервера. Измените это значение на CentralBinary, чтобы включить централизованное двоичное ведение журнала. | Место |
system.applicationHost/log/centralBinaryLogFile
Свойство | Описание | По умолчанию |
---|---|---|
Активирован | Указывает, включено ли центральное двоичное ведение журнала. | Неправда |
каталог | Указывает каталог, в котором записываются записи журнала. | %SystemDrive%\inetpub\logs\LogFiles |
Настройка приложений и сайтов
Следующие параметры относятся к пулу приложений и настройке сайта.
system.applicationHost/applicationPools/applicationPoolDefaults
Свойство | Описание | По умолчанию |
---|---|---|
длина очереди | Указывает HTTP.sys, сколько запросов находятся в очереди для пула приложений, прежде чем последующие запросы будут отклонены. При превышении значения этого свойства IIS отклоняет последующие запросы с ошибкой 503. Рекомендуется увеличить это для приложений, которые взаимодействуют с внутренними хранилищами данных с высокой задержкой, если наблюдается ошибка 503. |
1000 |
enable32BitAppOnWin64 | Если значение True, позволяет 32-разрядному приложению работать на компьютере с 64-разрядным процессором. Рекомендуется включить 32-разрядный режим, если потребление памяти является проблемой. Поскольку размеры указателей и размер инструкций меньше, 32-разрядные приложения используют меньше памяти, чем 64-разрядные приложения. Недостаток работы 32-разрядных приложений на 64-разрядном компьютере заключается в том, что адресное пространство в режиме пользователя ограничено 4 ГБ. |
Неправда |
system.applicationHost/sites/VirtualDirectoryDefault
Свойство | Описание | По умолчанию |
---|---|---|
allowSubDirConfig | Указывает, ищут ли службы IIS файлы типа web.config в каталогах содержимого ниже текущего уровня (True), или не ищут файлы типа web.config в каталогах содержимого ниже текущего уровня (False). Введя простое ограничение, которое разрешает настройку только в виртуальных каталогах, IIS 10.0 может знать, что, если только параметр /<name>.htm не является виртуальным каталогом, он не должен искать файл конфигурации. Пропуск дополнительных операций с файлами может значительно повысить производительность веб-сайтов с очень большим набором статического содержимого. | Верно |
Управление модулями IIS 10.0
IIS 10.0 была разбита на несколько модулей, которые можно расширять пользователями, чтобы поддерживать модульную структуру. Эта факторизация имеет небольшую стоимость. Для каждого модуля интегрированный конвейер должен вызывать модуль для каждого события, соответствующего модулю. Это происходит независимо от того, должен ли модуль выполнять любую работу. Вы можете сохранить циклы ЦП и память, удалив все модули, которые не относятся к конкретному веб-сайту.
Веб-сервер, настроенный для простых статических файлов, может включать только следующие пять модулей: UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule и HttpLoggingModule.
Чтобы удалить модули из applicationHost.config, удалите все ссылки на модуль из разделов system.webServer/handlers и system.webServer/modules в дополнение к удалению объявления модуля в system.webServer/globalModules.
Классические параметры ASP
Основная стоимость обработки классического запроса ASP включает инициализацию обработчика скриптов, компиляцию запрошенного скрипта ASP в шаблон ASP и выполнение шаблона в обработчике скриптов. Хотя стоимость выполнения шаблона зависит от сложности ASP-скрипта, классический модуль ASP IIS может кэшировать движки скриптов в памяти и кэшировать шаблоны как в памяти, так и на диске (только если произойдет переполнение кеша шаблонов в памяти) для повышения производительности в сценариях, ограниченных ЦП.
Следующие параметры используются для настройки классического кэша шаблонов ASP и кэша обработчика скриптов, и они не влияют на параметры ASP.NET.
system.webServer/asp/cache
Свойство | Описание | По умолчанию |
---|---|---|
diskTemplateCacheDirectory | Имя каталога, который ASP использует для хранения скомпилированных шаблонов при переполнении кэша в памяти. Рекомендация: Установите каталог, который не сильно используется, например на диск, который не совместно используется с операционной системой, журналами IIS или другим часто используемым содержимым. |
%SystemDrive%\inetpub\temp\ASP Скомпилированные шаблоны |
Параметр maxDiskTemplateCacheFiles (максимальное количество файлов шаблонов кэша диска) | Указывает максимальное количество скомпилированных шаблонов ASP, которые можно кэшировать на диске. Рекомендация. Задайте максимальное значение 0x7FFFFFFF. |
2000 |
scriptFileCacheSize (размер кэша файлов скрипта) | Этот атрибут указывает максимальное количество скомпилированных шаблонов ASP, которые можно кэшировать в памяти. Рекомендация: Установите как минимум столько, сколько составляет число часто запрашиваемых скриптов ASP, обрабатываемых пулом приложений. Если возможно, установите максимально возможное количество шаблонов ASP в соответствии с ограничениями памяти. |
500 |
scriptEngineCacheMax | Указывает максимальное количество скриптовых движков, которые будут держать в кэше в памяти. Рекомендация: Установите как минимум столько, сколько составляет число часто запрашиваемых скриптов ASP, обрабатываемых пулом приложений. Если это возможно, установите столько обработчиков скриптов, насколько позволяет ограничение памяти. |
250 |
system.webServer/asp/limits
Свойство | Описание | По умолчанию |
---|---|---|
максимум потока процессора | Указывает максимальное количество рабочих потоков на процессор, которые может создать ASP. Увеличьте, если текущий параметр недостаточно для обработки нагрузки, что может привести к ошибкам при обслуживании запросов или возникновении недостаточного использования ресурсов ЦП. | двадцать пять |
system.webServer/asp/comPlus
Свойство | Описание | По умолчанию |
---|---|---|
executeInMta | Установите значение True, если обнаружены ошибки или сбои во время обслуживания ASP-контента в IIS. Это может произойти, например, при размещении нескольких изолированных сайтов, в которых каждый сайт выполняется в рамках собственного рабочего процесса. Ошибки обычно регистрируются из COM+ в Просмотре событий. Этот параметр включает многопотоковую модель квартиры в ASP. | Неправда |
параметр параллелизма ASP.NET
ASP.NET 3.5
По умолчанию ASP.NET ограничивает параллелизм запросов, чтобы уменьшить потребление памяти устойчивого состояния на сервере. Приложения с высокой параллелизмом могут потребоваться изменить некоторые параметры, чтобы повысить общую производительность. Этот параметр можно изменить в файле aspnet.config:
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>
Следующий параметр полезен для полного использования ресурсов в системе:
maxConcurrentRequestPerCpu Значение по умолчанию: 5000
Этот параметр ограничивает максимальное количество одновременных выполнения запросов ASP.NET в системе. Значение по умолчанию является консервативным для уменьшения потребления памяти ASP.NET приложениями. Рассмотрите возможность увеличения этого ограничения в системах, работающих с приложениями, выполняющими длительные синхронные операции ввода-вывода. В противном случае пользователи могут столкнуться с высокой задержкой из-за сбоев очереди или запросов из-за превышения ограничений очереди при высокой нагрузке при использовании параметра по умолчанию.
ASP.NET 4.6
Помимо параметра maxConcurrentRequestPerCpu, ASP.NET 4.7 также предоставляет параметры для повышения производительности в приложениях, которые сильно зависят от асинхронной операции. Параметр можно изменить в файле aspnet.config.
<system.web>
<applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>
- percentCpuLimit Значение по умолчанию: 90 асинхронных запросов имеют некоторые проблемы масштабируемости, когда огромная нагрузка (за пределами аппаратных возможностей) помещается в такой сценарий. Проблема связана с характером выделения в асинхронных сценариях. В этих условиях выделение будет происходить при запуске асинхронной операции, и выделенные ресурсы будут использоваться при завершении. К тому времени весьма вероятно, что объекты будут перемещены в поколение 1 или 2 с помощью GC. Когда это произойдет, увеличение нагрузки будет отображаться на запросе в секунду (rps) до точки. Когда мы пройдем этот момент, время, затраченное в GC, начнет стать проблемой, и rps начнет падать, имея негативный эффект масштабирования. Чтобы устранить проблему, когда загрузка ЦП превышает параметр percentCpuLimit, запросы будут отправляться во встроенную очередь ASP.NET.
- percentCpuLimitMinActiveRequestPerCpu Значение по умолчанию: регулирование ЦП 100 (параметр percentCpuLimit) не зависит от количества запросов, но насколько дорогими они являются. В результате может быть всего несколько запросов, требующих большого объема вычислительных ресурсов ЦП, что приводит к скапливанию в собственной очереди без возможности освободить её, кроме как за счет поступающих запросов. Чтобы решить эту проблему, можно использовать процентCpuLimitMinActiveRequestPerCpu, чтобы обеспечить минимальное количество запросов перед регулированием.
Варианты рабочего процесса и переработки
Можно настроить параметры для повторного использования рабочих процессов IIS и предоставить практические решения для острых ситуаций или событий, не требуя вмешательства или сброса службы или компьютера. Такие ситуации и события включают утечки памяти, увеличение нагрузки памяти или неответствующие или неактивные рабочие процессы. В обычных условиях варианты переработки могут не потребоваться, и повторное использование может быть отключено или система может быть настроена для переработки очень редко.
Вы можете включить переработку процессов для конкретного приложения, добавив атрибуты в элемент recycling/periodicRestart . Событие перезапуска может быть активировано несколькими событиями, включая использование памяти, фиксированное количество запросов и фиксированный период времени. При перезапуске рабочего процесса очереди и выполнения запросов удаляются, а новый процесс одновременно запускается для обслуживания новых запросов. Элемент recycling/periodicRestart является для каждого приложения, что означает, что каждый атрибут в следующей таблице секционируется на основе каждого приложения.
system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart
Свойство | Описание | По умолчанию |
---|---|---|
память | Включите повторное использование процесса, если потребление виртуальной памяти превышает указанное ограничение в килобайтах. Это полезный параметр для 32-разрядных компьютеров с небольшим адресным пространством в 2 ГБ. Это может помочь избежать неудачных запросов из-за ошибок вне памяти. | 0 |
частная память | Включите повторное использование процесса, если выделение частной памяти превышает указанное ограничение в килобайтах. | 0 |
Запросы | Включите перезапуск процессов после определенного количества запросов. | 0 |
Время | Включите повторное использование процесса после указанного периода времени. | 29:00:00 |
Динамическая настройка выгрузки страниц рабочего процесса
Начиная с Windows Server 2012 R2, в IIS появилась возможность настроить приостановку рабочего процесса после его простоя в течение некоторого времени (в дополнение к возможности завершения, которая существовала начиная с IIS 7).
Основная цель как выгрузки памяти неактивных рабочих процессов, так и завершения неактивных рабочих процессов заключается в экономии использования памяти на сервере, поскольку сайт может потреблять много памяти даже в состоянии ожидания. В зависимости от технологии, используемой на сайте (статическое содержимое, ASP.NET или другие платформы), используемая память может варьироваться от 10 МБ до сотен МБ, и это означает, что если ваш сервер настроен на работу с несколькими сайтами, определение наиболее эффективных параметров для них значительно повысит производительность как активных, так и приостановленных сайтов.
Прежде чем переходить к подробностям, мы должны помнить, что если нет ограничений по памяти, то, вероятно, лучше всего просто установить сайты так, чтобы их никогда не приостанавливать или не завершать. В конце концов, мало смысла в завершении рабочего процесса, если он единственный на машине.
Замечание
В случае, если сайт запускает неустойчивый код, например, код с утечкой памяти или иным образом неустойчивый, настройка завершения сайта при простое может быть быстрой и простой альтернативой исправлению ошибки кода. Это не то, что мы будем поощрять, но в критической ситуации может быть лучше использовать эту функцию в качестве механизма очистки, в то время как более постоянное решение находится в разработке.
Еще один фактор, который следует учитывать, заключается в том, что если сайт использует много памяти, то сам процесс приостановки может создавать нагрузку, поскольку компьютеру приходится записывать на диск данные, используемые в рабочем процессе. Если рабочий процесс использует большой фрагмент памяти, то приостановка может оказаться более дорогой, чем затраты на запуск резервного копирования.
Чтобы лучше всего использовать функцию приостановки рабочего процесса, необходимо просмотреть сайты в каждом пуле приложений и решить, какой должен быть приостановлен, который должен быть завершен, и который должен быть активным на неопределенный срок. Для каждого действия и каждого сайта необходимо определить идеальный период времени ожидания.
В идеале, те сайты, которые вы настроите на приостановку или прекращение, это те, у которых есть посетители каждый день, но их недостаточно, чтобы оправдать держать его активным всё время. Обычно это сайты с около 20 уникальных посетителей в день или меньше. Вы можете проанализировать шаблоны трафика с помощью файлов журнала сайта и вычислить средний ежедневный трафик.
Помните, что когда конкретный пользователь подключается к сайту, он обычно остается на нем по крайней мере некоторое время, делая дополнительные запросы, и поэтому просто подсчет ежедневных запросов может не точно отражать реальные шаблоны трафика. Чтобы получить более точное чтение, можно также использовать средство, например Microsoft Excel, для вычисления среднего времени между запросами. Рассмотрим пример.
Номер | URL-адрес запроса | Время запроса | Дельта |
---|---|---|---|
1 | /SourceSilverLight/Geosource.web/grosource.html | 10:01 | |
2 | /SourceSilverLight/Geosource.web/sliverlight.js | 10:10 | 0:09 |
3 | /SourceSilverLight/Geosource.web/clientbin/geo/1.aspx | 10:11 | 0:01 |
4 | /lClientAccessPolicy.xml | 10:12 | 0:01 |
5 | / SourceSilverLight/GeosourcewebService/Service.asmx | 10:23 | 0:11 |
6 | / SourceSilverLight/Geosource.web/GeoSearchServer… | 11:50 | 1:27 |
7 | /rest/Services/CachedServices/Silverlight_load_la...| | 12:50 | 1:00 |
8 | /rest/Services/CachedServices/Silverlight_basemap...|. | 12:51 | 0:01 |
9 | /rest/Services/DynamicService/ Silverlight_basemap...¦. | 12:59 | 0:08 |
10 | /rest/Services/CachedServices/Ortho_2004_cache.as... | 13:40 | 0:41 |
11 | /rest/Services/CachedServices/Ortho_2005_cache.js | 13:40 | 0:00 |
12 | /rest/Services/CachedServices/OrthoBaseEngine.aspx | 13:41 | 0:01 |
Однако трудность заключается в том, чтобы выяснить, какой параметр применить, чтобы всё было логично. В нашем случае сайт получает кучу запросов от пользователей, а в таблице выше показано, что в течение 4 часов произошло всего 4 уникальных сеанса. С параметрами по умолчанию для приостановки рабочего процесса пула приложений сайт будет завершен после истечения времени ожидания по умолчанию в 20 минут, что означает, что каждый из этих пользователей будет испытывать процесс загрузки сайта. Это делает его идеальным кандидатом на приостановку рабочего процесса, так как в течение большей части времени сайт неактивен, и поэтому приостановка будет сохранять ресурсы, и позволить пользователям добраться до сайта почти мгновенно.
Последнее и очень важное примечание об этом заключается в том, что производительность диска имеет решающее значение для этой функции. Так как процесс приостановки и пробуждения включает запись и чтение большого объема данных на жестком диске, настоятельно рекомендуется использовать быстрый диск для этого. Твердотельные накопители (SSD) идеально подходят и настоятельно рекомендуется для этого, и вы должны убедиться, что файл страницы Windows хранится на нем (если операционная система не установлена на SSD, настройте операционную систему для перемещения файла страницы в него).
Независимо от того, используется ли ssd или нет, мы также рекомендуем исправить размер файла страницы, чтобы разместить данные на странице без изменения размера файла. Изменение размера файла страницы может произойти, когда операционная система должна хранить данные в файле страницы, так как по умолчанию Windows настраивается для автоматической настройки размера на основе необходимости. Установив фиксированный размер, можно предотвратить изменение габаритов и значительно повысить производительность.
Чтобы настроить предварительно фиксированный размер файла страницы, необходимо вычислить его идеальный размер, который зависит от количества сайтов, которые будут приостановлены, и сколько памяти они используют. Если среднее значение составляет 200 МБ для активного рабочего процесса и у вас есть 500 сайтов на серверах, которые будут приостановлены, файл страницы должен быть по крайней мере (200 * 500 МБ) в базовом размере файла страницы (поэтому базовый + 100 ГБ в нашем примере).
Замечание
Когда сайты приостановлены, они будут потреблять около 6 МБ каждый, поэтому в нашем случае использование памяти, если все сайты приостановлены, будет около 3 ГБ. В действительности, однако, вы, вероятно, никогда не будете иметь их всех приостановленными одновременно.
Параметры настройки безопасности транспортного уровня
Использование протокола TLS накладывает дополнительные затраты на ЦП. Самым дорогим компонентом TLS является стоимость установления сеанса, так как она включает полный протокольный обмен. Повторное подключение, шифрование и расшифровка также добавляются в стоимость. Для повышения производительности TLS сделайте следующее:
Включите HTTP keep-alives для сеансов TLS. Это устраняет затраты на создание сеанса.
Повторно используйте сеансы при необходимости, особенно с трафиком без поддержки keep-alive.
Выборочно примените шифрование только к страницам или частям сайта, которым он нужен, а ко всему сайту.
Замечание
- Более крупные ключи обеспечивают большую безопасность, но они также используют больше времени ЦП.
- Все компоненты могут не быть зашифрованы. Однако сочетание обычного HTTP и HTTPS может привести к всплывающему предупреждению о том, что не все содержимое на странице безопасно.
Интерфейс программирования приложений Internet Server (ISAPI)
Для приложений ISAPI не требуются специальные параметры настройки. Если вы напишете собственное расширение ISAPI, убедитесь, что оно оптимизировано для производительности и использования ресурсов.
Рекомендации по оптимизации управляемого кода
Интегрированная модель конвейера в IIS 10.0 обеспечивает высокую степень гибкости и расширяемости. Пользовательские модули, реализованные в машинном или управляемом коде, можно вставить в конвейер или заменить существующие модули. Хотя эта модель расширяемости обеспечивает удобство и простоту, следует проявлять осторожность, прежде чем вставлять новые управляемые модули, которые подключаются к глобальным событиям. Добавление глобального управляемого модуля означает, что все запросы, включая статические запросы файлов, должны касаться управляемого кода. Пользовательские модули уязвимы для таких событий, как сборка мусора. Кроме того, пользовательские модули значительно увеличивают затраты на процессор из-за маршалинга данных между нативным и управляемым кодом. Если это возможно, необходимо задать предусловие managedHandler для управляемого модуля.
Чтобы повысить производительность холодного запуска, убедитесь, что вы предварительно компилируйте веб-сайт ASP.NET или используете функцию инициализации приложений IIS для прогревания приложения.
Если состояние сеанса не требуется, отключите его для каждой страницы.
Если существует много связанных операций ввода-вывода, попробуйте использовать асинхронную версию соответствующих API, что обеспечит вам гораздо лучшую масштабируемость.
Кроме того, использование кэша выходных данных также повышает производительность веб-сайта.
При запуске нескольких узлов, содержащих скрипты ASP.NET в изолированном режиме (один пул приложений на сайт), отслеживайте использование памяти. Убедитесь, что на сервере достаточно ОЗУ для ожидаемого количества одновременных пулов приложений. Рекомендуется использовать несколько доменов приложений вместо нескольких изолированных процессов.
Другие проблемы, влияющие на производительность IIS
Следующие проблемы могут повлиять на производительность IIS:
Установка фильтров, которые не относятся к кэшу
Установка фильтра, не поддерживающего http-кэш, приводит к тому, что службы IIS полностью отключают кэширование, что приводит к снижению производительности. Фильтры ISAPI, написанные до IIS 6.0, могут привести к этому поведению.
Общие запросы интерфейса шлюза (CGI)
По соображениям производительности использование приложений CGI для обслуживания запросов не рекомендуется использовать в IIS. Часто создавайте и удаляя процессы CGI включает значительные затраты. Лучшие варианты включают использование скриптов приложений FastCGI, сценариев приложений ISAPI и ASP или ASP.NET скриптов. Изоляция доступна для каждого из этих вариантов.