Compartilhar via

ASP.NET monitoramento de desempenho e quando alertar os administradores

  • Artigo

 

Thomas Marquardt
Microsoft Corporation

Atualizado em julho de 2003

Aplica-se a:
   Microsoft® ASP.NET

Resumo: Discute quais contadores de desempenho são mais úteis para diagnosticar problemas de estresse e desempenho em aplicativos do Microsoft ASP.NET, quais limites devem ser definidos para alertar os administradores sobre problemas e outros recursos que podem ser usados para monitorar a integridade de um aplicativo ASP.NET. (17 páginas impressas)

Baixe o código-fonte deste artigo.

Contents

Monitorando contadores de desempenho
Monitorando o log de eventos
Monitorando os logs W3C e HTTPERR
Outros recursos usados para monitorar ASP.NET
Noções básicas sobre os contadores de desempenho
   Contador de exceções do CLR do .NET
   Contadores de carregamento clr do .NET
   Contadores de memória CLR do .NET
   Contadores de ASP.NET
   Contadores de aplicativos ASP.NET
   Contadores de processo
   Contador do processador
   Contador de memória
   Contador do Sistema
   Contadores de serviço Web
Conclusão

Monitorando contadores de desempenho

Há muitos contadores de desempenho disponíveis para aplicativos de monitoramento. Escolher quais deles incluir nos logs de desempenho pode ser complicado e aprender a interpretá-los é uma arte. Este artigo deve ajudá-lo a se sentir mais confortável com essas duas tarefas.

No mínimo, os seguintes contadores de desempenho devem ser monitorados para aplicativos do Microsoft® ASP.NET:

  • Processor(_Total)\% Processor Time
  • Process(aspnet_wp)\% Processor Time
  • Process(aspnet_wp)\Private Bytes
  • Process(aspnet_wp)\Virtual Bytes
  • Process(aspnet_wp)\Handle Count
  • Exceções clr do Microsoft® .NET\# exceções lançadas/s
  • ASP.NET\Reinicializações de Aplicativo
  • ASP.NET\Solicitações Rejeitadas
  • ASP.NET\Reinicializações do Processo de Trabalho (não aplicável ao IIS 6.0)
  • Memory\Available Mbytes
  • Serviço Web\Conexões Atuais
  • Serviço Web\Solicitações de Extensão ISAPI/s

Abaixo está uma lista maior de contadores de desempenho que são úteis para monitorar o desempenho. É sempre bom ter mais dados de desempenho do que não o suficiente, especialmente quando você enfrenta um problema que não é reproduzido facilmente. A lista omite vários contadores de desempenho que geralmente não são necessários. Por exemplo, o estado da sessão e os contadores de desempenho de transações só são necessários quando os recursos são usados.

Alguns limites são recomendados com base na minha experiência com depuração e teste ASP.NET aplicativos. Você pode pesquisar neste artigo "Limite" para ir direto para eles. Os administradores devem determinar se devem gerar alertas quando esses limites forem excedidos com base em sua experiência. Na maioria dos casos, os alertas são apropriados, especialmente se o limite for excedido por longos períodos de tempo.

Monitorando o log de eventos

É essencial monitorar o log de eventos em busca de mensagens de ASP.NET e® do IIS (Microsoft Internet Information Server). ASP.NET grava mensagens no log do aplicativo, por exemplo, cada vez que o processo de trabalho aspnet_wp é encerrado. O IIS 6.0 grava mensagens nos logs do aplicativo e/ou do sistema, por exemplo, sempre que o processo de trabalho do w3wp se relata não íntegro ou falha. É muito fácil escrever um aplicativo .NET que lê o log do aplicativo e filtra mensagens de ASP.NET e IIS e dispara um alerta (envia email ou disca um pager) se necessário.

Monitorando os logs W3C e HTTPERR

Primeiro, habilite o registro em log do W3C para o IIS 5.0 e o IIS 6.0 por meio do Gerenciador dos Serviços de Informações da Internet (IIS). Esse log pode ser configurado para incluir vários dados sobre as solicitações, como o URI, status código e assim por diante. Examine o log em busca de códigos de erro, como 404 Não Encontrado, e execute uma ação para corrigir links, se necessário. No IIS 6.0, o código de substatus é incluído no log e é útil para depuração. O IIS usa códigos de substatus para recuar problemas específicos. Por exemplo, 404.2 indica que a extensão ISAPI que está tratando a solicitação está bloqueada. Uma lista de códigos status e substatus pode ser encontrada no tópico Sobre mensagens de erro personalizadas.

Novidades no IIS 6.0, solicitações malformadas ou incorretas e solicitações que não são atendidas por um Pool de Aplicativos são registradas no log HTTPERR por HTTP.SYS, o driver de modo kernel para lidar com solicitações HTTP. Cada entrada inclui a URL e uma breve descrição do erro.

Verifique o log HTTPERR para solicitações rejeitadas. As solicitações são rejeitadas por HTTP.SYS quando a fila de solicitação de kernel é excedida e quando o aplicativo é colocado offline pelo recurso de Proteção contra Falhas Rápidas. Quando o primeiro problema ocorre, a URL é registrada com a mensagem QueueFull e, quando a segunda ocorre, a mensagem é AppOffline. Por padrão, a fila de solicitação de kernel é definida como 1.000 e pode ser configurada na página Propriedades do Pool de Aplicativos no Gerenciador do IIS. É recomendável aumentar isso para 5.000 para um site ocupado, pois a fila de solicitação de kernel pode facilmente ultrapassar 1.000 se um Pool de Aplicativos falhar enquanto um site estiver sob uma carga muito alta.

Verifique se há solicitações perdidas no log HTTPERR devido a uma falha ou travamento do processo de trabalho. Quando isso ocorrer, a URL será registrada com a mensagem, Connection_Abandoned_By_AppPool, para cada solicitação em andamento. Uma solicitação em voo é aquela que foi enviada a um processo de trabalho para processamento, mas não foi concluída antes da falha ou travamento.

Os detalhes sobre o log HTTPERR podem ser encontrados no Artigo da Base de Dados de Conhecimento microsoft 820729: INFO: Log de erros na API HTTP.

Outros recursos usados para monitorar ASP.NET

Os contadores de desempenho e os logs de eventos não capturam todos os erros que ocorrem e, portanto, não são totalmente suficientes para monitorar ASP.NET. É recomendável escrever um aplicativo simples que envia uma solicitação HTTP para uma ou mais páginas e espera uma determinada resposta. Essa ferramenta deve monitorar o tempo para o último byte (TTLB) para garantir que as páginas sejam atendidas em tempo hábil. Ele também deve registrar todos os erros que ocorrerem, pois essas informações serão necessárias para analisar o problema.

