Contenção, desempenho fraco e bloqueios quando você fazer chamadas para serviços da Web de um aplicativo ASP.NET

Quando você faz chamadas a serviços Web de um aplicativo do Microsoft ASP.NET, você pode enfrentar contenção, mau desempenho e deadlocks. Os clientes podem relatar que solicitações parar de responder (ou "travar") ou levam muito tempo para executar. Se houver suspeita de um deadlock, o processo de trabalho pode ser reciclado. Você pode receber as seguintes mensagens no log de eventos do aplicativo.

• Se você estiver usando o Internet Information Services (IIS) 5.0, você receberá as seguintes mensagens no log do aplicativo:

     Event Type:     Error
     Event Source:   ASP.NET 1.0.3705.0
     Event Category: None
     Event ID:       1003
     Date:           5/4/2003
     Time:           6:18:23 PM
     User:           N/A
     Computer:       <ComputerName>
     Description:
        aspnet_wp.exe  (PID: <xxx>) was recycled because it was suspected to be in a deadlocked state.
        It did not send any responses for pending requests in the last 180 seconds.

• Se você estiver usando o IIS 6.0, você receberá as seguintes mensagens no log do aplicativo:

     Event Type:     Warning
     Event Source:   W3SVC-WP
     Event Category: None
     Event ID:       2262
     Date:           5/4/2003
     Time:           1:02:33 PM
     User:           N/A
     Computer:       <ComputerName>
     Description:
        ISAPI 'C:\Windows\Microsoft.net\Framework\v.1.1.4322\aspnet_isapi.dll' reported itself as
        unhealthy for the following reason: 'Deadlock detected'.

• Se você estiver usando o IIS 6.0, você receberá as seguintes mensagens no log do sistema:

     Event Type:     Warning
     Event Source:   W3SVC
     Event Category: None
     Event ID:       1013
     Date:           5/4/2003
     Time:           1:03:47 PM
     User:           N/A
     Computer:       <ComputerName>
     Description:
        A process serving application pool 'DefaultAppPool' exceeded time limits during shut down.
        The process id was '<xxxx>'.

Você também pode receber o seguinte erro de exceção de mensagens quando você faz uma chamada ao método HttpWebRequest.GetResponse :Você também pode receber a seguinte mensagem de erro de exceção no navegador:Observação Este artigo também se aplica a aplicativos que fazem solicitações HttpWebRequest diretamente.

Esse problema pode ocorrer porque o ASP.NET limita o número de threads de trabalho e de threads de porta de conclusão que uma chamada pode usar para executar solicitações.

Normalmente, uma chamada para um serviço da Web usa um thread de trabalho para executar o código que envia a solicitação e um segmento de porta de conclusão para receber o retorno de chamada do serviço da Web. No entanto, se a solicitação é redirecionada ou requer autenticação, a chamada pode usar até dois threads de trabalho e dois threads de porta de conclusão. Portanto, você pode esgotar o ThreadPool gerenciado quando ocorrem várias chamadas de serviço da Web ao mesmo tempo.

Por exemplo, suponha que o ThreadPool é limitado a 10 threads de trabalho e que todos os threads de trabalho 10 atualmente estão executando o código que está aguardando um retorno de chamada executar. O retorno de chamada nunca pode ser executado, pois os itens de trabalho que estão enfileirados para o ThreadPool são bloqueados até que um segmento estiver disponível.

Outra fonte potencial de contenção é o parâmetro maxconnection que usa o namespace System.Net para limitar o número de conexões. Em geral, Esse limite funciona conforme o esperado. No entanto, se muitos aplicativos tentam fazer muitas solicitações para um único endereço IP ao mesmo tempo, segmentos podem ter de esperar uma conexão disponível.

Para resolver esses problemas, você pode ajustar os seguintes parâmetros no arquivo Machine. config para melhor se adequarem a sua situação:

• maxWorkerThreads
• minWorkerThreads
• maxIoThreads
• minFreeThreads
• minLocalRequestFreeThreads
• maxconnection
• executionTimeout

Para resolver com êxito estes problemas, execute as seguintes ações:

• Limitar o número de solicitações do ASP.NET que podem ser executadas em o mesmo tempo para aproximadamente 12 por CPU.
• Permita retornos de chamada de serviço da Web para usar livremente os threads no ThreadPool.
• Selecione um valor apropriado para o parâmetro maxconnections . Basear a seleção do número de endereços IP e AppDomains que são usados.

Observação A recomendação para limitar o número de solicitações do ASP.NET para 12 por CPU é um pouco arbitrária. No entanto, esse limite provou funcionar bem para a maioria dos aplicativos.

maxWorkerThreads e maxIoThreads

ASP.NET usa as seguintes definições de configuração de dois para limitar o número máximo de threads de trabalho e de threads de conclusão são usado: Os parâmetros maxWorkerThreads e maxIoThreads implicitamente são multiplicados pelo número de CPUs. Para exemplo, se você tiver dois processadores, o número máximo de threads de trabalho é o seguinte:

minFreeThreads e minLocalRequestFreeThreads

ASP.NET também contém a seguinte configuração configurações que determinam quantos threads de trabalho e conclusão de threads de porta deve estar disponível para iniciar uma solicitação remota ou uma solicitação de local:Se não houver threads suficientes disponíveis, a solicitação é enfileirada até suficientes segmentos são livres para fazer a solicitação. Portanto, o ASP.NET será não execute mais do que o número de solicitações ao mesmo tempo:Observação Os parâmetros minFreeThreads e minLocalRequestFreeThreads não são multiplicados implicitamente pelo número de CPUs.

