Ajustando o IIS 10.0

Os Serviços de Informações da Internet (IIS) 10.0 estão incluídos no Windows Server 2022. Ele usa um modelo de processo semelhante ao do IIS 8.5 e IIS 7.0. Um driver de modo kernel para a Web (http.sys) recebe e encaminha pedidos HTTP e satisfaz pedidos a partir do seu cache de resposta. Os processos de trabalho registram-se para subespaços de URL e http.sys encaminha a solicitação para o processo apropriado (ou conjunto de processos para pools de aplicativos).

HTTP.sys é responsável pelo gerenciamento de conexões e tratamento de solicitações. A solicitação pode ser atendida a partir do armazenamento intermédio HTTP.sys ou encaminhada para um processo operativo 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 funciona o tratamento de solicitações, consulte a figura a seguir:

HTTP.sys inclui um cache de resposta. Quando uma solicitação corresponde a uma entrada no cache de resposta, HTTP.sys envia a resposta de cache diretamente do modo kernel. Algumas plataformas de aplicativos da Web, como ASP.NET, fornecem mecanismos para permitir que qualquer conteúdo dinâmico seja armazenado em cache no cache do modo kernel. O manipulador de arquivos estáticos no IIS 10.0 armazena automaticamente em cache os arquivos solicitados com freqüência no http.sys.

Como um servidor Web tem componentes de modo kernel e modo de usuário, ambos os componentes devem ser ajustados para um desempenho ideal. Portanto, ajustar o IIS 10.0 para uma carga de trabalho específica inclui configurar o seguinte:

• HTTP.sys e o cache de modo kernel associado

• Processos de trabalho e IIS de modo de usuário, incluindo a configuração do pool de aplicativos

• Certos parâmetros de ajuste que afetam o desempenho

As seções a seguir discutem como configurar os aspetos de modo kernel e 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ê deverá reiniciá-lo para que as alterações entrem em vigor.

Configurações de gerenciamento de cache

Um benefício que HTTP.sys fornece é um cache de modo kernel. Se a resposta estiver no cache do modo kernel, você poderá satisfazer uma solicitação HTTP inteiramente a partir do modo kernel, o que reduz significativamente o custo da CPU para lidar com a solicitação. No entanto, o cache de 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 é útil somente quando é usada. No entanto, a entrada sempre consome memória física, quer a entrada esteja ou não sendo usada. Você deve avaliar a utilidade de um item no cache (a economia de poder atendê-lo a partir do cache) e seu custo (a memória física ocupada) ao longo da vida útil da entrada, considerando os recursos disponíveis (CPU e memória física) e os requisitos de carga de trabalho. HTTP.sys tenta manter apenas itens úteis acessados ativamente no cache, mas você pode aumentar o desempenho do servidor Web ajustando o cache de HTTP.sys para cargas de trabalho específicas.

A seguir estão algumas configurações úteis para o cache de modo kernel 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 desativar o cache se você esperar 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 Especificar o tamanho define apenas o máximo, e o sistema pode não permitir que o cache cresça para o tamanho máximo definido.

  Â

• UriMaxUriBytes Valor padrão: 262144 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 tiver memória suficiente, considere aumentar o limite. Se a memória for limitada e as entradas grandes estiverem sobrecarregando as menores, pode ser útil reduzir o limite.

• UriScavengerPeriod Valor padrão: 120 segundos

  O cache de HTTP.sys é verificado periodicamente por um varredor, e as entradas que não são acessadas entre as varreduras do varredor são removidas. Definir o período do coletor para um valor alto reduz o número de varreduras do coletor. No entanto, o uso de memória cache pode aumentar porque entradas mais antigas e acessadas com menos frequência podem permanecer no cache. Definir o período muito baixo provoca scans de recuperação mais frequentes e pode resultar em demasiados descarregamentos e rotatividade de cache.

Configurações de gerenciamento de solicitações e conexões