O Kit de Recursos do IIS 6.0 inclui o Analisador de Log 2.1, uma ferramenta para analisar arquivos de log (Log W3C, Log HTTPERR, Logs de Eventos) e armazenar os resultados em um arquivo ou banco de dados. O kit de recursos pode ser instalado no Microsoft® Windows® XP e no Microsoft® Windows Server™ 2003.

Você também pode escrever um aplicativo que coleta dados de desempenho, filtra o log de eventos e registra dados de chave em um banco de dados do Microsoft® SQL Server. É incrivelmente fácil fazer isso usando o namespace System.Diagnostics . Você pode até mesmo monitorar as reinicializações do processo de trabalho usando a classe System.Diagnostics.Process .

Para ajudá-lo a começar, use o link na parte superior deste artigo para baixar o código de exemplo para várias ferramentas úteis:

  1. Código-fonte para snap.exe, uma ferramenta de linha de comando para registrar dados de desempenho em log para processos. O arquivo Snap.cs contém uma breve descrição e explica como compilar a ferramenta.
  2. Código-fonte para HttpClient.exe, um cliente simples que registra o TTLB (tempo de último byte) para solicitações HTTP. O arquivo HttpClient.cs contém uma breve descrição e explica como compilar a ferramenta.
  3. Código-fonte para qqq.exe, uma ferramenta de linha de comando para testar o estresse de um aplicativo ASP.NET. Quando usada em combinação com um cliente de estresse, como o ACT (Microsoft® Application Center Test), essa ferramenta anexará depuradores ao processo de trabalho e monitorará determinados contadores de desempenho. Ele pode ser ajustado para invadir os depuradores quando o desempenho é degradado. O arquivo qqq.cs contém uma descrição breif e explica como compilar a ferramenta.
  4. A página pminfo.aspx usa a classe System.Web.ProcessModelInfo para exibir informações sobre reinicializações de processo de aspnet_wp. O histórico é mantido até que o serviço w3svc seja interrompido.
  5. Código-fonte para ErrorHandler.dll. Esse é um IHttpModule que você pode adicionar ao pipeline HTTP para registrar exceções sem tratamento no log de eventos. É melhor registrar erros em um banco de dados SQL Server, mas o exemplo usa o log de eventos para simplificar.

Outra etapa simples é implementar Application_Error. Você pode adicionar o seguinte texto a global.asax e iniciar imediatamente o registro em log da maioria dos erros sem tratamento no log do aplicativo:

<%@ import namespace="System.Diagnostics" %>
<%@ import namespace="System.Text" %>

const string sourceName      = ".NET Runtime";
const string serverName      = ".";
const string logName         = "Application";
const string uriFormat       = "\r\n\r\nURI: {0}\r\n\r\n";
const string exceptionFormat = "{0}: \"{1}\"\r\n{2}\r\n\r\n";

void Application_Error(Object sender, EventArgs ea) {
    StringBuilder message = new StringBuilder();
    
    if (Request != null) {
        message.AppendFormat(uriFormat, Request.Path);
    }
  
    if (Server != null) {
        Exception e;
        for (e = Server.GetLastError(); e != null; e = e.InnerException) {
            message.AppendFormat(exceptionFormat, 
                                 e.GetType().Name, 
                                 e.Message,
                                 e.StackTrace);
        }
    }

    if (!EventLog.SourceExists(sourceName)) {
        EventLog.CreateEventSource(sourceName, logName);
    }

    EventLog Log = new EventLog(logName, serverName, sourceName);
    Log.WriteEntry(message.ToString(), EventLogEntryType.Error);

    //Server.ClearError(); // uncomment this to cancel the error
}

Application_Error capturará erros de analisador, compilação e tempo de execução nas páginas. Ele não detectará problemas de configuração nem detectará erros que ocorrem no inetinfo enquanto aspnet_isapi processa a solicitação. Além disso, ao usar a representação, o token representado deve ter permissão para gravar nessa origem do evento. Você pode evitar o problema com a representação registrando erros em um banco de dados SQL Server.

Por último, mas não menos importante, as Ferramentas de Depuração da Microsoft® para Windows são muito úteis para depuração de problemas em um servidor Web de produção. Essas ferramentas podem ser baixadas do https://www.microsoft.com/whdc/ddk/debugging/installx86.mspx. Há uma extensão de depurador chamada sos.dll que você pode carregar no depurador windbg.exe ou cdb.exe para depurar o código gerenciado. Ele pode despejar o conteúdo do heap de coleta de lixo (GC), mostrar rastreamentos de pilha gerenciados, auxiliar na investigação de contenção de bloqueios gerenciados, exibir estatísticas do pool de threads e muito, muito mais. Isso pode ser baixado como parte do Conjunto de Ferramentas de Depuração mencionado na Depuração de Produção para aplicativos .NET Framework.

Noções básicas sobre os contadores de desempenho

Veja a seguir uma breve descrição dos contadores de desempenho importantes e como usá-los.

Contador de exceções do CLR do .NET

A instância do contador _Global_ não deve ser usada com esse contador, pois é atualizada por todos os processos gerenciados. Em vez disso, use a instância aspnet_wp.

  • #Exceps lançadas/s. O número total de exceções gerenciadas geradas por segundo. À medida que esse número aumenta, o desempenho diminui. Exceções não devem ser geradas como parte do processamento normal. Observe, no entanto, que Response.Redirect, Server.Transfer e Response.End fazem com que um ThreadAbortException seja lançado várias vezes e um site que depende muito desses métodos incorrerá em uma penalidade de desempenho. Se você precisar usar Response.Redirect, chame Response.Redirect(url, false), que não chama Response.End e, portanto, não gerará. A desvantagem é que o código do usuário que segue a chamada para Response.Redirect(url, false) será executado. Também é possível usar uma página HTML estática para redirecionar. O artigo da Base de Dados de Conhecimento Microsoft 312629 fornece mais detalhes.

    Além de monitorar esse contador de desempenho muito útil, o evento Application_Error deve ser usado para alertar os administradores sobre problemas.

    Limite: 5% do RPS. Valores maiores que esse devem ser investigados e um novo limite deve ser definido conforme necessário.

Contadores de carregamento clr do .NET

