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

Traduções deste artigo Traduções deste artigo
ID do artigo: 821268 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sintomas

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 :
"System. InvalidOperationException: Não havia segmentos livres suficientes no objeto ThreadPool para concluir o operação."
Você também pode receber a seguinte mensagem de erro de exceção no navegador:
"HttpException (0x80004005): solicitação atingiu o tempo out."
Observação Este artigo também se aplica a aplicativos que fazem solicitações HttpWebRequest diretamente.

Causa

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.

Resolução

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:
<processModel maxWorkerThreads="20" maxIoThreads="20">
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:
2 * maxWorkerThreads

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:
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
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:
(maxWorkerThreads*número de CPUs)-minFreeThreads
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.
<processModel minWorkerThreads="1">
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.
minWorkerThreads = maxWorkerThreads / 2
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:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://65.53.32.230" maxconnection="12">
</connectionManagement>
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:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname" maxconnection="12">
</connectionManagement>
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:
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="http://hostname:8080" maxconnection="12">
</connectionManagement>
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:
<httpRuntime executionTimeout="90"/>
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.
<system.web>
	<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/>
	<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/>
</system.web>

<system.net>
	<connectionManagement>
		<add address="[ProvideIPHere]" maxconnection="96"/>
	</connectionManagement>
</system.net>

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 .

Situação

Isso comportamento é por design.

Mais Informações

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

Congelamento do ASP.net no IIS 7.0

Referências

Para obter mais informações, consulte o seguinte site da Microsoft Developer Network (MSDN):
Melhorar o desempenho do ASP.NET

Propriedades

ID do artigo: 821268 - Última revisão: quarta-feira, 6 de fevereiro de 2013 - Revisão: 1.0
A informação contida neste artigo aplica-se a:
  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
Palavras-chave: 
kbprb kbmt KB821268 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 821268

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com