Ajuste do IIS 10.0
O IIS (Serviços de Informações da Internet) 10.0 está incluído no Windows Server 2022. Ele usa um modelo de processo semelhante ao do IIS 8.5 e do IIS 7.0. Um driver Web no modo kernel (HTTP.sys) recebe e roteia as solicitações HTTP e atende às solicitações no cache de resposta. Os processos de trabalho se registram nos subespaços de URL e o HTTP.sys roteia a solicitação para o processo apropriado (ou o conjunto de processos para pools de aplicativos).
O HTTP.sys é responsável pelo gerenciamento de conexões e pelo tratamento de solicitações. A solicitação pode ser atendida no cache do HTTP.sys ou transmitida para um processo de trabalho para tratamento posterior. Vários processos de trabalho podem ser configurados, o que fornece isolamento a um custo reduzido. Para obter mais informações sobre como o tratamento de solicitações funciona, confira a seguinte figura:
O HTTP.sys inclui um cache de resposta. Quando uma solicitação corresponde a uma entrada no cache de resposta, o HTTP.sys envia a resposta de cache diretamente do modo kernel. Algumas plataformas de aplicativo Web, como o ASP.NET, fornecem mecanismos para permitir que qualquer conteúdo dinâmico seja armazenado em cache no cache do modo kernel. O identificador de arquivo estático do IIS 10.0 armazena automaticamente em cache os arquivos solicitados com frequência no HTTP.sys.
Como um servidor Web tem componentes do modo kernel e do modo de usuário, ambos os componentes precisam ser ajustados para proporcionar o desempenho ideal. Portanto, o ajuste do IIS 10.0 para uma carga de trabalho específica inclui a configuração do seguinte:
HTTP.sys e o cache do modo kernel associado
Processos de trabalho e IIS no modo de usuário, incluindo a configuração do pool de aplicativos
Alguns parâmetros de ajuste que afetam o desempenho
As seções a seguir discutem como configurar os aspectos do modo kernel e do modo de usuário do IIS 10.0.
Configurações do modo kernel
As configurações de HTTP.sys relacionadas ao desempenho se enquadram em duas categorias amplas: gerenciamento de cache e gerenciamento de conexões e solicitações. Todas as configurações do Registro são armazenadas na seguinte entrada do Registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters
Observação Se o serviço HTTP já estiver em execução, você precisará reiniciá-lo para que as alterações entrem em vigor.
Configurações do gerenciamento de cache
Um benefício oferecido pelo HTTP.sys é um cache no modo kernel. Se a resposta estiver no cache no modo kernel, você poderá atender a uma solicitação HTTP inteiramente no modo kernel, o que reduz consideravelmente o custo da CPU de lidar com a solicitação. No entanto, o cache no modo kernel do IIS 10.0 é baseado na memória física, e o custo de uma entrada é a memória que ela ocupa.
Uma entrada no cache só é útil quando usada. No entanto, a entrada sempre consome memória física, independentemente de a entrada ser usada ou não. Você precisa avaliar a utilidade de um item no cache (a economia da capacidade de atendê-lo no cache) e o custo dele (a memória física ocupada) ao longo do tempo de vida da entrada, considerando os recursos disponíveis (CPU e memória física) e os requisitos de carga de trabalho. O HTTP.sys tenta manter apenas itens úteis e acessados ativamente no cache, mas você pode aumentar o desempenho do servidor Web ajustando o cache do HTTP.sys para cargas de trabalho específicas.
Estas são algumas configurações úteis para o cache do modo kernel do HTTP.sys:
UriEnableCache Valor padrão: 1
Um valor diferente de zero habilita a resposta do modo kernel e o cache de fragmentos. Para a maioria das cargas de trabalho, o cache deve permanecer habilitado. Considere a possibilidade de desabilitar o cache se você espera uma resposta muito baixa e cache de fragmentos.
UriMaxCacheMegabyteCount Valor padrão: 0
Um valor diferente de zero que especifica a memória máxima disponível para o cache do modo kernel. O valor padrão, 0, permite que o sistema ajuste automaticamente a quantidade de memória disponível para o cache.
Observação A especificação do tamanho define apenas o máximo, e talvez o sistema não permita que o cache cresça até o tamanho máximo do conjunto.
Â
UriMaxUriBytes Valor padrão: 262.144 bytes (256 KB)
O tamanho máximo de uma entrada no cache do modo kernel. Respostas ou fragmentos maiores do que isso não são armazenados em cache. Se você tiver memória suficiente, considere o aumento do limite. Se a memória é limitada e entradas grandes ocupam mais recursos do que as menores, talvez seja útil reduzir o limite.
UriScavengerPeriod Valor padrão: 120 segundos
O cache do HTTP.sys é verificado periodicamente por uma recuperação, e as entradas que não são acessadas entre as verificações de recuperação são removidas. A definição do período de recuperação com um valor alto reduz o número de verificações de recuperações. No entanto, o uso da memória de cache pode aumentar, porque entradas mais antigas e acessadas com menos frequência podem permanecer no cache. Definir o período com um valor muito baixo causa verificações de recuperação mais frequentes e pode resultar em muitas liberações e rotatividade de cache.
Configurações de gerenciamento de solicitação e conexão
No Windows Server 2022, o HTTP.sys gerencia as conexões automaticamente. As seguintes configurações do Registro não são mais usadas:
MaxConnections
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnectionsIdleConnectionsHighMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMarkIdleConnectionsLowMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMarkIdleListTrimmerPeriod
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriodRequestBufferLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepthInternalRequestLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\InternalRequestLookasideDepth
Configurações do modo de usuário
As configurações desta seção afetam o comportamento do processo de trabalho do IIS 10.0. A maioria dessas configurações pode ser encontrada no seguinte arquivo de configuração XML:
%SystemRoot%\system32\inetsrv\config\applicationHost.config
Use o Appcmd.exe, o Console de Gerenciamento do IIS 10.0, os cmdlets WebAdministration ou IISAdministration do PowerShell para alterá-las. A maioria das configurações é detectada automaticamente e não exigem uma reinicialização dos processos de trabalho do IIS 10.0 ou do servidor de aplicativos Web. Para obter mais informações sobre o arquivo applicationHost.config, confira Introdução ao ApplicationHost.config.
Configuração ideal da CPU para o hardware NUMA
A partir do Windows Server 2016, o IIS 10.0 dá suporte à atribuição de CPU ideal automática para os threads do pool de threads, a fim de aprimorar o desempenho e a escalabilidade no hardware NUMA. Esse recurso está habilitado por padrão e pode ser configurado por meio da seguinte chave do Registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu
Com esse recurso habilitado, o gerenciador de threads do IIS realiza os melhores esforços para distribuir igualmente os threads do pool de threads do IIS em todas as CPUs de todos os nós NUMA de acordo com as cargas atuais. Em geral, recomendamos manter essa configuração padrão inalterada para o hardware NUMA.
Observação A configuração ideal da CPU é diferente das configurações de atribuição de nó NUMA do processo de trabalho (numaNodeAssignment e numaNodeAffinityMode) introduzidas nas Configurações da CPU para um pool de aplicativos. A configuração ideal da CPU afeta a forma como o IIS distribui os threads do pool de threads, enquanto as configurações de atribuição de nó NUMA do processo de trabalho determinam em qual nó NUMA um processo de trabalho é iniciado.
Configurações de comportamento de cache no modo de usuário
Esta seção descreve as configurações que afetam o comportamento de cache do IIS 10.0. O cache do modo de usuário é implementado como um módulo que escuta os eventos de cache global gerados pelo pipeline integrado. Para desabilitar por completo o cache do modo de usuário, remova o módulo FileCacheModule (cachfile.dll) da lista de módulos instalados na seção de configuração system.webServer/globalModules no applicationHost.config.
system.webServer/caching
| Atributo | Descrição | Padrão |
|---|---|---|
| habilitado | Desabilita o cache do IIS no modo de usuário quando definido como False. Quando a taxa de ocorrência no cache é muito pequena, você pode desabilitar por completo o cache a fim de evitar a sobrecarga associada ao caminho do código de cache. A desabilitação do cache do modo de usuário não desabilita o cache do modo kernel. | Verdadeiro |
| enableKernelCache | Desabilita o cache do modo kernel quando definido como False. | Verdadeiro |
| maxCacheSize | Limita o tamanho do cache do modo de usuário do IIS ao tamanho especificado em megabytes. O IIS ajusta o padrão, dependendo da memória disponível. Escolha o valor cuidadosamente de acordo com o tamanho do conjunto de arquivos acessados com frequência em relação à quantidade de RAM ou ao espaço de endereço do processo do IIS. | 0 |
| maxResponseSize | Armazena arquivos em cache até o tamanho especificado. O valor real depende do número e do tamanho dos maiores arquivos no conjunto de dados em comparação com a RAM disponível. O cache de arquivos grandes e solicitados com frequência pode reduzir o uso da CPU, o acesso ao disco e as latências associadas. | 262144 |
Configurações do comportamento de compactação
O IIS a partir do 7.0 compacta o conteúdo estático por padrão. Além disso, a compactação de conteúdo dinâmico é habilitada por padrão quando o DynamicCompressionModule é instalado. A compactação reduz o uso da largura de banda, mas aumenta o uso da CPU. O conteúdo compactado é armazenado em cache no cache do modo kernel, se possível. A partir da versão 8.5, o IIS permite que a compactação seja controlada independentemente para o conteúdo estático e dinâmico. Em geral, o conteúdo estático se refere ao conteúdo que não é alterado, como arquivos GIF ou HTM. O conteúdo dinâmico normalmente é gerado por scripts ou por um código no servidor, ou seja, páginas ASP.NET. Você pode personalizar a classificação de qualquer extensão específica como estática ou dinâmica.
Para desabilitar por completo a compactação, remova StaticCompressionModule e DynamicCompressionModule da lista de módulos na seção system.webServer/globalModules no applicationHost.config.
system.webServer/httpCompression
| Atributo | Descrição | Padrão |
|---|---|---|
| staticCompression-EnableCpuUsage staticCompression-DisableCpuUsage dynamicCompression-EnableCpuUsage dynamicCompression-DisableCpuUsage |
Habilita ou desabilita a compactação se o percentual atual de uso da CPU fica acima ou abaixo dos limites especificados. A partir do IIS 7.0, a compactação será desabilitada automaticamente se a CPU de estado estável aumentar acima do limite de desabilitação. A compactação será habilitada se a CPU ficar abaixo do limite de habilitação. |
50, 100, 50 e 90, respectivamente |
| directory | Especifica o diretório em que as versões compactadas dos arquivos estáticos são temporariamente armazenadas e armazenadas em cache. Considere a possibilidade de mover esse diretório para fora da unidade do sistema se ele for acessado com frequência. | %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files |
| doDiskSpaceLimiting | Especifica se existe um limite para a quantidade de espaço em disco que todos os arquivos compactados podem ocupar. Os arquivos compactados são armazenados no diretório de compactação especificado pelo atributo directory. | Verdadeiro |
| maxDiskSpaceUsage | Especifica o número de bytes de espaço em disco que os arquivos compactados podem ocupar no diretório de compactação. Essa configuração poderá precisar ser aumentada se o tamanho total de todo o conteúdo compactado for muito grande. |
100 MB |
system.webServer/urlCompression
| Atributo | Descrição | Padrão |
|---|---|---|
| doStaticCompression | Especifica se o conteúdo estático é compactado. | Verdadeiro |
| doDynamicCompression | Especifica se o conteúdo dinâmico é compactado. | Verdadeiro |
Observação
Para os servidores que executam o IIS 10.0 com baixo uso médio da CPU, considere a possibilidade de habilitar a compactação para o conteúdo dinâmico, especialmente se as respostas forem grandes. Isso deve ser feito primeiro em um ambiente de teste para avaliar o efeito sobre o uso da CPU da linha de base.
Como ajustar a lista de documentos padrão
O módulo de documento padrão trata as solicitações HTTP para a raiz de um diretório e as converte em solicitações para um arquivo específico, como Default.htm ou Index.htm. Em média, cerca de 25% de todas as solicitações na Internet passam pelo caminho do documento padrão. Isso varia consideravelmente para sites individuais. Quando uma solicitação HTTP não especifica um nome de arquivo, o módulo de documento padrão pesquisa a lista de documentos padrão permitidos para cada nome no sistema de arquivos. Isso pode afetar negativamente o desempenho, especialmente se o acesso do conteúdo exigir uma viagem de ida e volta de rede ou o acesso a um disco.
Você pode evitar a sobrecarga desabilitando seletivamente documentos padrão e reduzindo ou ordenando a lista de documentos. Para os sites que usam um documento padrão, você deve reduzir a lista apenas aos tipos de documento padrão usados. Além disso, ordene a lista para que ela comece com o nome do arquivo do documento padrão acessado com mais frequência.
Você pode definir seletivamente o comportamento do documento padrão em URLs específicas personalizando a configuração dentro de uma marca de local em applicationHost.config ou inserindo um arquivo web.config diretamente no diretório de conteúdo. Isso permite uma abordagem híbrida, que permite documentos padrão somente quando necessário e define a lista como o nome de arquivo correto para cada URL.
Para desabilitar por completo os documentos padrão, remova DefaultDocumentModule da lista de módulos na seção system.webServer/globalModules no applicationHost.config.
system.webServer/defaultDocument
| Atributo | Descrição | Padrão |
|---|---|---|
| Habilitado | Especifica que os documentos padrão estão habilitados. | Verdadeiro |
Elemento <files> |
Especifica os nomes de arquivos configurados como documentos padrão. | A lista padrão é Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm e Default.aspx. |
Log binário central
Quando a sessão do servidor tem vários grupos de URLs abaixo dela, o processo de criar centenas de arquivos de log formatados para grupos de URL individuais e gravar os dados de log em um disco pode consumir rapidamente recursos valiosos da CPU e da memória, criando assim problemas de desempenho e escalabilidade. O log binário centralizado minimiza a quantidade de recursos do sistema usados para log, fornecendo dados de log detalhados para as organizações que exigem isso. A análise de logs de formato binário exige uma ferramenta de pós-processamento.
Você pode habilitar o log binário central definindo o atributo centralLogFileMode como CentralBinary e definindo o atributo enabled como True. Considere a possibilidade de mover o local do arquivo de log central para fora da partição do sistema e para uma unidade de log dedicada para evitar a contenção entre as atividades do sistema e as atividades de log.
system.applicationHost/log
| Atributo | Descrição | Padrão |
|---|---|---|
| centralLogFileMode | Especifica o modo de log para um servidor. Altere esse valor para CentralBinary para habilitar o log binário central. | Site |
system.applicationHost/log/centralBinaryLogFile
| Atributo | Descrição | Padrão |
|---|---|---|
| Habilitado | Especifica se o log binário central é habilitado. | Falso |
| directory | Especifica o diretório em que as entradas de log são gravadas. | %SystemDrive%\inetpub\logs\LogFiles |
Ajustes de aplicativos e de sites
As configurações a seguir estão relacionadas aos ajustes de site e de pool de aplicativos.
system.applicationHost/applicationPools/applicationPoolDefaults
| Atributo | Descrição | Padrão |
|---|---|---|
| queueLength | Indica a HTTP.sys quantas solicitações são enfileiradas para um pool de aplicativos antes que as solicitações futuras sejam rejeitadas. Quando o valor dessa propriedade é excedido, o IIS rejeita as solicitações seguintes com um erro 503. Considere a possibilidade de aumentar isso para os aplicativos que se comunicam com armazenamentos de dados de back-end de alta latência se forem observados erros 503. |
1000 |
| enable32BitAppOnWin64 | Quando True, permite que um aplicativo de 32 bits seja executado em um computador que tenha um processador de 64 bits. Considere a possibilidade de habilitar o modo de 32 bits se o consumo de memória for uma preocupação. Como os tamanhos de ponteiro e os tamanhos de instrução são menores, os aplicativos de 32 bits usam menos memória do que os aplicativos de 64 bits. A desvantagem de executar aplicativos de 32 bits em um computador de 64 bits é que o espaço de endereço no modo de usuário é limitado a 4 GB. |
Falso |
system.applicationHost/sites/VirtualDirectoryDefault
| Atributo | Descrição | Padrão |
|---|---|---|
| allowSubDirConfig | Especifica se o IIS procura arquivos web.config em diretórios de conteúdo inferiores ao nível atual (True) ou não procura arquivos web.config em diretórios de conteúdo inferiores ao nível atual (False). Ao impor uma limitação simples, que permite a configuração somente em diretórios virtuais, o IIS 10.0 pode saber que, a menos que /<name>.htm seja um diretório virtual, ele não deve procurar um arquivo de configuração. Ignorar as operações de arquivo adicionais pode aprimorar consideravelmente o desempenho dos sites que têm um conjunto muito grande de conteúdo estático acessado aleatoriamente. | Verdadeiro |
Como gerenciar módulos do IIS 10.0
O IIS 10.0 foi incluído em vários módulos extensíveis pelo usuário para dar suporte a uma estrutura modular. Essa fatoração tem um custo pequeno. Para cada módulo, o pipeline integrado precisa chamar o módulo para cada evento relevante para o módulo. Isso acontece independentemente de o módulo precisar fazer algum trabalho. Você pode preservar ciclos de CPU e memória removendo todos os módulos que não são relevantes para um site específico.
Um servidor Web ajustado para arquivos estáticos simples pode incluir apenas os cinco seguintes módulos: UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule e HttpLoggingModule.
Para remover módulos do applicationHost.config, remova todas as referências ao módulo das seções system.webServer/handlers e system.webServer/modules, além de remover a declaração de módulo em system.webServer/globalModules.
Configurações clássicas do ASP
O custo principal do processamento de uma solicitação ASP clássica inclui inicializar um mecanismo de script, compilar o script ASP solicitado em um modelo ASP e executar o modelo no mecanismo de script. Embora o custo de execução do modelo dependa da complexidade do script ASP solicitado, o módulo ASP clássico do IIS pode armazenar em cache mecanismos de script em modelos de memória e cache na memória e no disco (somente se o cache de modelo na memória estourar) para aumentar o desempenho em cenários associados à CPU.
As configurações a seguir são usadas para configurar o cache de modelo ASP clássico e o cache do mecanismo de script e não afetam as configurações do ASP.NET.
system.webServer/asp/cache
| Atributo | Descrição | Padrão |
|---|---|---|
| diskTemplateCacheDirectory | O nome do diretório que o ASP usa para armazenar modelos compilados quando o cache em memória estourar. Recomendação: defina-a como um diretório que não seja muito usado, por exemplo, uma unidade que não é compartilhada com o sistema operacional, o log do IIS ou outro conteúdo acessado com frequência. |
%SystemDrive%\inetpub\temp\ASP Compiled Templates |
| maxDiskTemplateCacheFiles | Especifica o número máximo de modelos ASP compilados que podem ser armazenados em cache no disco. Recomendação: defina-a como o valor máximo de 0x7FFFFFFF. |
2000 |
| scriptFileCacheSize | Esse atributo especifica o número máximo de modelos ASP compilados que podem ser armazenados em cache na memória. Recomendação: defina-a como, no mínimo, o número de scripts ASP solicitados com frequência atendidos por um pool de aplicativos. Se possível, defina isso como o máximo de modelos ASP que os limites de memória permitirem. |
500 |
| scriptEngineCacheMax | Especifica o número máximo de mecanismos de script que serão mantidos armazenados em cache na memória. Recomendação: defina-a como, no mínimo, o número de scripts ASP solicitados com frequência atendidos por um pool de aplicativos. Se possível, defina isso como o máximo de mecanismos de script que os limites de memória permitirem. |
250 |
system.webServer/asp/limits
| Atributo | Descrição | Padrão |
|---|---|---|
| processorThreadMax | Especifica o número máximo de threads de trabalho por processador que pode ser criado pelo ASP. Aumente-o se a configuração atual for insuficiente para lidar com a carga, o que pode causar erros ao atender solicitações ou causar o uso insuficiente de recursos de CPU. | 25 |
system.webServer/asp/comPlus
| Atributo | Descrição | Padrão |
|---|---|---|
| executeInMta | Defina-o como True se erros ou falhas forem detectados enquanto o IIS estiver fornecendo o conteúdo de ASP. Isso pode ocorrer, por exemplo, ao hospedar vários sites isolados nos quais cada site é executado em um processo de trabalho próprio. Normalmente, os erros são relatados do COM+ no Visualizador de Eventos. Essa configuração habilita o modelo Multi-Threaded Apartment no ASP. | Falso |
Configuração de simultaneidade do ASP.NET
ASP.NET 3.5
Por padrão, o ASP.NET limita a simultaneidade de solicitação para reduzir o consumo de memória de estado estável no servidor. Talvez os aplicativos de alta simultaneidade precisem ajustar algumas configurações para aprimorar o desempenho geral. Você pode alterar essa configuração no arquivo aspnet.config:
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>
A seguinte configuração é útil para usar por completo os recursos em um sistema:
maxConcurrentRequestPerCpu Valor padrão: 5000
Essa configuração limita o número máximo de solicitações do ASP.NET executadas simultaneamente em um sistema. O valor padrão é conservador para reduzir o consumo de memória dos aplicativos ASP.NET. Considere a possibilidade de aumentar esse limite em sistemas que executam aplicativos que realizam operações de E/S longas e síncronas. Caso contrário, os usuários poderão experimentar alta latência devido a falhas de fila ou solicitação por conta dos limites de fila excedidos em uma carga alta quando a configuração padrão é usada.
ASP.NET 4.6
Além da configuração de maxConcurrentRequestPerCpu, o ASP.NET 4.7 também fornece configurações para aprimorar o desempenho nos aplicativos que têm uma dependência forte da operação assíncrona. A configuração pode ser alterada no arquivo aspnet.config.
<system.web>
<applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>
- percentCpuLimit Valor padrão: 90 A solicitação assíncrona tem alguns problemas de escalabilidade quando uma carga muito grande (além dos recursos de hardware) é colocada nesse cenário. O problema se deve à natureza da alocação em cenários assíncronos. Nessas condições, a alocação ocorrerá quando a operação assíncrona for iniciada e ela será consumida quando for concluída. Até lá, é muito possível que os objetos tenham sido movidos para a geração 1 ou 2 pelo GC. Quando isso acontecer, o aumento da carga mostrará um aumento na RPS (solicitações por segundo) até um ponto. Depois que passarmos esse ponto, o tempo gasto no GC começará a se tornar um problema e as RPS começarão a cair, tendo um efeito de dimensionamento negativo. Para corrigir o problema, quando o uso da CPU exceder a configuração de percentCpuLimit, as solicitações serão enviadas para a fila nativa do ASP.NET.
- percentCpuLimitMinActiveRequestPerCpu Valor padrão: 100 CPU A limitação (configuração de percentCpuLimit) não é baseada no número de solicitações, mas no quão caras elas são. Como resultado, pode haver apenas algumas solicitações com uso intensivo de CPU causando um backup na fila nativa sem nenhuma forma de esvaziá-la além das solicitações de entrada. Para resolver esse problema, percentCpuLimitMinActiveRequestPerCpu pode ser usado para garantir que um número mínimo de solicitações esteja sendo atendido antes que a limitação entre em ação.
Opções de processo de trabalho e reciclagem
Você pode configurar opções para reciclar processos de trabalho do IIS e fornecer soluções práticas para situações ou eventos graves sem exigir intervenção nem redefinir um serviço ou um computador. Situações e eventos como esses incluem perda de memória, aumento da carga de memória ou processos de trabalho sem resposta ou ociosos. Em condições comuns, as opções de reciclagem talvez não sejam necessárias, e a reciclagem pode ser desativada ou o sistema pode ser configurado para reciclagem com muita pouca frequência.
Você pode habilitar a reciclagem de processos para um aplicativo específico adicionando atributos ao elemento recycling/periodicRestart. O evento de reciclagem pode ser disparado por vários eventos, incluindo o uso de memória, um número fixo de solicitações e um período fixo. Quando um processo de trabalho é reciclado, as solicitações enfileiradas e em execução são esgotadas e um novo processo é iniciado simultaneamente para atender às novas solicitações. O elemento recycling/periodicRestart é por aplicativo, o que significa que cada atributo na tabela a seguir é particionado por aplicativo.
system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart
| Atributo | Descrição | Padrão |
|---|---|---|
| memória | Habilite a reciclagem de processos se o consumo de memória virtual exceder o limite especificado em quilobytes. Essa é uma configuração útil para computadores de 32 bits que têm um espaço de endereço pequeno de 2 GB. Ela pode ajudar a evitar solicitações com falha devido a erros de memória insuficiente. | 0 |
| privateMemory | Habilite a reciclagem de processos se as alocações de memória privada excederem um limite especificado em quilobytes. | 0 |
| solicitações | Habilite a reciclagem de processos após determinado número de solicitações. | 0 |
| time | Habilite a reciclagem de processos após um período especificado. | 29:00:00 |
Ajuste da saída de página do processo de trabalho dinâmico
A partir do Windows Server 2012 R2, o IIS oferece a opção de configurar o processo de trabalho para suspensão depois de ele ficar ocioso por um tempo (além da opção de encerramento, que existe desde o IIS 7).
A principal finalidade dos recursos de encerramento e de saída de página do processo de trabalho ocioso é preservar a utilização de memória no servidor, pois um site pode consumir muita memória, mesmo que ele esteja inativo, escutando. Dependendo da tecnologia usada no site (conteúdo estático em relação ao ASP.NET e a outras estruturas), a memória usada pode ser de cerca de 10 MB a centenas de MBs, e isso significa que, se o servidor estiver configurado com muitos sites, descobrir as configurações mais eficazes para seus sites poderá aprimorar consideravelmente o desempenho de sites ativos e suspensos.
Antes de entrarmos nos detalhes, precisamos ter em mente que, se não houver restrições de memória, provavelmente será melhor simplesmente definir os sites para nunca serem suspensos ou encerrados. Afinal, de pouco adianta encerrar um processo de trabalho se ele for o único na máquina.
Observação
Caso o site execute um código instável, como um código com perda de memória ou de outro modo instável, a definição do site para encerramento quando ocioso pode ser uma alternativa improvisada para corrigir o bug do código. Isso não é algo que incentivamos, mas em uma situação crítica, pode ser melhor usar esse recurso como um mecanismo de limpeza enquanto uma solução mais permanente está em andamento.
Outro fator a ser considerado é que, se o site usar muita memória, o processo de suspensão em si será prejudicial, pois o computador precisará gravar os dados usados pelo processo de trabalho em disco. Se o processo de trabalho estiver usando uma grande parte da memória, suspendê-lo poderá ser mais caro do que o custo de precisar esperar que ele inicie o backup.
Para aproveitar ao máximo o recurso de suspensão do processo de trabalho, você precisa analisar seus sites em cada pool de aplicativos e decidir quais devem ser suspensos, quais devem ser encerrados e quais devem ficar ativos por tempo indeterminado. Para cada ação e site, você precisa descobrir o período ideal de tempo limite.
O ideal é que os sites que você vai configurar para suspensão ou encerramento sejam aqueles que têm visitantes todos os dias, mas não o suficiente para garantir mantê-los ativos o tempo todo. Geralmente, são sites com cerca de 20 visitantes únicos por dia ou menos. Você pode analisar os padrões de tráfego usando os arquivos de log do site e calcular o tráfego diário médio.
Tenha em mente que, uma vez que um usuário específico se conecta ao site, ele normalmente permanecerá nele por, no mínimo, um tempo, fazendo solicitações adicionais. Portanto, apenas contar as solicitações diárias talvez não reflita com precisão os padrões de tráfego reais. Para obter uma leitura mais precisa, use também uma ferramenta, como o Microsoft Excel, para calcular o tempo médio entre as solicitações. Por exemplo:
| Número | URL da solicitação | Tempo de solicitação | Delta |
|---|---|---|---|
| 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 |
A parte difícil, porém, é descobrir qual configuração aplicar para fazer sentido. Em nosso caso, o site obtém várias solicitações dos usuários, e a tabela acima mostra que um total de quatro sessões exclusivas ocorreram em um período de quatro horas. Com as configurações padrão para a suspensão do processo de trabalho do pool de aplicativos, o site será encerrado após o tempo limite padrão de 20 minutos, o que significa que cada um desses usuários experimentará o ciclo de rotação do site. Isso o torna um candidato ideal para a suspensão do processo de trabalho, pois, na maioria das vezes, o site está ocioso e, portanto, suspendê-lo preservará recursos e permitirá que os usuários acessem o site quase instantaneamente.
Uma observação final e muito importante sobre isso é que o desempenho do disco é crucial para esse recurso. Como o processo de suspensão e de ativação envolve a gravação e a leitura de um grande volume de dados no disco rígido, recomendamos fortemente o uso de um disco rápido para isso. As SSDs (unidades de estado sólido) são ideais e altamente recomendadas para isso, e você deve verificar se o arquivo de página do Windows está armazenado nela (se o próprio sistema operacional não estiver instalado na SSD, configure o sistema operacional para mover o arquivo de página para ele).
Independentemente de você usar um SSD, também recomendamos corrigir o tamanho do arquivo de página para acomodar a gravação dos dados de página nele sem o redimensionamento de arquivo. O redimensionamento de arquivo de página pode acontecer quando o sistema operacional precisa armazenar dados no arquivo de página, pois, por padrão, o Windows é configurado para ajustar automaticamente o tamanho de acordo com a necessidade. Ao definir o tamanho como fixo, você pode impedir o redimensionamento e aprimorar muito o desempenho.
Para configurar um tamanho de arquivo de página pré-fixo, você precisa calcular o tamanho ideal, que depende de quantos sites você suspenderá e de quanta memória eles consomem. Se a média for de 200 MB para um processo de trabalho ativo e você tiver 500 sites nos servidores que serão suspensos, o arquivo de página deverá ter, no mínimo, (200 * 500) MB acima do tamanho base do arquivo de página (portanto, base + 100 GB, em nosso exemplo).
Observação
Quando os sites forem suspensos, eles consumirão aproximadamente 6 MB cada. Portanto, em nosso caso, o uso de memória se todos os sites forem suspensos será de cerca de 3 GB. Porém, você provavelmente nunca terá todos eles suspensos ao mesmo tempo.
Parâmetros de ajuste do protocolo TLS
O uso do protocolo TLS impõe um custo adicional da CPU. O componente mais caro do TLS é o custo de estabelecer uma sessão, porque isso envolve um handshake completo. Reconexão, criptografia e descriptografia também aumentam o custo. Para aprimorar o desempenho do TLS, faça o seguinte:
Habilite keep-alives HTTP para as sessões TLS. Isso elimina os custos de estabelecimento da sessão.
Reutilize as sessões quando apropriado, especialmente com o tráfego não keep-alive.
Aplique a criptografia seletivamente somente às páginas ou às partes do site que precisam dela, em vez de a todo o site.
Observação
- Chaves maiores fornecem mais segurança, mas também usam mais tempo da CPU.
- Talvez nem todos os componentes precisem ser criptografados. No entanto, misturar HTTP simples e HTTPS pode resultar em um aviso pop-up de que nem todo o conteúdo na página é seguro.
Interface ISAPI
Nenhum parâmetro de ajuste especial é necessário para aplicativos ISAPI. Se você escrever uma extensão ISAPI privada, escreva-a de modo que ela proporcione desempenho e uso de recursos.
Diretrizes de ajuste do código gerenciado
O modelo de pipeline integrado do IIS 10.0 permite um alto grau de flexibilidade e extensibilidade. Os módulos personalizados implementados em código nativo ou gerenciado podem ser inseridos no pipeline ou podem substituir os módulos existentes. Embora esse modelo de extensibilidade ofereça conveniência e simplicidade, você deve ter cuidado antes de inserir novos módulos gerenciados que se conectam a eventos globais. A adição de um módulo gerenciado global significa que todas as solicitações, incluindo as solicitações de arquivo estático, precisam acessar o código gerenciado. Os módulos personalizados são suscetíveis a eventos como coleta de lixo. Além disso, os módulos personalizados contribuem para um custo significativo de CPU devido ao marshaling de dados entre o código nativo e gerenciado. Se possível, você deve definir preCondition como managedHandler para o módulo gerenciado.
Para obter um melhor desempenho da inicialização a frio, compile previamente o site do ASP.NET ou aproveite o recurso Inicialização de Aplicativo do IIS para preparar o aplicativo.
Se o estado da sessão não for necessário, desative-o para cada página.
Se houver muitas operações associadas à E/S, tente usar a versão assíncrona das APIs relevantes, o que dará a você uma escalabilidade muito melhor.
Além disso, o uso do Cache de Saída corretamente aumentará o desempenho do site.
Quando você executar vários hosts que contêm scripts ASP.NET no modo isolado (um pool de aplicativos por site), monitore o uso da memória. Verifique se o servidor tem RAM suficiente para o número esperado de pools de aplicativos em execução simultânea. Considere o uso de vários domínios de aplicativo, em vez de vários processos isolados.
Outros problemas que afetam o desempenho do IIS
Os seguintes problemas podem afetar o desempenho do IIS:
Instalação de filtros que não têm reconhecimento de cache
A instalação de um filtro que não tem reconhecimento de cache HTTP faz com que o IIS desabilite por completo o cache, o que resulta em baixo desempenho. Os filtros da ISAPI gravados antes do IIS 6.0 podem causar esse comportamento.
Solicitações da interface CGI
Por motivos de desempenho, o uso de aplicativos CGI para atender a solicitações não é recomendado com o IIS. A criação e a exclusão frequentes de processos de CGI envolve uma sobrecarga significativa. Entre alternativas melhores estão o uso de FastCGI, scripts de aplicativo ISAPI e scripts ASP ou ASP.NET. O isolamento está disponível para cada uma dessas opções.