A instância do contador _Global_ não deve ser usada com esses contadores de desempenho, pois é atualizada por todos os processos gerenciados. Em vez disso, use a instância aspnet_wp.

  • AppDomains atuais. O número atual de AppDomains carregados no processo. O valor desse contador deve ser o mesmo que o número de aplicativos Web mais 1. O AppDomain adicional é o domínio padrão.

  • Assemblies atuais. O número atual de assemblies carregados no processo. Por padrão, os arquivos ASPX e ASCX em um diretório são compilados em "lote". Normalmente, isso produz de um a três assemblies, dependendo das dependências. Por exemplo, se houver páginas ASPX com dependências de tempo de análise em arquivos ASCX, dois assemblies normalmente serão gerados. Um conterá os arquivos ASPX, os outros arquivos ASCX. As dependências de tempo de análise incluem aquelas criadas pelas <diretivas %@ import %>, <%@ reference %>e <%@ register %> . Um controle carregado por meio do método LoadControl não cria uma dependência de tempo de análise. Observe que global.asax é compilado para um assembly por si só.

    Ocasionalmente, o consumo excessivo de memória é causado por um número extraordinariamente grande de assemblies carregados. Por exemplo, um site que exibe artigos de notícias terá um desempenho melhor usando um pequeno conjunto de arquivos ASPX que obtêm as notícias de um banco de dados do que um único arquivo ASPX usado para cada artigo. Os designers de site devem tentar gerar conteúdo dinamicamente, usar o cache e reduzir o número de páginas ASPX e ASCX.

    Assemblies não podem ser descarregados de um AppDomain. Para evitar o consumo excessivo de memória, o AppDomain é descarregado quando o número de recompilações (ASPX, ASCX, ASAX) excede o limite especificado por <numRecompilesBeforeAppRestart=/>. Observe que, se o <atributo %@ page debug=%> estiver definido como true ou se <a compilação debug=/ estiver definida como> true, a compilação em lote será desabilitada.

  • Bytes no Heap do Carregador. O número de bytes confirmados pelo carregador de classe em todos os AppDomains. Esse contador deve atingir um estado estável. Se esse contador estiver aumentando continuamente, monitore o contador "Assemblies Atuais". Pode haver muitos assemblies carregados por AppDomain.

Contadores de memória CLR do .NET

A instância do contador _Global_ não deve ser usada com esses contadores de desempenho, pois é atualizada por todos os processos gerenciados. Em vez disso, use a instância aspnet_wp.

  • # Bytes em todos os Heaps. O número de bytes confirmados por objetos gerenciados. Essa é a soma do heap de objetos grandes e dos heaps de geração 0, 1 e 2. Essas regiões de memória são do tipo MEM_COMMIT (consulte a documentação do SDK da Plataforma para VirtualAlloc). O valor desse contador sempre será menor que o valor de Process\Private Bytes, que conta todas as regiões MEM_COMMIT para o processo. Bytes privados menos # Bytes em todos os Heaps é o número de bytes confirmados por objetos não gerenciados. A primeira etapa na investigação do uso excessivo de memória é determinar se ele está sendo usado por objetos gerenciados ou não gerenciados.

    Para investigar o uso excessivo de memória gerenciada, recomendo WINDBG.EXE e SOS.DLL, sobre os quais você pode ler em Depuração de Produção para aplicativos .NET Framework. SOS.DLL tem um comando "!dumpheap –stat" que lista a contagem, o tamanho e o tipo de objetos no heap gerenciado. Você pode usar "!dumpheap –mt" para obter o endereço de um objeto e "!gcroot" para ver suas raízes. O comando "!eeheap" apresenta estatísticas de uso de memória para os heaps gerenciados.

    Outra ferramenta útil para diagnosticar o uso de memória é o CLR Profiler, discutido mais detalhadamente abaixo.

    O uso excessivo de memória gerenciada normalmente é causado por:

    1. Ler grandes conjuntos de dados na memória.
    2. Criar entradas de cache excessivas.
    3. Carregar ou baixar arquivos grandes.
    4. Uso excessivo de expressões regulares ou cadeias de caracteres ao analisar arquivos.
    5. ViewState excessivo.
    6. Dados demais no estado da sessão ou em sessões demais.

  • # Coleções de Geração 0. O número de vezes que objetos de geração 0 foram coletados como lixo. Os objetos que sobrevivem são promovidos à geração 1. Uma coleção é executada quando a sala é necessária para alocar um objeto ou quando alguém força uma coleção chamando System.GC.Collect. Coleções que envolvem gerações mais altas levam mais tempo, pois são precedidas por coleções de gerações mais baixas. Tente minimizar o percentual de coleções de geração 2. Como regra geral, o número de coleções de geração 0 deve ser 10 vezes maior que o número de coleções de geração 1 e, da mesma forma, para a geração 1 e 2. Os contadores # Gen N Collections e o contador % time no GC são os melhores para identificar problemas de desempenho causados por alocações excessivas. Confira a descrição de % de tempo no GC para obter as etapas que você pode executar para melhorar o desempenho.

  • # Coleções gen 1. O número de vezes que objetos de geração 1 foram coletados como lixo. Os objetos que sobrevivem são promovidos para a geração 2.

    Limite: um décimo do valor de # Gen 0 Coleções. Os aplicativos que têm um bom desempenho seguem a regra geral mencionada na descrição do contador Coleções # Gen 0.

  • # Coleções gen 2. O número de vezes que os objetos de geração 2 foram coletados como lixo. A geração 2 é a mais alta, portanto, os objetos que sobrevivem à coleção permanecem na geração 2. As coleções gen 2 podem ser muito caras, especialmente se o tamanho do heap gen 2 for excessivo.

    Limite: um décimo do valor de # Gen 1 Coleções. Os aplicativos que têm um bom desempenho seguem a regra geral mencionada na descrição do contador Coleções # Gen 0.

  • % de Tempo Gasto em GC. O percentual de tempo gasto na execução da última coleta de lixo. Um valor médio de 5% ou menos seria considerado íntegro, mas picos maiores do que isso não são incomuns. Observe que todos os threads são suspensos durante uma coleta de lixo.

    A causa mais comum de um tempo de % alto no GC é fazer muitas alocações por solicitação. A segunda causa mais comum é inserir uma grande quantidade de dados no cache ASP.NET, removê-los, regenere-los e reinseri-los no cache a cada poucos minutos. Muitas vezes, há pequenas alterações que podem ser feitas para reduzir consideravelmente as alocações. Por exemplo, a concatenação de cadeia de caracteres pode ser cara por solicitação, pois as cadeias de caracteres concatenadas precisam ser coletadas como lixo. StringBuilder, com uma capacidade inicial apropriada, tem um desempenho melhor do que a concatenação de cadeia de caracteres. No entanto, StringBuilder também precisa ser coletado como lixo e, se usado incorretamente, pode resultar em mais alocações do que o esperado à medida que os buffers internos são redimensionados. Chamar Response.Write várias vezes em cada cadeia de caracteres tem um desempenho ainda melhor do que combiná-los com StringBuilder, portanto, se você puder evitar StringBuilder altogther, faça isso.

    Os aplicativos geralmente armazenam dados temporariamente em um StringBuilder ou MemoryStream ao gerar uma resposta. Em vez de recriar esse armazenamento temporário em cada solicitação, considere implemetria de um pool de buffers reutilizável de matrizes de caracteres ou bytes. Um pool de buffers é um objeto com uma rotina GetBuffer e ReturnBuffer . A rotina GetBuffer tenta retornar um buffer de um repositório interno de buffers, mas cria um novo buffer se o repositório estiver vazio. A rotina ReturnBuffer retornará o buffer para o repositório se o número máximo de buffers armazenados ainda não tiver sido atingido, mas, caso contrário, o liberará. A desvantagem dessa implementação do pool de buffers é que ele requer bloqueio para a segurança de threads. Como alternativa, você pode evitar o impacto no desempenho do bloqueio usando HttpContext.ApplicationInstance para acessar um campo de instância definido em global.asax. Há uma instância de global.asax para cada instância de pipeline e, portanto, o campo é acessível de apenas uma solicitação por vez, tornando-o um ótimo lugar para armazenar um caractere reutilizável ou buffer de bytes.

    Para reduzir o % de tempo no GC, você precisa conhecer seu padrão de alocação. Use o CLR Profiler para analisar uma única solicitação ou um estresse leve por no máximo alguns minutos. (Essas ferramentas são invasivas e não devem ser usadas no producton.) A exibição Gráfico de Alocação exibe a memória total alocada para cada tipo de objeto e a pilha de chamadas que executou a alocação. Use isso para reduzir alocações excessivas. A exibição Histograma por Tamanho (selecione Tipos Alocados de Histograma no menu Exibir) resume o tamanho dos objetos alocados. Evite alocar objetos de curta duração maiores que 85.000 bytes. Esses objetos são alocados no heap de objetos grandes e são mais caros de coletar. Na exibição Histograma por Tamanho, você pode selecionar objetos com o mouse e clicar com o botão direito do mouse para ver quem os alocou. Reduzir alocações é um processo iterativo de modificações de código e criação de perfil.

    Limite: uma média de 5% ou menos; picos de curta duração maiores do que isso são comuns. Valores médios maiores que esse devem ser investigados. Um novo limite deve ser definido conforme necessário.

