12 dicas para aumentar o desempenho do seu aplicativo ASP.NET – Parte 1

Criar e hospedar um aplicativo Web em um servidor Web é incrivelmente fácil com o ASP.NET e o IIS. No entanto, muitas oportunidades e configurações ocultas podem ser ajustadas para torná-lo um aplicativo da Web de alto desempenho. Nesta postagem da série, discutiremos alguns dos truques mais não utilizados ou ignorados que podem ser facilmente aplicados a qualquer aplicativo da web.

1. Cache do modo kernel

É uma das principais ferramentas amplamente utilizadas para escrever, tornando os aplicativos da web mais rápidos. Mas na maioria das vezes, não o usamos de maneira ideal, deixando alguns benefícios importantes.  Como cada solicitação asp.net passa por vários estágios, podemos implementar o cache em vários níveis, conforme abaixo.

Podemos ver que a solicitação é recebida primeiro pelo HTTP.sys, portanto, se ela estiver armazenada em cache no nível do kernel, podemos economizar a maior parte do tempo gasto no servidor, pois HTTP.sys é um ouvinte HTTP que fica no kernel do sistema operacional e escuta a solicitação diretamente da camada TCP. Podemos economizar todo o tempo gasto no pipeline do IIS/ASP.NET, no ciclo de vida da página, em nosso código personalizado, no tempo gasto no banco de dados, etc. Vamos ver como podemos implementá-lo.

a)      Vá para o IIS e selecione o site.

b)      Clique no ícone do cache de saída à direita na seção IIS

c)       No painel direito, em Ações, clique em Adicionar. A seguinte caixa de diálogo será aberta:

Aqui, na área circundada em vermelho, devemos definir as extensões de arquivo que queremos armazenar em cache no kernel. Para a segunda área circundada, precisamos marcar a caixa de seleção. A terceira área circundada mostra que há três opções fornecidas para invalidar o cache. Com base em nossos requisitos, podemos configurá-lo.

Observação – existem algumas limitações para o overcaching no nível do kernel. Como todos os recursos do IIS são implementados no nível do usuário, não poderemos aproveitar nenhum deles. Consulte este artigo do MSDN para obter uma lista completa do cache de kernel que não pode ser implementado.

2. Modo de pipeline (disponível no IIS 7+)

Dois modos de pipeline estão disponíveis no nível do pool de aplicativos: clássico e integrado. O Classic está disponível para dar suporte aos aplicativos que foram migrados do IIS6. Então, primeiro, vamos entender esses modos. O IIS fornece muitos recursos que são implementados como módulos no IIS e, de maneira semelhante, muitos recursos são implementados como um módulo HTTP, que faz parte do ASP.NET Pipeline. No modo clássico, cada solicitação passa pelo pipeline do IIS e, em seguida, pelo pipeline do ASP.NET antes de ser atendida.

Existem muitos recursos que fazem parte de ambos os pipelines, como Autenticação, etc. No caso do modo Integrado, esses dois pipelines são mesclados em um e todos os módulos (IIS e ASP.NET) são invocados a partir de um único evento à medida que surgem, o que reduz a redundância e é muito útil no desempenho de um aplicativo.

Para definir/atualizar o modo de pipeline, selecione o pool de aplicativos desejado e clique com o botão direito do mouse nas propriedades.

Aqui, conforme circundado na foto acima, podemos definir o modo de pipeline.

Nota - Não vá alterá-lo cegamente, se o seu aplicativo migrou do IIS6, pode haver alguma dependência dele. Depois de mudar completamente, teste-o antes de prosseguir.

3. Remove Unused Modules

Cada solicitação passou pelo ASP.NET Pipeline, que contém muitos módulos HTTP e, no final, um manipulador HTTP, que atende à solicitação conforme abaixo.

Podemos ver aqui que a solicitação passa por cada módulo, é processada pelo manipulador e, em seguida, passa novamente pelos mesmos módulos. Vamos ver quantos módulos são, por padrão, habilitados em um aplicativo ASP.NET. Eu adicionei o código abaixo para obter todos os módulos.

HttpApplication httpApps = HttpContext.ApplicationInstance;
 
//Get list of active modules
HttpModuleCollection httpModuleCollections = httpApps.Modules;
ViewBag.ModulesCount = httpModuleCollections.Count;

Essa coleção pode ser associada a qualquer controle e é exibida como:

Ele mostra dezoito módulos, alguns dos quais podemos não estar usando, mas cada solicitação deve passar por esses módulos. Assim, podemos remover esses módulos do pipeline. Para remover um módulo, precisamos adicionar a configuração em web.config como:

 <system.webServer>
    <modules>
      <remove name="FormsAuthentication" />
      <remove name="DefaultAuthentication" />
      <remove name="OutputCache" />
      <remove name="AnonymousIdentification" />
      <remove name="RoleManager" />
    </modules>
  </system.webServer>

Aqui, listamos os módulos que queremos remover com a tag remove. Agora, como adicionamos aqui, remova cinco módulos, da próxima vez, quando verificarmos os módulos ativos, serão treze.

Nota – Para esta demonstração, usei o VS 2013, você pode obter um número diferente ao usar outra versão, mas o ponto principal é que devemos remover todos os módulos que não são necessários.

4. runAllManagedModulesForAllRequests