minWorkerThreads

No ASP.NET 1.0 Service Pack 3 e ASP.NET 1.1, ASP.NET também contém a seguinte configuração que determina como muitos threads de trabalho podem ser disponibilizadas imediatamente atender a um controle remoto solicitação. Threads que são controladas por esta configuração pode ser criada em uma taxa muito mais rápida do que threads de trabalho são criados a partir do CLR padrão "thread ajuste" recursos. Essa configuração permite que o ASP.NET para solicitações de serviço que podem ser de repente, preenchendo a fila de solicitação ASP.NET devido a uma slow-down em um back-end servidor, um aumento repentino de solicitações do cliente final, ou algo semelhante que poderia causar um aumento repentino no número de solicitações na fila. O o valor padrão para o parâmetro minWorkerThreads é 1. Recomendamos que você defina o valor para o parâmetro minWorkerThreads para o seguinte valor. Por padrão, o parâmetro minWorkerThreads não está presente no arquivo Web. config ou o arquivo Machine. config. Essa configuração é implicitamente multiplicada pelo número de CPUs.

maxconnection

O parâmetro maxconnection determina quantas conexões podem ser feitas para um endereço IP específico. O parâmetro aparece da seguinte maneira:Se o código do aplicativo faz referência ao aplicativo pelo nome do host em vez do endereço IP, o parâmetro deve aparecer da seguinte maneira:Finalmente, se o aplicativo estiver hospedado em uma porta diferente da 80, o parâmetro deve incluir a porta não padrão no URI, semelhante à seguinte:As configurações para os parâmetros que são discutidos neste artigo estão todos no nível do processo. No entanto, a configuração do parâmetro maxconnection se aplica ao nível AppDomain. Por padrão, como essa configuração se aplica ao nível AppDomain, você pode criar um máximo duas conexões para um endereço IP específico de cada AppDomain em seu processo.

executionTimeout

ASP.NET usa a seguinte configuração para limite o tempo de execução de solicitação: Você também pode definir esse limite, usando a propriedade ScriptTimeout .

Observação Se você aumentar o valor do parâmetro executionTimeout , talvez você também precise modificar processModel responseDeadlockInterval configuração de parâmetro.

Recomendações

As configurações recomendadas nesta seção podem não funcionar para todos os aplicativos. No entanto, as seguintes informações adicionais podem ajudar a Faça os ajustes adequados.

Se Você está fazendo uma chamada de serviço da Web para um único endereço IP de cada página ASPX, A Microsoft recomenda que você use as seguintes configurações:

• Defina os valores de parâmetros maxWorkerThreads e maxIoThreads a 100.
• Defina o valor do parâmetro maxconnection para 12 *N (onde N é o número de CPUs que Você tem).
• Definir os valores do parâmetro minFreeThreads para 88 *N e o parâmetro minLocalRequestFreeThreads para76 *N.
• Conjunto o valor de minWorkerThreads para 50. Lembre-se de que minWorkerThreads não está no arquivo de configuração por padrão. Você deve adicioná-lo.

Alguns Estas recomendações envolvem uma fórmula simples que envolve o número de CPUs em um servidor. A variável que representa o número de CPUs a é de fórmulas N. Para essas configurações, se você tiver o hyperthreading ativado, Você deve usar o número de CPUs lógicas em vez do número de CPUs físicas. Por exemplo, se você tiver um servidor de quatro processadores com hyperthreading ativado, em seguida o valor de N as fórmulas serão 8 em vez de 4.

Observação Quando você usa esta configuração, você pode executar um máximo de 12 Solicitações ASP.NET por CPU ao mesmo tempo porque 100-88 = 12. Portanto, pelo menos 88 *N operador segmentos e 88 *N threads de porta de conclusão são disponível para outros usos (como retornos de chamada de serviço da Web).

Por exemplo, você tem um servidor com quatro processadores e hyperthreading ativado. Com base nas seguintes fórmulas, você usaria os seguintes valores para o definições de configuração que são mencionadas neste artigo.
Além disso, quando você usa esta configuração, 12 conexões estão disponíveis por CPU por endereço IP para cada AppDomain. Portanto, no seguinte cenário, muito pouco contenção ocorre quando solicitações estão aguardando conexões e o ThreadPool não é esgotado:

• A web hospeda apenas um aplicativo (AppDomain).
• Cada solicitação para uma página ASPX faz uma solicitação de serviço da Web.
• Todas as solicitações são para o mesmo endereço IP.

No entanto, quando você usa esta configuração, cenários que envolvem um dos procedimentos a seguir provavelmente usará muitas conexões:

• As solicitações são para vários endereços IP.
• As solicitações são redirecionadas (código de status 302).
• Solicitações exigem autenticação.
• As solicitações são feitas de vários AppDomains.

Nessas situações, é uma boa idéia usar um valor menor para o parâmetro maxconnection e valores mais altos para os parâmetros minFreeThreads e minLocalRequestFreeThreads .

Isso comportamento é por design.

Se você estiver tendo um desempenho ruim e contenção no IIS 7.0 com o ASP.NET, consulte os seguintes blogs da Microsoft:

Para obter mais informações, consulte o seguinte site da Microsoft Developer Network (MSDN):