Contadores de ASP.NET

Os contadores de desempenho nessa categoria são redefinidos apenas para 0 quando o serviço w3svc é iniciado.

  • Reinicializações do aplicativo. O número de reinicializações do aplicativo. Recriar o domínio do aplicativo e recompilar páginas leva tempo, portanto, as reinicializações imprevistas do aplicativo devem ser investigadas. O domínio do aplicativo é descarregado quando ocorre um dos seguintes procedimentos:

    • Modificação de machine.config, web.configou global.asax.
    • Modificação do diretório bin do aplicativo ou seu conteúdo.
    • Quando o número de compilações (ASPX, ASCX ou ASAX) excede o limite especificado por <numRecompilesBeforeAppRestart=/>.
    • Modificação do caminho físico de um diretório virtual.
    • Modificação da política de segurança de acesso ao código.
    • O serviço Web é reiniciado.

    Para web farms em produção, é recomendável que um servidor seja removido da rotação antes de atualizar o conteúdo para melhor desempenho e confiabilidade. Para um único servidor Web em produção, o conteúdo pode ser atualizado enquanto o servidor está sob carga. O hotfix descrito no artigo da Base de Dados de Conhecimento 810281 é de interesse de qualquer pessoa que tenha erros após a reinicialização de um aplicativo, como o compartilhamento de violações com um erro semelhante a "Não é possível acessar o file <FileName> porque ele está sendo usado por outro processo".

    Um problema envolvendo reinicializações de software e aplicativos antivírus é corrigido no Artigo da Base de Dados de Conhecimento 820746 : CORREÇÃO: alguns programas antivírus podem fazer com que os aplicativos Web sejam reiniciados inesperadamente para a v1.0 e, no Artigo da Base de Dados de Conhecimento 821438 para v1.1.

    Limite: 0. Em um mundo perfeito, o domínio do aplicativo sobreviverá durante a vida útil do processo. Valores excessivos devem ser investigados e um novo limite deve ser definido conforme necessário.

  • Aplicativos em execução. O número de aplicativos em execução.

  • Solicitações Atuais. O número de solicitações atualmente tratadas pelo ISAPI ASP.NET. Isso inclui aqueles que estão na fila, em execução ou aguardando para serem gravados no cliente. Esse contador de desempenho foi adicionado à v1.0 de ASP.NET no hotfix pré-SP3 descrito no Artigo da Base de Dados de Conhecimento 329959.

    ASP.NET começará a rejeitar solicitações quando esse contador exceder o requestQueueLimit definido na seção de configuração processModel . Observe que requestQueueLimit se aplica a ASP.NET no IIS 5.0 durante a execução em aspnet_wp, mas talvez surpreendentemente, ele também se aplica ao IIS 6.0 ao ser executado no w3wp. Não é bem conhecido que várias definições de configuração processModel ainda se aplicam durante a execução no IIS 6.0. Isso inclui requestQueueLimit, responseDeadlockInterval, maxWorkerThreads, maxIoThreads, minWorkerThreads e minIoThreads. Um bug na v1.1 da Estrutura, corrigido em ASP.NET pacote cumulativo de atualizações de hotfix de junho de 2003 de 1.1 de junho de 2003, permitiu que ASP.NET lidasse com um número infinito de solicitações ao executar no IIS 6.0. A correção faz com que ASP.NET rejeite solicitações quando Requests Current excede o requestQueueLimit.

    Para aplicativos ASP clássicos, Solicitações Enfileiradas fornece um aviso de quando as solicitações serão rejeitadas. Para ASP.NET, solicitações atuais, juntamente com solicitações na fila de aplicativos, fornecem essa funcionalidade. Esse contador também é usado pelo mecanismo de detecção de deadlock ASP.NET. Se Requests Current for maior que 0 e nenhuma resposta tiver sido recebida do processo de trabalho por uma duração maior que o limite especificado por <processModel responseDeadlockInterval=/>, o processo será encerrado e um novo processo será iniciado. No hotfix pre-SP3 descrito no Artigo da Base de Dados de Conhecimento 328267, o algoritmo foi modificado para que Requests Current deve ser maior que a soma de maxWorkerThreads mais maxIoThreads, especificada na < seção de configuração processModel/>. Observe que, por padrão, o tempo limite de execução da solicitação é de 90 segundos e é intencionalmente menor que responseDeadlockInterval. O tempo limite de execução da solicitação pode ser modificado por meio da < definição de configuração httpRuntime executionTimeout=/> ou da propriedade Server.ScriptTimeout, mas sempre deve ser feito menos do que responseDeadlockInterval.

  • Tempo de Execução da Solicitação. O número de milissegundos necessários para executar a última solicitação. Na versão 1.0 do Framework, o tempo de execução começa quando o processo de trabalho recebe a solicitação e é interrompido quando o ISAPI ASP.NET envia HSE_REQ_DONE_WITH_SESSION para o IIS. Para o IIS versão 5, isso inclui o tempo necessário para gravar a resposta no cliente, mas para o IIS versão 6, os buffers de resposta são enviados de forma assíncrona e, portanto, o tempo necessário para gravar a resposta no cliente não está incluído. Assim, no IIS versão 5, um cliente com uma conexão de rede lenta aumentará consideravelmente o valor desse contador.

    Na versão 1.1 do Framework, o tempo de execução começa quando o HttpContext para a solicitação é criado e é interrompido antes que a resposta seja enviada ao IIS. Supondo que o código do usuário não chame HttpResponse.Flush, isso implica que o tempo de execução é interrompido antes de enviar bytes para o IIS ou para o cliente nesse caso.

    ASP.NET\Tempo de Execução da Solicitação é um contador de instância e muito volátil. Por outro lado, o TTLB (tempo para o último byte) pode ser facilmente médio e usado para calcular uma melhor estimativa de desempenho em um período de tempo. O TTLB pode ser calculado por meio de um cliente HTTP simples escrito em código gerenciado ou você pode usar um dos muitos clientes HTTP disponíveis que calculam o TTLB, como o TESTE do Application Center (ACT).

    Observe que, se < a compilação debug=/> for definida como TRUE, a compilação em lotes será desabilitada e a < definição de configuração httpRuntime executionTimeout=/> e as chamadas para Server.ScriptTimeout serão ignoradas. Isso poderá causar problemas se a < configuração processModel responseDeadlockInterval=/ não estiver definida como > Infinita, pois as solicitações para páginas de depuração podem teoricamente ser executadas para sempre.

    Limite: N.A. O valor desse contador deve ser estável. A experiência ajudará a definir um limite para um site específico. Quando o modelo de processo está habilitado, o tempo de execução da solicitação inclui o tempo necessário para gravar a resposta no cliente e, portanto, depende da largura de banda da conexão do cliente.

  • Solicitações enfileiradas. O número de solicitações atualmente enfileiradas. Ao executar no IIS 5.0, há uma fila entre inetinfo e aspnet_wp e há uma fila para cada diretório virtual. Ao executar no IIS 6.0, há uma fila em que as solicitações são postadas no ThreadPool gerenciado do código nativo e uma fila para cada diretório virtual. Esse contador inclui solicitações em todas as filas. A fila entre inetinfo e aspnet_wp é um pipe nomeado pelo qual a solicitação é enviada de um processo para o outro. O número de solicitações nessa fila aumentará se houver uma escassez de threads de E/S disponíveis no processo de aspnet_wp. No IIS 6.0, ele aumenta quando há solicitações de entrada e uma escassez de threads de trabalho.

    Observe que as solicitações são rejeitadas quando o contador Solicitações Atuais excede o <processModel requestQueueLimit=/>. Muitas pessoas acham que isso ocorre quando o contador Solicitações Enfileiradas excede requestQueueLimit, mas esse não é o caso. Quando esse limite for excedido, as solicitações serão rejeitadas com um código 503 status e a mensagem "O servidor está muito ocupado". Se uma solicitação for rejeitada por esse motivo, ela nunca alcançará o código gerenciado e os manipuladores de erros não serão notificados. Normalmente, isso é apenas um problema quando o servidor está sob uma carga muito pesada, embora uma carga de "intermitência" a cada hora também possa causar isso. Para o cenário de carregamento de intermitência incomum, talvez você esteja interessado no hotfix descrito no Artigo da Base de Dados de Conhecimento 810259, que permitirá aumentar o número mínimo de threads de E/S do padrão de 1 por CPU.

    Cada diretório virtual tem uma fila que usa para manter a disponibilidade de threads de E/S e de trabalho. O número de solicitações nessa fila aumenta se o número de threads de trabalho disponíveis ou threads de E/S disponíveis ficar abaixo do limite especificado por <httpRuntime minFreeThreads=/>. Quando o limite especificado por <httpRuntime appRequestQueueLimit=/> é excedido, a solicitação é rejeitada com um código de status 503 e o cliente recebe uma HttpException com a mensagem "Servidor muito ocupado".

    Por si só, esse contador não é um indicador claro de problemas de desempenho, nem pode ser usado para determinar quando as solicitações serão rejeitadas. No artigo da Base de Dados de Conhecimento 329959, dois novos contadores de desempenho foram introduzidos para resolver esse problema: Solicitações Atuais e Solicitações na Fila de Aplicativos. Confira as descrições desses dois contadores, bem como para Solicitações Rejeitadas.

  • Solicitações rejeitadas. O número de solicitações rejeitadas. As solicitações são rejeitadas quando um dos limites de fila é excedido (consulte a descrição de Solicitações Enfileiradas). As solicitações podem ser rejeitadas por vários motivos. A latência de back-end, como a causada por um SQL Server lento, geralmente é precedida por um aumento repentino no número de instâncias de pipeline e uma diminuição na utilização da CPU e solicitações/s. Um servidor pode ser sobrecarregado durante tempos de carga pesada devido a restrições de processador ou memória que, em última análise, resultam na rejeição de solicitações.

    O design de um aplicativo pode resultar em tempo excessivo de execução da solicitação. Por exemplo, a compilação em lote é um recurso no qual todas as páginas de um diretório são compiladas em um único assembly quando a primeira solicitação de uma página é recebida. Se houver várias centenas de páginas em um diretório, a primeira solicitação nesse diretório poderá levar muito tempo para ser executada. Se <a compilação batchTimeout=/> for excedida, a compilação em lote continuará em um thread em segundo plano e a página solicitada será compilada individualmente. Se a compilação em lote for bem-sucedida, o assembly será preservado em disco e poderá ser reutilizado após a reinicialização de um aplicativo. No entanto, se o global.asax, web.config, machine.config ou um assembly na pasta bin do aplicativo for modificado, o processo de compilação em lote será executado novamente devido à alteração de dependência.

    O design cuidadoso de um site grande pode ter um impacto significativo no desempenho. Nesse caso, é melhor ter apenas algumas páginas que variam de comportamento com base nos dados da cadeia de caracteres de consulta. Em geral, você precisa minimizar o tempo de execução da solicitação, que é melhor monitorado pelo TTLB (tempo médio para o último byte) usando um cliente HTTP que solicita uma ou mais páginas do site.

    Os seguintes contadores de desempenho são mais adequados para descobrir a causa das solicitações rejeitadas:

    • Processo\% tempo do processador
    • Processo\Bytes Particulares
    • Process\Thread Count
    • Serviço Web\Solicitações de Extensão ISAPI/s
    • ASP.NET\Solicitações Atuais
    • ASP.NET\Solicitações Enfileiradas
    • ASP.NET\Tempo de Espera da Solicitação
    • ASP.NET Applications\Pipeline Instance Count
    • ASP.NET Aplicativos\Solicitações na Fila de Aplicativos

    Limite: 0. O valor desse contador deve ser 0. Valores maiores que esse devem ser investigados.

  • Tempo de Espera da Solicitação. O número de milissegundos que a solicitação mais recente gastou aguardando na fila, ou pipe nomeado, que existe entre inetinfo e aspnet_wp (consulte a descrição de Solicitações Enfileiradas). Isso não inclui nenhum tempo gasto aguardando nas filas do aplicativo.

    Limite: 1000. A solicitação média deve gastar 0 milissegundos aguardando na fila.

  • Processos de trabalho em execução. O número atual de processos de trabalho aspnet_wp. Por um curto período de tempo, um novo processo de trabalho e o processo de trabalho que está sendo substituído podem coexistir. Embora raro, às vezes processa deadlock enquanto eles estão saindo. Se você suspeitar disso, considere usar uma ferramenta para monitorar o número de instâncias do processo de trabalho. Como alternativa, o contador de desempenho Memory\Available Mbytes pode ser usado, pois esses processos suspensos consumirão memória.

    Limite: 2. Durante o desligamento do processo de trabalho anterior, pode haver duas instâncias. Se webGarden estiver habilitado, o limite deverá ser #CPUs mais 1. Valores maiores que esse podem indicar reinicializações excessivas de processo em um período muito curto de tempo.

  • Reinicializações do processo de trabalho. O número de reinicializações aspnet_wp processo.

    Limite: 1. As reinicializações de processo são caras e indesejáveis. Os valores dependem das configurações do modelo de processo, bem como de violações de acesso imprevistas, vazamentos de memória e deadlocks. Se aspnet_wp for reiniciada, uma entrada do Log de Eventos do Aplicativo indicará o motivo. As solicitações serão perdidas se ocorrer uma violação de acesso ou deadlock. Se as configurações do modelo de processo forem usadas para reciclar preventivamente o processo, será necessário definir um limite apropriado.