No Windows Server 2022, o HTTP.sys gerencia conexões automaticamente. As seguintes configurações do Registro não são mais usadas:

• MaxConnections

  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
  

Configurações do modo de usuário

As configurações nesta 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 Appcmd.exe, o Console de Gestão do IIS 10.0, os Cmdlets do WebAdministration ou IISAdministration PowerShell para alterá-los. A maioria das configurações é detetada automaticamente e não requer 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, consulte Introdução ao ApplicationHost.config.

Configuração de CPU ideal para hardware NUMA

A partir do Windows Server 2016, o IIS 10.0 oferece suporte à atribuição automática ideal de CPU para os seus threads do pool de threads para melhorar o desempenho e a escalabilidade em hardware NUMA. Esta funcionalidade está ativada por predefinição e pode ser configurada através da seguinte chave de registo:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu

Ao ativar este recurso, o gerenciador de threads do IIS se esforça para distribuir de forma equilibrada os threads do pool de IIS por todas as CPUs em todos os nós NUMA, com base em suas cargas atuais. Em geral, recomenda-se manter essa configuração padrão inalterada para 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 do CPU afeta como o IIS distribui os seus threads do pool de threads, enquanto as configurações de atribuição do 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 no IISÂ 10.0. O cache de modo de usuário é implementado como um módulo que escuta os eventos de cache global gerados pelo pipeline integrado. Para desativar completamente o cache de 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

Configurações de comportamento de compactação

O IIS, a partir da versão 7.0, compacta 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 de 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 conteúdo estático e dinâmico. O conteúdo estático normalmente refere-se ao conteúdo que não é alterado, como arquivos GIF ou HTM. O conteúdo dinâmico é normalmente gerado por scripts ou código no servidor, ou seja, ASP.NET páginas. Você pode personalizar a classificação de qualquer extensão específica como estática ou dinâmica.

Para desativar completamente a compactação, remova StaticCompressionModule e DynamicCompressionModule da lista de módulos na seção system.webServer/globalModules no applicationHost.config.

system.webServer/httpCompression

system.webServer/urlCompression

Ajustando a lista de documentos padrão

O módulo de documento padrão lida com solicitações HTTP para a raiz de um diretório e as traduz 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 padrão do documento. Isso varia significativamente para cada local. 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 alcançar o conteúdo exigir fazer uma volta completa à rede ou aceder a um disco.

Você pode evitar a sobrecarga desativando seletivamente os documentos padrão e reduzindo ou ordenando a lista de documentos. Para sites que usam um documento padrão, você deve reduzir a lista para apenas os tipos de documento padrão que são usados. Além disso, ordene a lista para que ela comece com o nome de arquivo de documento padrão acessado com mais freqüência.

Você pode definir seletivamente o comportamento padrão do documento em URLs específicas personalizando a configuração dentro de uma marca de local no applicationHost.config ou inserindo um arquivo web.config diretamente no diretório de conteúdo. Isso permite uma abordagem híbrida, que habilita documentos padrão somente onde eles são necessários e define a lista para o nome de arquivo correto para cada URL.

Para desativar completamente os documentos padrão, remova DefaultDocumentModule da lista de módulos na seção system.webServer/globalModules no applicationHost.config.

system.webServer/defaultDocument

O registo binário central

Quando a sessão do servidor tem vários grupos de URL sob ela, 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 de CPU e memória, criando problemas de desempenho e escalabilidade. O log binário centralizado minimiza a quantidade de recursos do sistema que são usados para registro em log e, ao mesmo tempo, fornece dados de log detalhados para organizações que precisam dele. A análise de logs de formato binário requer 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 mover o local do arquivo de log central da partição do sistema para uma unidade de log dedicada para evitar a contenção entre as atividades do sistema e as atividades de registro.

system.applicationHost/log

system.applicationHost/log/centralBinaryLogFile

Ajustes de aplicações e sites

As configurações a seguir estão relacionadas ao pool de aplicativos e aos ajustes do site.

