12 dicas para aumentar o desempenho de ASP.NET APPs – Parte 2

Este post é a segunda parte do meu post anterior, onde discutimos seis dicas para melhorar o desempenho de aplicativos ASP.NET. Neste post, vamos discutir mais seis dicas que podem ser mais uma rodada de impulsionador para o desempenho do seu aplicativo. O link para o post anterior está abaixo.

12 dicas para aumentar drasticamente o desempenho de ASP.NET aplicação – Parte 1

7. Torne sua página assíncrona

O IIS usa o pool de threads CLR para obter um thread que processa uma solicitação que chega ao aplicativo. Digamos, se houver atualmente vinte threads disponíveis no pool, isso significa que apenas vinte solicitações podem ser atendidas em paralelo e, se o processamento de solicitações levar algum tempo, poderá se transformar em um desastre se centenas de solicitações ímpares forem bombardeadas em poucos milissegundos. Nesse caso, algumas das solicitações podem levar muito tempo e, para algumas, podem retornar o código de status 404. Para qualquer solicitação, a parte significativa do tempo desaparece quando a solicitação sai do escopo atual, como ir ao banco de dados e buscar ou ler / gravar o arquivo, chamar os serviços da Web etc. Durante esse período, o thread atual continua aguardando até que a resposta seja retornada. Portanto, se fizermos a página assíncrona e as chamadas demoradas forem tratadas de forma assíncrona, poderemos aumentar consideravelmente a taxa de transferência. Para processar uma página de forma assíncrona, adicione uma diretiva assíncrona na página como

Além disso, agora escrever código assíncrono tornou-se tão fácil com a introdução das palavras-chave async e await. Podemos escrever métodos assíncronos e usá-los com a ajuda do método RegisterAsyncTask da página.

8. Suspensão do pool de aplicativos

Esse recurso foi introduzido com o Windows Server 2012 R2 e o .NET 4.5.1. O IIS fornece uma configuração de tempo limite ocioso para pools de aplicativos que, por padrão, são definidos como 20 minutos. Isso significa que, se não houver solicitação por 20 minutos, o processo de trabalho (w3wp.exe) será interrompido para economizar os recursos do servidor. Mas tem um efeito colateral, pois o processo de trabalho está parado no momento, a próxima solicitação se torna uma vítima porque, ao atendê-la, o processo de trabalho é necessário para reiniciar e inicializar. A reinicialização do processo de trabalho é um processo caro e demorado, pois inclui muitas tarefas, como iniciar o processo, inicializar configurações, inicializar asp.net, carregar os binários, etc. na memória.

Esse recurso nos permite suspender o processo em vez de interrompê-lo.  Após a suspensão, ele libera a maior parte da CPU e da memória, que fica disponível para outros sites hospedados no mesmo servidor. Mas ele é mantido em um estado, se uma solicitação chegar, ele se tornará ativo rapidamente e começará a atender a solicitação. É semelhante à suspensão em aplicativos do Windows, onde temos conceitos de aplicativos ativos e suspensos.  Ajuda em duas dobras, primeiro nos permite servir de forma mais otimizada, adicionando mais aplicação e até mesmo a solicitação que vem após um tempo limite, também servida rapidamente sem muita diferença com as ativas. Podemos configurar em qualquer pool de aplicativos como

Select application pool -> advanced settings

9. Remova os métodos de Global.asax

Global.asax nos fornece alguns métodos de nível de aplicativo em que alguns são disparados uma vez na primeira solicitação, enquanto outros são disparados em cada solicitação. Na maioria das vezes, temos métodos vazios nesses arquivos, o que asp.net força a executar esses métodos, mesmo que não haja código dentro. Em cada solicitação, ASP.NET verifica se há algum método disponível em Global.asax e, em caso afirmativo, ele o carrega e o executa de acordo. Então, em primeiro lugar, devemos remover métodos vazios e, mesmo que possamos remover alguns métodos de lá, colocando o código em algum outro lugar no ciclo de vida da página, isso também será útil.

10. Não use SqlDataSource

Evite usar SqlDataSource como a fonte de dados para controles de dados como GridView. No caso do GridView, se a paginação estiver habilitada, no clique no número da página, ele buscará todos os registros do banco de dados e, em seguida, aplicará a paginação por conta própria. O mesmo vale para a classificação. Em vez disso, use a associação de modelo introduzida no ASP.NET 4.5, onde podemos usar consultas IQueryable e usar o método select etc para retornar a lista de itens. IQueryable nos bastidores otimize e crie as consultas SQL de forma inteligente que buscam apenas os dados necessários do banco de dados, como apenas dez registros, em vez de todos os registros, ou classificam os dados no nível do banco de dados. Isso torna a paginação e a classificação muito eficientes. Da mesma forma, também podemos usar QueryableDataSource ou ObjectDataSource.

11. Use HTTP Keep-Alive

É outra joia escondida que reside no cabeçalho de resposta e ajuda a melhorar significativamente o desempenho de nossos aplicativos da web. Esse cabeçalho de resposta mantém a conexão do cliente e do servidor aberta por um período específico e é utilizado por várias solicitações. Caso a conexão esteja aberta, o tempo para criar uma nova conexão é salvo, o que permite que o servidor envie a resposta muito rapidamente. Por padrão, ele está habilitado e a conexão é aberta por 120 segundos. Se estiver desabilitado, ele se comportará como HTTP 1.0, onde apenas uma solicitação por conexão é permitida. Podemos configurá-lo no IIS como