Contadores de aplicativos ASP.NET

Os contadores de desempenho nessa categoria são redefinidos para 0 quando o domínio do aplicativo ou o serviço Web é reiniciado.

  • Entradas totais de cache. O número atual de entradas no cache (usuário e interno). Internamente, ASP.NET usa o cache para armazenar objetos que são caros de criar, incluindo objetos de configuração, entradas de assembly preservadas, caminhos mapeados pelo método MapPath e objetos de estado de sessão em processo.

    Nota A família de contadores de desempenho "Cache Total" é útil para diagnosticar problemas com o estado da sessão em processo. Armazenar muitos objetos no cache geralmente é a causa de vazamentos de memória.

  • Taxa de Ocorrência Total de Cache. A taxa total de acertos para erros de todas as solicitações de cache (usuário e interno).

  • Taxa de Volume de Negócios Total do Cache. O número de adições e remoções ao cache por segundo (usuário e interno). Uma alta taxa de volume de negócios indica que os itens estão sendo adicionados e removidos rapidamente, o que pode ser caro.

  • Entradas de API de cache. O número de entradas atualmente no cache do usuário.

  • Taxa de Ocorrências da API de Cache. A taxa total de acertos para erros de solicitações de Cache de Usuário.

  • Taxa de Rotatividade da API de Cache. O número de adições e remoções ao cache do usuário por segundo. Uma alta taxa de volume de negócios indica que os itens estão sendo adicionados e removidos rapidamente, o que pode ser caro.

  • Entradas de cache de saída. O número de entradas atualmente no Cache de Saída.

  • Taxa de Ocorrências do Cache de Saída. A taxa total de acertos para erros de solicitações de Cache de Saída.

  • Taxa de Volume de Negócios do Cache de Saída. O número de adições e remoções ao cache de saída por segundo. Uma alta taxa de volume de negócios indica que os itens estão sendo adicionados e removidos rapidamente, o que pode ser caro.

  • Contagem de instâncias de pipeline. O número de instâncias de pipeline ativas. Apenas um thread de execução pode ser executado em uma instância de pipeline, portanto, esse número fornece o número máximo de solicitações simultâneas que estão sendo processadas para um determinado aplicativo. O número de instâncias de pipeline deve ser constante. Aumentos repentinos são indicativos de latência de back-end (consulte a descrição de Solicitações Rejeitadas acima).

  • Total de compilações. O número de arquivos ASAX, ASCX, ASHX, ASPX ou ASMX que foram compilados. Esse é o número de arquivos compilados, não o número de assemblies gerados. Os assemblies são preservados no disco e reutilizados até que o tempo de criação, a hora da última gravação ou o comprimento de uma dependência de arquivo sejam alterados. As dependências de uma página ASPX incluem global.asax, web.config, machine.config, assemblies dependentes na pasta bin e arquivos ASCX referenciados pela página. Se você reiniciar o aplicativo sem modificar nenhuma das dependências de arquivo, o assembly preservado será recarregado sem a necessidade de nenhuma compilação. Esse contador de desempenho só será incrementado quando um arquivo for analisado inicialmente e compilado em um assembly.

    Por padrão, a compilação em lote está habilitada, no entanto, esse contador será incrementado uma vez para cada arquivo analisado e compilado em um assembly, independentemente de quantos assemblies forem criados.

    Se a compilação falhar, o contador não será incrementado.

  • Erros durante o pré-processamento. O número total de erros de configuração e análise. Esse contador é incrementado sempre que ocorre um erro de configuração ou de análise. Embora os erros de configuração sejam armazenados em cache, o contador incrementa cada vez que o erro ocorre.

    Nota Não dependa apenas dos contadores de desempenho "Erros" para determinar se o servidor está íntegro. Eles são redefinidos para zero quando o AppDomain é descarregado. No entanto, eles podem ser usados para se aprofundar em um problema específico. Em geral, use o evento Application_Error para alertar os administradores sobre problemas.

  • Erros durante a compilação. O número total de erros de compilação. A resposta é armazenada em cache e esse contador incrementa apenas uma vez até que a recompilação seja forçada por uma alteração de arquivo. Implemente a manipulação de erros personalizada para gerar um evento.

  • Erros durante a execução. O número total de erros em tempo de execução.

  • Erros sem tratamento durante a execução. O número total de exceções sem tratamento em tempo de execução. Isso não inclui o seguinte:

    1. Erros limpos por um manipulador de eventos (por exemplo, por Page_Error ou Application_Error).
    2. Erros tratados por uma página de redirecionamento.
    3. Erros que ocorrem em um bloco try/catch.

  • Erros sem tratamento durante a execução/s. O número total de exceções sem tratamento por segundo em tempo de execução.

  • Total de erros. A soma de erros durante o pré-processamento, erros durante a compilação e erros durante a execução.

  • Total de erros/s. O total de erros durante o pré-processamento, erros durante a compilação e erros durante a execução por segundo.

  • Solicitações em execução. O número de solicitações em execução no momento. Esse contador é incrementado quando o HttpRuntime começa a processar a solicitação e é reduzido após o HttpRuntime concluir a solicitação. Na v1.1 da Estrutura, há um bug nesse contador de desempenho corrigido no pacote cumulativo de atualizações de hotfix de 1.1 de junho de 2003 ASP.NET. Infelizmente, o bug não está descrito no artigo da Base de Dados de Conhecimento. Antes da correção, o contador incluía o tempo necessário para gravar a resposta no cliente.

  • Solicitações na Fila de Aplicativos. O número de solicitações na fila de solicitações do aplicativo (consulte a descrição de Solicitações Enfileiradas acima). Além das Solicitações Atuais, as Solicitações na Fila de Aplicativos fornecem um aviso de quando as solicitações serão rejeitadas. Se houver apenas alguns diretórios virtuais, aumentar o appRequestQueueLimit padrão para 200 ou 300 poderá ser adequado, especialmente para aplicativos lentos sob carga pesada.

  • Solicitações Não Encontradas. O número de solicitações de recursos não encontrados.

  • Solicitações Não Autorizadas. O número de solicitações falhou devido ao acesso não autorizado.

  • Solicitações atingiu o tempo limite. O número de solicitações que atingiu o tempo limite.

  • Solicitações bem-sucedidas. O número de solicitações executadas com êxito.

  • Total de Solicitações. O número de solicitações desde que o aplicativo foi iniciado.

  • Solicitações/s. O número de solicitações executadas por segundo. Prefiro "Solicitações de Extensão do Serviço Web\ISAPI/s" porque ela não é afetada pelas reinicializações do aplicativo.