system.applicationHost/applicationPools/applicationPoolDefaults

system.applicationHost/sites/VirtualDirectoryDefault

Gerenciando módulos do IIS 10.0

O IIS 10.0 foi incluído em vários módulos extensíveis pelo usuário para oferecer suporte a uma estrutura modular. Esta fatoração possui um custo baixo. Para cada módulo, o pipeline integrado deve chamar o módulo para cada evento relevante para o módulo. Isso acontece independentemente de o módulo dever fazer algum trabalho. Você pode conservar os ciclos da CPU e a 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 módulos a seguir: UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule e HttpLoggingModule.

Para remover módulos de 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 ASP clássicas

O principal custo de 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. Enquanto o custo de execução do modelo depende da complexidade do script ASP solicitado, o módulo ASP clássico do IIS pode armazenar em cache os motores de script na memória e os modelos em cache na memória e no disco (somente se o cache de modelos na memória exceder), para aumentar o desempenho em cenários limitados pela 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 configurações do ASP.NET.

system.webServer/asp/cache

system.webServer/asp/limits

system.webServer/asp/comPlus

ASP.NET configuração de simultaneidade

ASP.NET 3.5

Por padrão, ASP.NET limita a simultaneidade de solicitação para reduzir o consumo de memória em estado estacionário no servidor. Aplicativos de alta simultaneidade podem precisar ajustar algumas configurações para melhorar o desempenho geral. Você pode alterar esta configuração no arquivo aspnet.config:

<system.web>
  <applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>

A configuração a seguir é útil para usar totalmente os recursos em um sistema:

• maxConcurrentRequestPerCpu Valor padrão: 5000

  Essa configuração limita o número máximo de solicitações de ASP.NET executadas simultaneamente em um sistema. O valor padrão é conservador para reduzir o consumo de memória de aplicativos ASP.NET. Considere aumentar esse limite em sistemas que executam aplicativos que executam operações de E/S longas e síncronas. Caso contrário, os usuários podem enfrentar alta latência devido a falhas no enfileiramento ou em pedidos, causadas pelo excesso dos limites de fila sob elevada carga quando a configuração padrão é usada.

ASP.NET 4.6

Além da configuração maxConcurrentRequestPerCpu, o ASP.NET 4.7 também fornece configurações para melhorar o desempenho nos aplicativos que dependem fortemente 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 enorme (além dos recursos de hardware) é colocada nesse cenário. O problema deve-se à natureza da alocação em cenários assíncronos. Nessas condições, a alocação acontecerá quando a operação assíncrona for iniciada e será consumida quando for concluída. Por essa altura, é muito possível que os objetos tenham sido movidos para a geração 1 ou 2 pelo GC. Quando isso acontece, aumentar a carga resultará num aumento no número de pedidos por segundo (rps) até certo ponto. Uma vez passado esse ponto, o tempo gasto em GC começará a se tornar um problema e o rps começará a cair, tendo um efeito de escala negativo. Para corrigir o problema, quando o uso da CPU exceder a definição de percentCpuLimit, as solicitações serão enviadas para a fila nativa do ASP.NET.
• percentCpuLimitMinActiveRequestPerCpu Valor padrão: 100 A limitação da CPU (configuração percentCpuLimit) não se baseia no número de solicitações, mas em 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 maneira de esvaziá-lo além das solicitações recebidas. 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.

Processo de trabalho e opções de reciclagem

Você pode configurar opções para reciclar processos de trabalho do IIS e fornecer soluções práticas para situações ou eventos agudos sem a necessidade de intervenção ou redefinição de um serviço ou computador. Tais situações e eventos incluem vazamentos de memória, aumento da carga de memória ou processos de trabalho ociosos ou sem resposta. Em condições normais, as opções de reciclagem podem não ser necessárias e a reciclagem pode ser desligada ou o sistema pode ser configurado para reciclar muito raramente.