É outra configuração que deve ter sido vista em web.config ou applicationHost.config, onde é definida globalmente para todos os aplicativos nesse IIS como:

<modules runAllManagedModulesForAllRequests="true">

Isso significa que todos os módulos estariam em execução para todas as solicitações que chegam ao aplicativo, mas normalmente não exigimos isso porque ele deve executar apenas ASP.NET arquivos, não outros arquivos como CSS, js, jpg, HTML, etc. Isso significa até mesmo a solicitação desses recursos passando pelo pipeline, o que é desnecessário para esses arquivos, e apenas adiciona sobrecarga extra. Mas não podemos torná-lo simplesmente falso no nível do aplicativo. Portanto, pode haver duas maneiras -

a)      Crie um aplicativo diferente apenas para servir esses recursos estáticos e defina essa configuração como false em web.config.

b)      Ou, no mesmo aplicativo, coloque todos os recursos estáticos em uma pasta e adicione um arquivo web.config específico a essa pasta e torne-o falso.

 

5. Não escreva nada na pasta c:\inetpub\wwwroot

Um observador de arquivos examina a pasta e reinicia o pool de aplicativos correspondente se houver alguma alteração nessa pasta. Esse recurso está disponível no IIS; Se houver alguma alteração em Web.config ou em qualquer arquivo, ele reiniciará o pool de aplicativos para que o aplicativo modificado atenda à solicitação. Agora, digamos que você escreva o log do aplicativo em algum arquivo de texto dentro da pasta do aplicativo, o que faz algumas entradas em cada solicitação, o pool de aplicativos seria reiniciado muitas vezes, o que seria perigoso para o seu aplicativo. Portanto, não escreva ou altere nada nesta pasta até que ela não faça parte dos binários do aplicativo.

6. Remova os mecanismos de visualização extra

a) Como sabemos, o View Engines faz parte do ciclo de vida da solicitação MVC e é responsável por encontrar a view e processá-la. Ele também nos permite adicionar nossos próprios mecanismos de visualização personalizados. Vamos criar um aplicativo MVC padrão e tentar retornar uma exibição que não existe na solução. Agora, quando executamos este aplicativo, ele mostra o seguinte erro.

Isso mostra que está procurando os arquivos razor e aspx para todos os locais possíveis. Mas, como sabemos, estamos usando o mecanismo de visualização razor, portanto, não devemos perder tempo olhando para outros arquivos aspx porque já sabemos que ele não fará parte da solução. Portanto, devemos remover todos os mecanismos de visualização extras.  Precisamos adicionar o código a seguir no método Application_Start, que está disponível em Global.asax.

// Removing all the view engines
ViewEngines.Engines.Clear();
 
//Add Razor Engine (which we are using)
ViewEngines.Engines.Add(new RazorViewEngine());

Agora vamos executá-lo novamente

Agora, ele está procurando apenas arquivos razor

b)      Se virmos cuidadosamente as telas acima quentes, sabemos que ele está procurando por arquivos c# e vb e diz em nossas soluções, nunca usamos vb, então, novamente, não adianta procurar arquivos vbhtml. Para corrigir isso, precisamos escrever nosso próprio ViewEngine personalizado. Então, vamos escrever nosso RazorViewEngine personalizado como:

    public class MyCustomViewEngine : RazorViewEngine
    {
        public MyCustomViewEngine()
        {
            base.AreaViewLocationFormats = new string[] { "~/Areas/{2}/Views/{1}/{0}.cshtml", "~/Areas/{2}/Views/Shared/{0}.cshtml"};
            base.AreaMasterLocationFormats = new string[] { "~/Areas/{2}/Views/{1}/{0}.cshtml", "~/Areas/{2}/Views/Shared/{0}.cshtml" };
            base.AreaPartialViewLocationFormats = new string[] { "~/Areas/{2}/Views/{1}/{0}.cshtml","~/Areas/{2}/Views/Shared/{0}.cshtml"};
            base.ViewLocationFormats = new string[] { "~/Views/{1}/{0}.cshtml", "~/Views/Shared/{0}.cshtml" };
            base.MasterLocationFormats = new string[] { "~/Views/{1}/{0}.cshtml", "~/Views/Shared/{0}.cshtml" };
            base.PartialViewLocationFormats = new string[] { "~/Views/{1}/{0}.cshtml", "~/Views/Shared/{0}.cshtml" };
            base.FileExtensions = new string[] { "cshtml" };
        }
    }

Aqui, eu o herdei de RazorViewEngine,e se virmos o construtor no, então descobrimos que lá definimos todos os locais possíveis onde um arquivo pode existir, o que inclui possíveis extensões de arquivo também. Agora vamos usar este View Engine em Global.asax.

E execute o aplicativo.

Agora ele procura arquivos de navalha csharp que façam sentido e sejam amigáveis ao desempenho.

Conclusão

Neste post, discutimos as seis dicas a seguir, que podem ser facilmente aplicadas a qualquer aplicativo ASP.NET.

1 –   Cache do modo kernel

2 – Pipeline mode

3 –  Remove unused modules

4 –   runAllManagedModulesForAllRequests

5 –  Don’t write in wwwroot

6 –  Remova os mecanismos de exibição e o idioma não utilizados

No próximo post da série, discutiremos mais cinco dicas que funcionarão como um impulsionador de desempenho para os aplicativos.