IIS 7.0
Os 10 principais aperfeiçoamentos de desempenho no IIS 7.0
Mike Volodarsky
Visão geral:
- Minimizar a superfície do aplicativo
- Reduzir os custos de largura de banda
- Usar recursos avançados de cache
Conteúdo
Servidores Web mais enxutos
Criar um SO mais enxuto
Topologias de aplicativo aperfeiçoadas
Suporte aperfeiçoado de aplicativo
Aumentar a densidade do aplicativo
Redução de largura de banda na compactação
Limitação da taxa de bits da mídia
Cache de saída
Convertendo código ISAPI em módulos IIS 7.0
Extensibilidade do servidor
Conclusão
Quando visito empresas que planejam adotar o IIS 7.0, uma questão que inevitavelmente levantam é se o fato de migrar para o IIS 7.0 irá melhorar o desempenho de servidores ou aplicativos. A
resposta, em geral, é sim, mas não fique surpreso se não observar melhorias de desempenho ao migrar os aplicativos para o IIS 7.0.
Para entender isso, é preciso entender a natureza dessa versão mais recente. O IIS 6.0 era uma versão de engenharia com três objetivos: oferecer mais segurança, mais confiabilidade e melhor desempenho. O IIS 7.0, por sua vez, é uma versão de plataforma. Sua finalidade é converter o núcleo básico do servidor Web de alta qualidade de seu predecessor em uma plataforma modular e extensível com suporte aos principais cenários de gerenciamento e implantação atuais.
Muitas alterações de arquitetura e vários recursos novos podem realmente causar um impacto negativo no desempenho do servidor Web, considerando, por exemplo, que uma das principais alterações decompôs caminhos de código de servidor Web rigidamente otimizados em módulos autônomos que não recebem nenhum tratamento especial do servidor Web. Entretanto, graças ao intenso trabalho no desempenho realizado pela equipe do IIS, o IIS 7.0 não ficou nada a dever ao seu predecessor em termos de desempenho e inclusive o excede em algumas áreas. Posso dizer, por minha própria experiência ao trabalhar com núcleo de servidor Web e pipeline integrado, que esse feito exigiu uma boa dose de criatividade no design e muito trabalho na implementação do produto.
Contudo, o IIS 7.0 tem um potencial muito maior para fornecer melhorias de desempenho significativas e reduzir os custos relacionados ao desempenho para seu farm de servidores do que as antigas versões do IIS.
Você não verá necessariamente essas vantagens apenas migrando para o IIS 7.0, mas isso acontecerá em alguns ambientes. Por exemplo, o Microsoft.com obteve 10% de aperfeiçoamento de eficiência da CPU (você encontrará uma análise completa no blog da equipe do Microsoft.com em go.microsoft.com/fwlink/?LinkId=122497). Talvez você também observe aperfeiçoamentos notáveis em áreas específicas, incluindo no SSL e na autenticação do Windows® (ambos agora executados no kernel), e melhor escalabilidade vertical em computadores multiprocessadores e multinucleados.
No entanto, a verdadeira potência do IIS 7.0 não está nos aperfeiçoamentos de desempenho incrementais para os recursos existentes, mas nos novos recursos que você deve usar ativamente. Em geral, esses recursos se baseiam na flexibilidade e extensibilidade da plataforma e nas novas características de desempenho. Neste artigo, mostrarei as 10 causas mais importantes dos aperfeiçoamentos de desempenho que você pode desvendar ao migrar para o IIS 7.0.
Servidores Web mais enxutos
A capacidade de implantar servidores IIS 7.0 mais enxutos vem da arquitetura modular do servidor. Praticamente todos os recursos de servidor Web são implementados como componentes modulares que podem ser adicionados ou removidos individualmente. Assim, você pode remover qualquer recurso do servidor que não seja necessariamente para uma operação de aplicativo e obter benefícios notáveis, incluindo uma área de superfície de ataque extremamente reduzida, uma superfície operacional menor e um melhor desempenho.
O conjunto de recursos de servidor Web do IIS 7.0 contém 44 módulos, incluindo módulos IIS nativos e módulos ASP.NET que fornecem serviços para o pipeline integrado. Esses módulos fornecem serviços como autenticação (módulos Autenticação do Windows e Autenticação Digest), suporte à estrutura de aplicativos (módulo FastCGI), serviços de aplicativo (módulo Estado da Sessão), segurança (módulo Filtragem de Solicitações) e desempenho (módulo Cache de Saída). No entanto, um servidor Web mínimo que precisa ser usado apenas para conteúdo estático pode operar com apenas dois módulos!
A sobrecarga de módulos desnecessários pode ser muito significativa, por exemplo, no caso de log de solicitação e módulos de rastreamento de solicitação com falha. Remover esses módulos em ambientes em que eles não são necessários pode resultar em uma taxa de transferência total maior e respostas mais rápidas que reduzem a métrica de tempo do primeiro byte (TTFB) e do último (TTLB) para a carga de trabalho do servidor.
A Figura 1 mostra os resultados de um teste de taxa de transferência simples de um arquivo HTML (carga de trabalho estática) e uma página de "alô mundo" do ASP.NET (carga de trabalho do ASP.NET) quando configurado com o conjunto completo de recursos, o conjunto padrão de recursos e o conjunto mínimo de recursos necessários para a carga de trabalho. Muito embora os recursos mais essenciais já estejam desabilitados na configuração Full (Completo), removê-los totalmente na configuração Minimal (Mínimo) resulta em um aumento considerável na taxa de transferência para a carga de trabalho estática e a carga de trabalho do ASP.NET.
Figura 1 Taxas de transferência de carga de trabalho estática e do ASP.NET em três configurações diferentes com 100 clientes simultâneos (clique na imagem para ampliá-la)
Além disso, você pode ver aperfeiçoamentos na superfície da memória e na alta densidade do site, especialmente em ambientes de hospedagem compartilhados ou casos em que um grande número de processos de trabalho é usado. Isso é normalmente obtido carregando menos DLLs em cada processo e eliminando qualquer alocação de memória que ocorra durante a inicialização do módulo e o processamento da solicitação. A Figura 2 mostra o uso de memória (bytes particulares do processo de trabalho do IIS) no mesmo teste de taxa de transferência. Embora os aperfeiçoamentos não sejam tão pronunciados neste exemplo, os aumentos estão alinhados às expectativas, já que a sobrecarga de appdomain do ASP.NET é relativamente mais alta do que as economias de linha de base fornecidas pelos módulos removidos.
Figura 2 Uso de memória (bytes particulares) das cargas de trabalho estática e do ASP.NET em três configurações diferentes com 100 clientes simultâneos (clique na imagem para ampliá-la)
O IIS 7.0 fornece controle adicional sobre os módulos habilitados no nível do aplicativo, bem como sobre o uso do módulo baseado na carga de trabalho por meio de pré-condições do módulo. Embora exija uma configuração avançada, isso pode fornecer vantagens adicionais em ambientes multissite ou para aplicativos que ofereçam suporte a várias cargas de trabalho distintas.
Uma nota de advertência: a tarefa de determinar a funcionalidade necessária pode ser arriscada. Você deve considerar não apenas a funcionalidade mínima necessária para dar suporte à estrutura do seu aplicativo, mas também qualquer recurso adicional do qual seu aplicativo possa depender indiretamente. Por exemplo, seu aplicativo pode depender de métodos de autenticação específicos ou utilizar a semântica de autorização fornecida por vários recursos do IIS e, neste caso, remover aqueles que afetam negativamente a segurança do aplicativo. Da mesma forma, seu aplicativo pode utilizar alguns módulos para efeitos funcionais ou de desempenho e, neste caso, sua remoção pode provocar um comportamento incorreto ou perda de desempenho.
Criar um SO mais enxuto
O Windows Server® 2008 também fornece a componentização no nível do SO que você pode usar para reduzir ainda mais a área de superfície do seu servidor Web. O Server Core é uma opção de instalação mínima para o sistema operacional Windows Server 2008 e contém um conjunto mínimo de subsistemas principais do SO. É um ambiente ideal para servidores Web enxutos do IIS 7.0.
Mas, ao avaliar o Server Core, saiba que algumas de suas limitações podem afetar o seu aplicativo. O Server Core não fornece suporte ao Microsoft® .NET Framework; portanto, pode esquecer do ASP.NET, da extensibilidade do .NET e do Gerenciador do IIS. Além disso, as tarefas de gerenciamento local exigirão ferramentas de linha de comando já que não existe MMC (Console de Gerenciamento Microsoft). Da perspectiva do desempenho, se você já aproveita adequadamente as vantagens da componentização do IIS, talvez não veja diferença na superfície da memória ou na taxa de transferência da carga de trabalho do aplicativo executado no Server Core em comparação com a implementação completa do Windows Server. Isso porque o trabalho executado pelo IIS e o seu aplicativo é o mesmo nas duas plataformas. Entretanto, existe um lugar onde você verá uma diferença: a superfície geral do servidor, em termos de espaço em disco e uso de memória.
Como exemplo, a Figura 3 mostra a diferença na superfície depois de executar o teste de carga de trabalho estática em uma configuração completa do Windows Server 2008 e no Server Core. Embora a superfície do IIS seja praticamente a mesma nos dois casos, a superfície geral do SO do Server Core permite o suporte à carga de trabalho com muito menos memória. A superfície reduzida pode permitir realmente que você implante a carga de trabalho do aplicativo em um hardware menos potente, concentrando-se nas demandas de processamento do aplicativo, e não no ambiente operacional. É claro que, com isso, o Server Core torna-se uma excelente opção para ambientes virtualizados.
Figura 3 Superfície de memória do Windows Server 2008 completo em comparação com o Server Core depois de executar o teste de carga de trabalho estática (clique na imagem para ampliá-la)
Topologias de aplicativo especializadas
Ao otimizar cargas de trabalho de aplicativos, você pode separá-las em partes distintas. Por exemplo, em vez de executar seu aplicativo em um farm de 30 servidores Web idênticos, você pode executá-lo em 10: 5 servidores de aplicativo e 3 servidores proxy que executam cache e compressão.
Essa especialização funciona por vários motivos. Primeiro, o desempenho de várias cargas de trabalho de aplicativo depende muito de diversos recursos compartilhados, como memória, que podem ser contestados em várias partes do aplicativo. A competição por esses recursos pode criar afunilamentos que impedem que cada servidor seja utilizado totalmente nos outros recursos. A separação do aplicativo em partes confere a elas pronto acesso aos recursos que, de outra forma, seriam contestados, aumentando a eficiência no mesmo conjunto de recursos de hardware.
Em segundo lugar, a especialização pode permitir que o aplicativo obtenha mais localidade cache, melhorando assim o desempenho. Isso inclui caches de baixo nível, como o TLB (buffer de conversão à parte) de memória virtual, o cache do sistema e outros caches de aplicativo e do sistema operacional. Outra fonte de ganho de localidade vem da CPU. Ao reduzir o número de atividades paralelas em andamento e se concentrar apenas em uma parte específica, o aplicativo pode reduzir o número de alternâncias de contexto e maximizar o trabalho executado pela CPU.
Em terceiro lugar, a especialização permite a otimização de carga de trabalho específica, tornando cada parte do trabalho do aplicativo mais eficiente. Muitas dessas otimizações não são possíveis quando o mesmo servidor oferece suporte ao aplicativo inteiro, devido às necessidades conflitantes de partes diferentes do aplicativo.
Um lugar em que isso geralmente acontece é na configuração de threads do ASP.NET, que afeta significativamente a simultaneidade e indiretamente o uso de memória, a latência e a taxa de transferência para muitos aplicativos. A carga de trabalho de arquivo estática do IIS é extremamente assíncrona e requer um alto limite de solicitação simultânea, mas o número de threads é bastante reduzido. Entretanto, muitos recursos do ASP.NET são síncronos, de bloqueamento longo e requerem uma contagem de threads alta, enquanto outros requerem um limite de simultaneidade menor para reduzir o impacto na memória. Ao separar a carga de trabalho estática e dividir as partes do pipeline de processamento de solicitações em um processo ou servidor separado, é possível otimizar a simultaneidade de cada carga de trabalho individualmente.
Finalmente, a especialização aceita uma escalabilidade geral maior, permitindo que o aplicativo dimensione cargas de trabalho discretas ou partes do aplicativo independentes. Assim, a topologia do aplicativo fornece mais capacidade e redundância onde elas são mais necessárias, em vez de exigir que você aplique o mesmo modelo ao aplicativo inteiro. Neste modelo, os recursos especializados podem ser servidores físicos, virtuais ou até pools de aplicativos no mesmo computador.
Ao avaliar as possíveis vantagens de especialização na topologia do aplicativo, comece localizando os afunilamentos de processamento ou de uso intensivo de recursos. Essas áreas devem ser as primeiras candidatas à especialização, porque apresentam um potencial significativo para otimização quando isoladas e exigem o maior dimensionamento horizontal. Portanto, avalie se o ato de isolá-las permite que o resto do aplicativo utilize os recursos com mais eficiência. Finalmente, você precisará avaliar a sobrecarga no mecanismo de conectividade necessária para reunir os componentes isolados do aplicativo.
Suporte aperfeiçoado de aplicativo
O IIS 7.0 vem com suporte estendido para estruturas de aplicativo por meio do FastCGI, um protocolo aberto com suporte em várias estruturas de aplicativo de código aberto que, de outra forma, não ofereceriam suporte a uma integração estável e de alto desempenho com o IIS. Diferentemente do protocolo CGI, ao qual o IIS ofereceu suporte durante um longo tempo, o FastCGI fornece um desempenho muito mais aperfeiçoado na plataforma Windows. Isso é possível principalmente por causa da arquitetura de processos reutilizáveis do FastCGI, que elimina a grande sobrecarga de criação de processos por solicitação, permitindo aos clientes aproveitarem as conexões keep alive persistentes.
Se você oferece suporte a estruturas de aplicativo no IIS usando CGI ou outro mecanismo, poderá obter um desempenho aperfeiçoado (e, em alguns casos, estabilidade) migrando para o protocolo Fast CGI.
A primeira estrutura do aplicativo a aproveitar esse suporte é a PHP. Na verdade, a equipe do IIS trabalhou diretamente com a Zend Technologies para garantir que a implantação do FastCGI do IIS funcionasse com PHP e permitisse melhorias de desempenho na estrutura PHP no Windows. (Para saber mais sobre o projeto, consulte a postagem no meu blog em go.microsoft.com/fwlink/?LinkId=122509.) Se você tiver uma mistura de tecnologias de servidor Web que inclua aplicativos ASP ou ASP.NET executados no IIS e PHP ou outras estruturas de aplicativo compatíveis com FastCGI usando outras tecnologias, poderá consolidar esses aplicativos na plataforma do IIS 7.0.
Com a migração do PHP e de outras estruturas de aplicativo para o IIS 7.0 e FastCGI, você poderá aproveitar vários recursos do IIS 7.0, incluindo o pipeline integrado do ASP.NET. É uma opção muito conveniente para aperfeiçoar estruturas de aplicativo com serviços ASP.NET sem convertê-las em ASP.NET. Assim, os aplicativos também podem usar diferentes estruturas para colaborar. Um exemplo de como isso pode ser usado para aperfeiçoar os aplicativos existentes sem alterar nenhum código, consulte o meu artigo da MSDN® Magazine "Aperfeiçoe seus aplicativos com o pipeline integrado do ASP.NET" (disponível em msdn.microsoft.com/magazine/cc135973.aspx).
Aumentar a densidade do aplicativo
O IIS 7.0 inclui vários aperfeiçoamentos destinados a aumentar a densidade dos aplicativos que podem ser hospedados em um único servidor. Esses aperfeiçoamentos fazem parte de diversos recursos que o IIS 7.0 fornece para aperfeiçoar a qualidade da hospedagem compartilhada, incluindo provisionamento aperfeiçoado de sites e melhor isolamento de aplicativos.
Da perspectiva do desempenho, os aperfeiçoamentos visam principalmente dois aspectos de aumento de densidade do aplicativo: aumentar o número de aplicativos que podem ser provisionados em um servidor IIS 7.0 e o número de aplicativos que podem ficar ativos a qualquer momento.
Observe que o IIS 7.0 agora permite provisionar mais aplicativos em cada servidor do que antes (em alguns testes internos, foi possível até 100.000 sites em um único servidor). Isso mostra a capacidade de criar e configurar um grande número de sites e aplicativos.
Uma nota de advertência: para obter um provisionamento de alta velocidade, é necessário migrar as novas APIs de configuração, já que as antigas não podem obtê-lo. Além disso, nem todas as APIs de configuração do IIS fornecem as mesmas características de desempenho, portanto, faça uma escolha cuidadosa para garantir um alto desempenho. Em dúvida, opte pelas opções de configuração que aproveitam os novos objetos de configuração do IIS diretamente, incluindo o namespace Microsoft.Web.Administration, a ferramenta de linha de comando AppCmd.exe e os objetos de configuração COM do IIS acessados por código de script, .NET ou C++.
A diferença entre o número de sites que podem ser provisionados e o número que podem ficar ativos é uma distinção muito importante na arquitetura do IIS, que usa aplicativos e processos de trabalho persistentes para executar o processamento de solicitações. Neste modelo, os aplicativos ativos consomem mais recursos no servidor, mas também fornecem um melhor desempenho sustentado graças ao cache e aos custos de inicialização removidos.
Como cada aplicativo ativo requer uma determinada quantidade de memória e um processo de trabalho separado (se o modelo de isolamento de aplicativo recomendado for usado), o número de aplicativos ativos depende muito de sua superfície de memória. Portanto, embora um único aplicativo usado apenas para conteúdo estático exija apenas 3 MB para o processo de trabalho (e possa até compartilhar o mesmo processo de trabalho com outros aplicativos de conteúdo estático), alguns aplicativos dinâmicos podem exigir 100 MB ou mais de RAM inclusive com baixa utilização. Isso torna a sobrecarga de memória do processo de trabalho em si do IIS insignificante quando comparada com a superfície do aplicativo ao definir a máxima densidade possível.
No cenário de hospedagem compartilhado, é comum ver o que é chamado de distribuição 80/20, em que 80% das solicitações vão para 20% dos sites. Com isso, uma pequena porcentagem de sites fica ativa a qualquer momento. Para permitir um número maior de sites ativos, o IIS 7.0 fornece um gerenciamento de tempo de vida ativo. Isso pode ajudá-lo a recuperar memória de aplicativos inativos para permitir que mais aplicativos ativos sejam hospedados.
O IIS 7.0 apresenta um novo algoritmo chamado ociosidade dinâmica, que ajusta de forma proativa os limites de ociosidade dos processos de trabalho com base na memória disponível do servidor. Conforme a memória se torna baixa, os aplicativos ociosos são removidos com mais rapidez, permitindo que mais aplicativos ativos sejam hospedados. Entretanto, se a memória estiver disponível, os limites poderão permanecer grandes para fornecer melhor desempenho e manter o estado do aplicativo. Além de permitir que mais aplicativos fiquem ativos, a ociosidade dinâmica também ajuda a evitar condições de memória baixa que causam uma séria degradação de desempenho devido à paginação excessiva.
Para tornar a hospedagem de vários aplicativos ativos possível, você também deve aproveitar o sistema operacional de 64 bits, que permite ao sistema dedicar mais de 4 GB de memória. Além disso, você pode configurar os processos de trabalho do IIS para serem executados no modo de 32 bits (SysWoW64), no qual consomem menos memória e permitem que o SO dedique mais memória do que seria possível em um ambiente de 32 bits.
Redução de largura de banda na compactação
Não é de espantar que os custos de largura de banda sejam um dos principais na execução de um data center voltado para a Internet. Além disso, a largura de banda necessária para fornecer o conteúdo solicitado é um fator importante na resposta percebida no seu aplicativo.
Uma das formas mais eficientes de reduzir a largura de banda necessária para fornecer as respostas dos aplicativos é usar a compactação HTTP. Ela pode reduzir o tamanho da resposta de forma substancial, com freqüência, em até 10 vezes, quando aplicada a um conteúdo de texto facilmente compactável como HTML. A melhor parte é que ela possui suporte em praticamente todos os navegadores desktop e os custos de descompactação em hardware de desktop são pequenos comparados à economia de latência obtida no envio de menos dados. E, como a compactação se baseia na negociação de codificação de conteúdo definida no protocolo HTTP 1.1, é seguro habilitá-la para clientes que não oferecem suporte a compactação (esses clientes simplesmente recebem uma versão não compactada do conteúdo).
O IIS 7.0 fornece os dois recursos de compactação apresentados por seu predecessor: compactação estática e dinâmica. A estática compacta previamente o conteúdo estático e o salva no disco, permitindo que solicitações futuras usem o conteúdo compactado diretamente sem sobrecarga de compressão. A dinâmica compacta a resposta em tempo real e, por isso, permite a compactação para as respostas geradas pelos aplicativos. Qualquer estrutura de aplicativo no IIS 7.0 pode utilizar a compactação dinâmica, incluindo ASP, ASP.NET ou PHP.
Apesar de um mito comum, a compactação dinâmica normalmente não tem uma sobrecarga de CPU proibitiva. Na verdade, em geral, a compactação dinâmica é responsável por menos de 5% da utilização total da CPU em um servidor ocupado. A compactação dinâmica pode ser implantada de forma relativamente livre para permitir a máxima economia de largura de banda na carga de trabalho de qualquer aplicativo.
Você pode otimizar ainda mais a sobrecarga de compactação configurando sua potência para obter a compactação desejada em relação à taxa de sobrecarga da CPU. Mas isso não é tudo. Você também pode configurar seu aplicativo para permitir o cache do conteúdo compactado, eliminando a sobrecarga de compactação nos acertos de cache pelo uso do conteúdo já compactado. Observe que os caches de saída do ASP.NET e do IIS foram atualizados com o recurso opcional de armazenar em cache o conteúdo compactado para clientes que ofereçam suporte a isso, bem como manipular as solicitações de clientes que exigem conteúdo não compactado.
Limitação da taxa de bits da mídia
Com o aumento do número de sites que oferecem conteúdo de mídia, os custos de largura de banda para muitas empresas estão disparando. O que é pior, boa porcentagem da largura de banda é desperdiçada porque o conteúdo de mídia enviado ao cliente não é usado. Por que isso acontece?
Lembre-se da última vez em que assistiu a um vídeo online ou viu um anúncio de vídeo ao navegar. Você assistiu ao vídeo até o fim? É muito comum aos usuários que navegam em sites de vídeo assistirem apenas parte de um vídeo e passarem para outro ou saírem da página. Entretanto, um servidor Web usando download progressivo para fornecer o vídeo, em geral, envia muito mais dados do que o necessário durante aqueles poucos segundos de reprodução. A maior parte daqueles dados nunca é usada.
Se os seus vídeos obtêm em média 5 segundos de tempo de exibição, mas fornecem o equivalente a 30 segundos (buffer) de dados do vídeo nesses 5 segundos, provavelmente você está gastando mais de 80% da sua largura de banda!
Há um ano, para resolver esse problema para um cliente que adotou uma versão beta do IIS 7.0, escrevi um módulo de limitação de largura de banda que detectava automaticamente a taxa de bits do vídeo e garantia que o servidor fornecesse o vídeo ao cliente basicamente na mesma taxa. A equipe de mídia do IIS selecionou esse módulo, conhecido como Bit Rate Throttling Module (Módulo de limitação de taxa de bits, consulte a Figura 4) e ele está disponível no centro de download do iis.net (iis.net/downloads/?tabid=34&g=6&i=1640). Saiba mais sobre isso no blog de Scott Guthrie (disponível em go.microsoft.com/fwlink/?LinkId=122514).
Figura 4 A limitação de taxa de bits minimiza o uso da largura de banda (clique na imagem para ampliá-la)
O Bit Rate Throttling Module detecta a taxa de codificação dos tipos de vídeo mais conhecidos. Você pode controlar quantos dados deseja enviar previamente ao cliente para eliminar os atrasos de buffer iniciais (início rápido) e a porcentagem da taxa codificada que deseja de fornecer ao conteúdo. Também é possível configurar várias outras opções, como o máximo de conexões simultâneas e de largura de banda, e controlar o módulo programaticamente.
Cache de saída
Em termos gerais, o cache é o método mais usado para melhorar o desempenho de aplicativos que executam trabalhos repetidos. Diferentemente dos aperfeiçoamentos de desempenho específicos de aplicativo, que em geral exigem muito esforço e sobrecarga de processamento de um aplicativo, o cache elimina a sobrecarga de solicitações repetidas para o mesmo conteúdo.
Antes do IIS 7.0, o IIS e o ASP.NET ofereciam recursos de cache por meio do cache de kernel do IIS e do Cache de Saída do ASP.NET. O cache de kernel do IIS fornecia o máximo de desempenho, mas se restringia basicamente ao conteúdo estático. O Cache de Saída do ASP.NET era uma solução muito mais completa para o cache de conteúdo dinâmico, embora com um desempenho menor e um gerenciamento de memória menos eficiente. O novo Cache de Saída do IIS 7.0 preenche a lacuna entre o cache de kernel do IIS e o Cache de Saída do ASP.NET.
O Cache de Saída do IIS 7.0 permite o cache do conteúdo dinâmico de qualquer aplicativo, incluindo ASP, ASP.NET, PHP e qualquer outra estrutura de aplicativo compatível com o IIS 7.0. Ao fornecer suporte básico à variabilidade e expiração de conteúdo, esse novo recurso torna possível implementar o cache de um conteúdo que não pode ser armazenado pelo cache de kernel do IIS. No entanto, ele permite o uso de cache de kernel para um conteúdo que atenda às restrições.
Além disso, o Cache de Saída do IIS 7.0 também fornece uma alternativa de desempenho maior para o Cache de Saída do ASP.NET para um conteúdo ASP.NET que não exija os recursos de cache avançados (como dependências ou invalidação de cache) que só estão disponíveis no Cache de Saída do ASP.NET.
Quando se trata de cache de saída, os desafios normalmente são definir as diretivas apropriadas de expiração de conteúdo, invalidação e variabilidade que permitem um cache de resposta eficiente enquanto mantêm a precisão e a atualização de cache necessárias. Em geral, é possível fazer isso simplesmente configurando as regras de cache apropriadas, embora algumas situações exijam diretivas mais complexas que dependem de informações de runtime. Para resolve isso, o Cache de Saída do IIS 7.0 fornece APIs programáticas que podem ser usadas para garantir o comportamento de cache necessário. Isso desbloqueia o possível desempenho do cache para um conteúdo que, de outra forma, não se beneficiaria com o cache. Além disso, o pipeline integrado do ASP.NET permite o uso do Cache de Saída do ASP.NET para conteúdo que não seja ASP.NET.
Implantar o cache de saída para conteúdo dinâmico pode ser arriscado e exibir uma estratégia multicamada para aproveitar as eficiências e a flexibilidade dos diferentes recursos de cache na plataforma do IIS 7.0. Isso com freqüência inclui descrever vários parâmetros que afetam a resposta e definir as estratégias de expiração e invalidação para manter a atualização do cache e determinar qual cache oferecerá suporte à semântica necessária.
Mas essa complexidade quase sempre vale a pena. Ao implementar o Cache de Saída do IIS 7.0, você pode obter aperfeiçoamentos em vários graus de importância na taxa de transferência geral do seu aplicativo e uma redução correspondente de carga no banco de dados e nos componentes de camada empresariais.
Convertendo código ISAPI em módulos do IIS 7.0
O IIS 7.0 apresenta uma nova API de servidor na qual todos os seus módulos se baseiam. Ela substitui as APIs de filtro e a extensão ISAPI herdadas usadas nas versões anteriores do IIS. Para novos módulos que não precisam oferecer suporte a versões anteriores, as novas APIs são mais fáceis de usar, ajudam a produzir código de servidor mais confiável e são muito mais poderosas.
Entretanto, o IIS 7.0 fornece uma opção para oferecer suporte aos filtros e às extensões ISAPI por meio de uma camada de compatibilidade implementada por módulos do IIS 7.0 opcionais. Assim, os componentes ISAPI existentes podem funcionar no IIS 7.0 sem ser necessário reescrevê-los.
Embora o uso de investimentos de ISAPI existentes reduza a barra para a migração do IIS 7.0, você deve considerar seriamente o uso do código ISAPI herdado nas novas APIs do IIS 7.0. Com isso, você elimina a sobrecarga da camada de compatibilidade ISAPI e aproveita as vantagens de desempenho que não estão disponíveis para componentes ISAPI. Dependendo do trabalho executado pelo componente ISAPI, essas vantagens de desempenho podem ser bastante significativas. Por exemplo, a API de módulo do IIS 7.0 fornece suporte interno ao cache de metadados de configuração e outros dados arbitrários associados a sites, aplicativos e URLs, que podem acelerar bastante as operações internas do componente.
Além disso, a API de módulo do IIS permite que os módulos executem operações assíncronas de longa duração, como receber dados de entidades de solicitação ou enviar resposta. A execução dessas tarefas assíncronas possibilita que o servidor atenda a um grande número de clientes simultâneos (dezenas de milhares), em vez de maximizar em dezenas ou, no máximo, centenas de clientes simultâneos devido aos limites no número de threads de solicitação. O processamento assíncrono também pode eliminar o efeito do processamento em outras solicitações e atividades no aplicativo, reduzir o uso de memória e permitir uma melhor utilização da CPU.
Acima dos padrões específicos que afetam o desempenho, a API nativa fornece aos desenvolvedores mais flexibilidade para tarefas de processamento de solicitação. Assim, você poderá melhorar o design de componente do servidor e, em troca, habilitar grandes eficiências. Por exemplo, algumas tarefas de filtragem que anteriormente exigiam extensões ISAPI de caractere curinga e execução de solicitação filho agora podem ser executadas em um módulo durante a solicitação original e também podem habilitar o cache de kernel IIS para a resposta.
Pode ser necessário um protótipo e uma experimentação para determinar o design ideal que maximize as vantagens da migração. Devido a diferenças fundamentais de arquitetura entre a API de módulo do IIS 7.0 e ISAPI, a rota direta não é necessariamente a correta. A boa notícia é que a API de módulo do IIS 7.0 também é mais simples de usar que a ISAPI, o que torna a migração menos difícil.
Extensibilidade do servidor
O IIS 7.0 oferece extensibilidade de ponta a ponta. Ele requer uma boa dose de conhecimento prévio sobre a operação do servidor, mas também fornecem um grande potencial para ganhos de desempenho específico de aplicativo. Conhecendo um pouco da arquitetura do servidor e o processamento de solicitações, você pode aproveitar essa extensibilidade para criar soluções de desempenho personalizadas específicas para as exigências de aplicativo, carga de trabalho e hardware.
Isso pode ser feito substituindo qualquer recurso interno do IIS 7.0 por implementações personalizadas. Embora os recursos do IIS 7.0 tenham sido submetidos a diversos testes de otimização e desempenho, obviamente, eles não foram otimizados para todos os possíveis tipos de uso. Portanto, você pode melhorar o desempenho de módulos específicos criando otimizações para sua carga de trabalho específica. Por exemplo, você pode decidir reimplementar o módulo de listagem de diretório para armazenar na memória o cache de listagens de diretório em vez de usar as APIs de sistema de arquivo para enumerar arquivos.
Opcionalmente, a extensibilidade pode ser usada para criar novos recursos de desempenho. Os exemplos internos de tais recursos incluem o Cache de Saída, os módulos de compressão e vários outros caches internos.
Para determinar a necessidade de um recurso de desempenho personalizado, é necessário entender as características de desempenho do aplicativo e sua carga de trabalho, bem como conhecer o afunilamento a ser resolvido. O IIS 7.0 fornece um amplo suporte de diagnóstico para análise de desempenho, que pode tornar mais claros os requisitos e o possível design dos recursos necessários.
Conclusão
Embora o lançamento do IIS 7.0 seja basicamente uma versão funcional, ele oferece aperfeiçoamentos dignos de nota derivados de sua arquitetura modular, configurabilidade e novos recursos de desempenho. Esses aperfeiçoamentos podem preparar o caminho para economias de negócio significativas por meio da consolidação do servidor e dos custos de largura de banda reduzidos, bem como fornecer uma melhor experiência do usuário.
Para aproveitar adequadamente muitos desses recursos, é necessário executar uma análise detalhada da plataforma do seu aplicativo atual e adquirir uma boa dose de conhecimento da arquitetura do IIS 7.0. Para saber mais sobre a arquitetura e os recursos do IIS 7.0 mencionados neste artigo, visite o iis.net. No mvolo.com, falarei mais no blog sobre técnicas que aproveitam de forma proativa o IIS 7.0 para melhorar o desempenho do aplicativo e reduzir os custos operacionais.
Mike Volodarsky foi gerente de programa da equipe de IIS na Microsoft. Nos últimos cinco anos, controla o design e desenvolvimento dos principais recursos para o ASP.NET 2.0 e o IIS 7.0. Agora, ele cria tecnologias de servidor Web avançadas para farms da Web de alto desempenho usando o IIS 7.0 e o Windows Server 2008. Mike é autor do livro IIS 7.0 Resource Kit (Kit de recursos do IIS 7.0) e escreve ativamente para a MSDN Magazine e seu blog do IIS 7.0, mvolo.com.