Contadores de processo

Com esses contadores, os processos de interesse são aspnet_wp e inetinfo.

  • % de Tempo do Processador. A porcentagem de tempo que os threads desse processo gastam usando os processadores.

    Limite: 70%. Valores maiores que esse por longos períodos de tempo indicam a necessidade de comprar hardware ou otimizar seu aplicativo.

  • Contagem de identificadores.

    Limite: 10000. Uma contagem de identificadores de 2000 em aspnet_wp é suspeita e 10.000 está muito além dos limites aceitáveis. A degradação perceptível do desempenho ocorrerá se a contagem total de identificadores para todos os processos exceder aproximadamente 40.000, o que é totalmente alcançável durante um ataque de negação de serviço contra o IIS.

  • Bytes privados. O tamanho atual, em bytes, da memória confirmada pertencente a esse processo. Os vazamentos de memória são identificados por um aumento consistente e prolongado em Bytes Privados. Esse é o melhor contador de desempenho para detectar vazamentos de memória.

    Ao executar no IIS 5.0, um limite de memória para Bytes Privados deve ser definido na <seção de configuração processModel memoryLimit=/> . Ao executar no IIS 6.0, o limite de memória deve ser definido no Gerenciador do IIS. Abra Propriedades para o pool de aplicativos e, na guia Reciclagem , especifique um limite para Memória máxima usada (em megabytes). Esse limite corresponde a Bytes Privados. Bytes privados para o processo de trabalho são comparados com o limite de memória para determinar quando reciclar o processo. System.Web.Caching.Cache também usa Bytes Privados e o limite de memória para determinar quando expurgar itens do cache e, portanto, evitar a reciclagem do processo. É recomendável um limite de memória de 60% da RAM física para evitar a paginação, especialmente quando um novo processo substitui o antigo devido ao consumo excessivo de memória. Observe que o Artigo da Base de Dados de Conhecimento 330469 resolve um problema com ASP.NET em que falha ao monitorar Bytes Privados em servidores com um grande número de processos em execução. Esse hotfix também permite que o gerenciador de memória de cache funcione corretamente quando há um grande número de processos em execução.

    É importante ajustar o limite de memória em computadores com grandes quantidades de RAM física, para que o gerenciador de memória de cache e a reciclagem de processos funcionem corretamente. Por exemplo, suponha que você tenha um servidor com 4 GB (gigabytes) de RAM física que esteja usando o limite de memória padrão. Isso é um problema. Sessenta por cento da RAM física é de 2,4 GB, que é maior que o espaço de endereço virtual padrão de 2 GB. Então, como o limite de memória deve ser definido?

    Há algumas coisas a serem consideradas: primeiro, a probabilidade de experimentar um OutOfMemoryException começa a aumentar drasticamente quando "Process\Virtual Bytes" está dentro de 600 MB do limite de espaço de endereço virtual (geralmente 2 GB) e, em segundo lugar, os testes mostraram que "Process\Virtual Bytes" geralmente é maior que "Process\Private Bytes" em no máximo 600 MB. Essa diferença se deve, em parte, às regiões de MEM_RESERVE mantidas pelo GC, permitindo que ela confirme rapidamente mais memória quando necessário. Juntos, isso implica que quando "Process\Private Bytes" excede 800 MB, a probabilidade de experimentar um OutOfMemoryException aumenta. Neste exemplo, o computador tem 4 GB de RAM física, portanto, você precisa definir o limite de memória como 20% para evitar condições de memória insuficiente. Você pode experimentar esses números para maximizar o uso de memória em um computador, mas se você quiser reproduzi-lo com segurança, os números no exemplo funcionarão.

    Para resumir, defina o limite de memória para o menor de 60% da RAM física ou 800 MB. Como a v1.1 dá suporte a 3 GB de espaço de endereço virtual, se você adicionar /3 GB a boot.ini, poderá usar com segurança 1.800 MB em vez de 800 MB como um limite superior.

    Observe que, ao executar testes, se você quiser forçar um GC e estabilizar a memória gerenciada, poderá chamar System.GC.GetTotalMemory(true) uma vez. Esse método chamará o GC. Coletar e WaitForPendingFinalizers() repetidamente até que a memória se estabilize dentro de 5%.

    Limite: o mínimo de 60% da RAM física e 800 MB. Valores maiores que 60% da RAM física total começam a ter um impacto sobre o desempenho, especialmente durante as reinicializações do aplicativo e do processo. A liklihood de um OutOfMemoryException aumenta muito quando bytes privados excedem 800 MB em um processo com um limite de espaço de endereço virtual de 2 GB.

  • Contagem de threads. O número de threads ativos nesse processo. A contagem de threads geralmente aumenta quando a carga é muito alta.

    Limite: 75 + ((maxWorkerThread + maxIoThreads) * #CPUs). O limite deverá ser aumentado se o modo aspcompat for usado: Limite: 75 + ((maxWorkerThread + maxIoThreads) * #CPUs * 2).

  • Bytes virtuais. O tamanho atual, em bytes, do espaço de endereço virtual para esse processo.

    O limite de espaço de endereço virtual de um processo de modo de usuário é de 2 GB, a menos que o espaço de endereço de 3 GB esteja habilitado usando o comutador /3 GB no boot.ini. O desempenho é degradado à medida que esse limite é abordado e normalmente resulta em um processo ou falha no sistema. O espaço de endereço fica fragmentado à medida que o limite de 2 GB ou 3 GB é abordado e, portanto, recomendo um limite conservador de 1,4 ou 2,4 GB, respectivamente. Se você estiver tendo problemas aqui, verá System.OutOfMemoryException sendo lançado e isso pode ou não falhar no processo.

    Ao executar no IIS 6.0, um limite de memória virtual pode ser definido no Gerenciador do IIS. No entanto, definir isso incorretamente pode causar problemas para ASP.NET. ASP.NET expunge itens do cache para evitar exceder o limite de Bytes Privados, mas o algoritmo usa Bytes Privados e o limite de Bytes Privados nessa determinação. Ele não monitora bytes virtuais nem o limite de bytes virtuais. Considerando que a diferença entre bytes virtuais e bytes privados normalmente não é superior a 600 MB, você pode definir o limite de Bytes Virtuais como um valor 600 MB maior que o limite de Bytes Privados se você estiver preocupado com a possibilidade de vazamentos de memória virtual ou fragmentação. Se isso for desejável, defina um limite para Memória virtual máxima (em megabytes), encontrado na guia Reciclagem para as Propriedades do pool de aplicativos.

    A versão 1.0 do Framework não dá suporte ao espaço de endereço de 3 GB no processo de trabalho ou no serviço de estado. No entanto, consulte Artigo da Base de Dados de Conhecimento 320353 para obter instruções para habilitar o espaço de endereço de 3 GB no inetinfo.exe. A versão 1.1 dá suporte total a espaço de endereço de 3 GB para o processo de trabalho e o serviço de estado.

    Limite: 600 MB a menos que o tamanho do espaço de endereço virtual; 1,4 ou 2,4 GB.

Contador do processador

  • % de Tempo do Processador. A porcentagem de tempo que todos os threads gastam usando os processadores.

    Limite: 70%. Valores maiores que esse por longos períodos de tempo indicam a necessidade de comprar hardware ou otimizar seu aplicativo.

Contador de memória

  • Mbytes disponíveis. A quantidade de RAM física disponível.

    Limite: 20% da RAM física. Valores menores que esse devem ser investigados e podem indicar a necessidade de comprar hardware.

Contador do Sistema

  • Opções de contexto/s. A taxa na qual os processadores alternam contextos de thread. Um número alto pode indicar alta contenção de bloqueio ou transições entre o modo de usuário e kernel. As Opções de Contexto/s devem aumentar linearmente com taxa de transferência, carga e o número de CPUs. Se aumentar exponencialmente, haverá um problema. Um criador de perfil deve ser usado para uma investigação mais aprofundada.

Contadores de Serviço Web

  • Conexões atuais. Um limite para esse contador depende de muitas variáveis, como o tipo de solicitações (ISAPI, CGI, HTML estático e assim por diante), utilização da CPU e assim por diante. Um limite deve ser desenvolvido por meio da experiência.
  • Total de Solicitações de Método/s. Usado principalmente como uma métrica para diagnosticar problemas de desempenho. Pode ser interessante comparar isso com "ASP.NET Applications\Requests/s" e "Web Service\ISAPI Extension Requests/s" para ver o percentual de páginas estáticas atendidas versus páginas renderizadas por aspnet_isapi.dll.
  • Solicitações de extensão ISAPI/s. Usado principalmente como uma métrica para diagnosticar problemas de desempenho. Pode ser interessante comparar isso com "ASP.NET Applications\Requests/s" e "Web Service\Total Method Requests/s". Observe que isso inclui solicitações para todas as extensões ISAPI, não apenas aspnet_isapi.dll.

Conclusão

O estresse cuidadoso e o teste de desempenho de um aplicativo antes de entrar no ar podem evitar uma grande dor de cabeça. Parece haver dois grandes obstáculos que muitas pessoas encontram:

  1. Você precisa usar um cliente HTTP capaz de simular o tráfego e a carga que você espera que o site experimente.
  2. Você precisa testar todo o aplicativo em um ambiente quase idêntico ao ambiente de produção.

Não é fácil simular o tráfego de site real, mas posso dizer honestamente que a maioria dos aplicativos que enfrentam problemas nunca foram testados adequadamente. Este artigo deve ajudá-lo a entender os contadores de desempenho e criar algumas ferramentas úteis para monitorar o desempenho. Para aplicar a carga, recomendo o ACT (Microsoft Application Center Test), que está incluído no Microsoft® Visual Studio® .NET. Você pode ler mais sobre essa ferramenta de estresse no Microsoft Application Center Test 1.0, Visual Studio .NET Edition. Também recomendo a WAST (Microsoft® Web Application Stress Tool). Isso pode ser baixado gratuitamente no TechNet. Se o aplicativo usar ViewState, você precisará usar o ACT, pois o WAST não pode analisar dinamicamente a resposta.

Eu não sei o que é sobre ambientes de produção, mas há definitivamente algo especial sobre eles. Não consigo contar as vezes que ouvi a declaração: "O problema só ocorre em nosso site de produção." Normalmente, a diferença é o próprio aplicativo. Muitas vezes, há alguma parte do aplicativo que não pode ser simulada no laboratório. Por exemplo, o servidor de anúncios foi omitido do teste ou o banco de dados usado para simular o banco de dados real é substancialmente diferente. Às vezes, as diferenças de rede ou DNS são a causa e, às vezes, é uma diferença no hardware no qual os servidores são executados.

Estou depurando e monitorando o desempenho de aplicativos ASP.NET há vários anos, mas ainda há momentos em que preciso de ajuda. Se você se encontrar nessa posição, os fóruns no site do ASP.NET serão um bom lugar para obter respostas. Mas se você estiver realmente em uma associação, não hesite em entrar em contato com o Suporte ao Produto da Microsoft usando as informações de contato fornecidas nesse site. Observe que, se um problema for determinado pela Microsoft como resultado de um defeito em um produto da Microsoft, você não será cobrado por esse incidente.

Esperamos que este documento tenha equipado você com as ferramentas e as informações necessárias para garantir a confiabilidade e o desempenho do aplicativo. Se você tiver alguma pergunta, poste-as no ASP.NET Web e farei o possível para respondê-las. Boa sorte!

Sobre o autor

Thomas Marquardt é desenvolvedor da equipe de ASP.NET da Microsoft. Ele tem depurado e investigado problemas de desempenho com ASP.NET aplicativos desde o inverno de 2000. Thomas gostaria de agradecer a Dmitry Robsman, gerente de desenvolvimento por ASP.NET na Microsoft, por horas e horas de ajuda e orientação ao longo dos anos.

© Microsoft Corporation. Todos os direitos reservados.