Você pode habilitar a reciclagem de processo para um aplicativo específico adicionando atributos ao elemento recycling/periodicRestart . O evento de reciclagem pode ser acionado por vários eventos, incluindo o uso de memória, um número fixo de solicitações e um período de tempo fixo. Quando um processo de trabalho é reciclado, as solicitações que estavam enfileiradas e sendo processadas são finalizadas, e um novo processo é iniciado simultaneamente para atender a 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

Ajuste dinâmico da página do processo de trabalho

A partir do Windows Server 2012 R2, o IIS oferece a opção de configurar o processo de trabalho para suspender depois de ficar ocioso por um tempo (além da opção de encerrar, que existia desde o IIS 7).

O principal objetivo dos recursos de saída de página do processo de trabalho ocioso e da terminação do processo de trabalho ocioso é conservar a utilização da memória no servidor, uma vez que um site pode consumir muita memória, mesmo quando está apenas em inatividade, aguardando. Dependendo da tecnologia usada no site (conteúdo estático vs ASP.NET vs outras estruturas), a memória usada pode ser de cerca de 10 MB a centenas de MBs, e isso significa que, se o seu servidor estiver configurado com muitos sites, descobrir as configurações mais eficazes para seus sites pode melhorar drasticamente o desempenho de sites ativos e suspensos.

Antes de entrarmos em detalhes, devemos ter em mente que, se não houver restrições de memória, provavelmente é melhor simplesmente definir os sites para nunca suspender ou encerrar. Afinal, de pouco vale encerrar um processo de trabalho se ele for o único na máquina.

Outro fator a considerar é que, se o site usa muita memória, o processo de suspensão em si cobra um preço, porque o computador tem que gravar os dados usados pelo processo de trabalho no disco. Se o processo de trabalho estiver usando um grande pedaço de memória, suspendê-lo pode ser mais caro do que o custo de ter que esperar que ele inicie o backup.

Para aproveitar ao máximo o recurso de suspensão do processo de trabalho, você precisa revisar seus sites em cada pool de aplicativos e decidir quais devem ser suspensos, quais devem ser encerrados e quais devem estar ativos indefinidamente. Para cada ação e cada site, você precisa descobrir o período de tempo limite ideal.

Idealmente, os sites que você configurará para suspensão ou encerramento são aqueles que têm visitantes todos os dias, mas não o suficiente para garantir mantê-lo ativo o tempo todo. Estes são geralmente 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 médio diário.

Tenha em mente que, uma vez que um usuário específico se conecta ao site, ele normalmente permanecerá nele por pelo menos um tempo, fazendo solicitações adicionais e, portanto, apenas contar solicitações diárias pode não refletir com precisão os padrões de tráfego reais. Para obter uma leitura mais precisa, você também pode usar uma ferramenta, como o Microsoft Excel, para calcular o tempo médio entre as solicitações. Por exemplo:

A parte difícil, porém, é descobrir qual configuração aplicar para fazer sentido. No nosso caso, o site recebe um monte de solicitações dos usuários, e a tabela acima mostra que um total de 4 sessões únicas ocorreram em um período de 4 horas. Com as configurações padrão para a suspensão do processo de trabalho do pool de aplicativos, o site seria encerrado após o tempo limite padrão de 20 minutos, o que significa que cada um desses usuários passaria pelo ciclo de inicialização do site. Isso o torna um candidato ideal para a suspensão do processo de trabalho, porque, na maioria das vezes, o site está ocioso e, portanto, suspendê-lo economizaria recursos e permitiria que os usuários chegassem ao 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 despertar envolve a gravação e leitura de uma grande quantidade de dados no disco rígido, recomendamos o uso de um disco rápido para isso. As unidades de estado sólido (SSDs) são ideais e altamente recomendadas para isso, e você deve certificar-se de que o arquivo de paginação do Windows está armazenado nele (se o próprio sistema operacional não estiver instalado no SSD, configure o sistema operacional para mover o arquivo de paginação para ele).