Vá para IIS -> Selecione o site desejado -> Abrir cabeçalhos de resposta HTTP -> Clique em Definir cabeçalhos comuns na guia de ação à direita

Está ativado por padrão (consulte a área circundida). Verifique-o para verificar se seu aplicativo está aproveitando esse recurso ou não.

Observação – Para o IIS 7.5 e superior, essa marca de cabeçalho é removida do cabeçalho de resposta e, por padrão, ela é habilitada conforme discutido, mas há outra marca de cabeçalho em maiúsculas e minúsculas opostas. Se estiver desabilitado, no cabeçalho de resposta, haverá um novo cabeçalho disponível como Conexão: fechar. Isso significa que a conexão é fechada após a solicitação.

12. Remove ETag

Vamos dar uma olhada em um cabeçalho de resposta HTTP

Aqui podemos ver que há um elemento como ETag (Consulte Vermelho circundado). Vamos tentar entender a forma como é usado. Se alguma resposta é atendida pelo cache do cliente ou não, depende de dois itens: um é o atributo Cache-Control e Expires e outro ETag. ETag é um código hash que é criado no servidor web para cada conteúdo e, no caso de o conteúdo do arquivo mudar, o hash muda o que invalida o cache. No cenário de Web Farm, o hash criado em um servidor diferente será diferente, mesmo que o conteúdo seja o mesmo, pois o hash também depende do servidor. Portanto, a solicitação não será atendida do cache, mesmo que o conteúdo seja o mesmo, se a solicitação for para outro servidor web. Portanto, é melhor removermos essa tag em si para obter o melhor uso do cache do cliente se o aplicativo estiver hospedado em um web farm.

Essa dica é um conjunto de algumas alterações de configuração muito importantes, que podem causar um impacto significativo no desempenho do seu aplicativo.

um.       Discutimos anteriormente que o IIS usa o pool de threads CLR para atender à solicitação. Vamos dar um exemplo, se nosso aplicativo receber até 100 solicitações simultaneamente e esse número de threads não estiver disponível no pool de threads, alguns deles terão que esperar. O CLR começa a criar novos threads para atribuir cada solicitação. A criação de novos threads é um processo bastante pesado e, nas versões anteriores do .net, a taxa de criação de threads era de dois segundos por thread, enquanto na versão mais recente era de cerca de 0,5 segundo. Considerando 0,5 segundos por thread, a criação de oitenta threads levará quarenta segundos, então podemos entender que o tempo de resposta variaria pelo menos 1-40 segundos. Você pode imaginar a situação se um número de solicitações for 500 ou 1000.

Há uma configuração em machine.config que é, por padrão, como

Que podemos mudar como:

  maxWorkerThreads = "200" />

Como definimos a contagem minWorkerThread como 100, isso reduzirá o tempo gasto na criação de cada thread e o IIS estará pronto para receber as solicitações rapidamente. Observe que as configurações acima estão ativadas por núcleo da CPU.

b.      Há outra configuração importante disponível em applicationHost. Config (pode ser definido no nível do pool de aplicativos) como maxConcurrentRequestsPerCPU (disponível no IIS 7+), que está nas versões mais recentes, é 5000, pode ser ajustado com base nos requisitos. Como o nome sugere, ele define os limites em que o número de solicitações simultâneas pode ser processado pelo aplicativo.

c.        maxConnection é outra configuração muito importante. Limita o número de conexões que podem ser criadas para algum outro sistema. O valor padrão era 2 em versões anteriores of.NET. Ele entra em cena quando o servidor web faz uma chamada para outra máquina na rede, como serviços de banco de dados / wcf, etc. Isso significa que, em um determinado momento, apenas duas conexões podem ser feitas, mesmo se você tiver servidores de última geração com boa conectividade. Ele pode ser alterado no nível da máquina ou no nível da aplicação como

Aqui mudamos para cem. Com base na necessidade, podemos aumentar ou diminuir, mas é aconselhável mantê-lo moderado, caso contrário, pode ser um exagero. Além disso, podemos fornecer detalhes mais específicos, como endereço IP ou informações de domínio, para limitá-lo a servidores específicos na rede.

Conclusão

Nesta série, discutimos as seguintes doze dicas, a maioria delas podemos aplicar facilmente sem qualquer alteração de código que possa melhorar drasticamente o desempenho do seu aplicativo da web. Estes são:

1. Cache do modo kernel
2. Pipeline mode
3. Remove unused modules
4. runAllManagedModulesForAllRequests
5. Don’t write in wwwroot
6. Remover mecanismos de exibição e idioma não utilizados
7. Tornar sua página assíncrona
8. Suspensão do pool de aplicativos
9. Remover métodos de Global.asax
10. Não use SqlDataSource
11. Usar HTTP Keep-Alive
12. Remove ETag

Tentei discutir as dicas que normalmente são ignoradas, mas elas têm um enorme potencial de melhoria de desempenho e também podem ser aplicadas rapidamente. Alguns truques comuns como agrupamento e minificação, compactação do IIS, ViewState, cache do cliente são muito importantes, mas bem conhecidos que não foram incluídos na série.