Quer você use um SSD ou não, também recomendamos corrigir o tamanho do arquivo de paginação para acomodar a gravação dos dados de saída de página nele sem redimensionamento de arquivos. O redimensionamento do arquivo de paginação pode acontecer quando o sistema operacional precisa armazenar dados no arquivo de paginação, porque, por padrão, o Windows é configurado para ajustar automaticamente seu tamanho com base na necessidade. Ao definir o tamanho para um fixo, você pode evitar o redimensionamento e melhorar muito o desempenho.

Para configurar um tamanho de arquivo de página prefixado, você precisa calcular seu tamanho ideal, que depende de quantos sites você suspenderá e 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 paginação deverá ter pelo menos (200 * 500) MB sobre o tamanho base do arquivo de paginação (portanto, base + 100 GB em nosso exemplo).

Parâmetros de ajuste de segurança da camada de transporte

O uso de Transport Layer Security (TLS) impõe custo adicional de CPU. O componente mais caro do TLS é o custo de estabelecer uma sessão porque envolve um handshake completo. A religação, encriptação e desencriptação também aumentam o custo. Para um melhor desempenho do TLS, faça o seguinte:

• Ative HTTP keep-alives para sessões TLS. Isto elimina os custos de estabelecimento da sessão.

• Reutilize as sessões quando apropriado, especialmente com tráfego sem persistência.

• Aplique seletivamente a criptografia apenas às páginas ou partes do site que precisam dela, e não a todo o site.

ISAPI (Internet Server Application Programming Interface)

Não são necessários parâmetros de ajuste especiais para aplicativos ISAPI. Se você escrever uma extensão ISAPI privada, certifique-se de que ela seja escrita para desempenho e uso de recursos.

Diretrizes de ajuste de código gerenciado

O modelo de pipeline integrado no IIS 10.0 permite um alto grau de flexibilidade e extensibilidade. Módulos personalizados que são implementados em código nativo ou gerenciado podem ser inseridos no pipeline ou podem substituir 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. Adicionar um módulo gerenciado global significa que todas as solicitações, incluindo solicitações de arquivos estáticos, devem tocar no código gerenciado. Os módulos personalizados são suscetíveis a eventos como a coleta de lixo. Além disso, os módulos personalizados adicionam um custo de CPU significativo devido ao empacotamento de dados entre código nativo e gerenciado. Se possível, você deve definir preCondition como managedHandler para o módulo gerenciado.

Para obter um melhor desempenho de inicialização a frio, certifique-se de pré-compilar o site ASP.NET ou aproveitar o recurso de inicialização de aplicativos do IIS para aquecer o aplicativo.

Se o estado da sessão não for necessário, certifique-se de desativá-lo para cada página.

Se houver muitas operações vinculadas a E/S, tente usar a versão assíncrona de APIs relevantes, o que lhe dará uma escalabilidade muito melhor.

Além disso, usar o cache de saída corretamente também aumentará o desempenho do seu site.

Quando você executa vários hosts que contêm scripts ASP.NET no modo isolado (um pool de aplicativos por site), monitore o uso de 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 reconhecem cache

  A instalação de um filtro que não reconhece cache HTTP faz com que o IIS desabilite completamente o cache, o que resulta em um desempenho insatisfatório. Os filtros ISAPI que foram escritos antes do IISÂ 6.0 podem causar esse comportamento.

• Solicitações CGI (Common Gateway Interface)

  Por motivos de desempenho, o uso de aplicativos CGI para atender solicitações não é recomendado com o IIS. A criação e exclusão freqüentes de processos CGI envolve uma sobrecarga significativa. Melhores alternativas incluem o uso de FastCGI, scripts de aplicativos ISAPI e scripts ASP ou ASP.NET. O isolamento está disponível para cada uma dessas opções.

Referências Adicionais

• Ajuste de desempenho do servidor Web
• Ajuste HTTP 1.1/2