O que está limitando o número de conexões simultâneas que meu aplicativo ASP.NET pode fazer em um serviço da web?

Eu tenho um aplicativo ASP.NET 4.0 em execução no IIS 7.5 em uma máquina Windows Server 2008 R2 Enterprise de 64 bits com lotes de RAM, CPU, disco, etc.

Com cada solicitação da Web, o aplicativo ASP.NET faz uma conexão com um serviço da web de back-end (por meio de sockets brutos), que está sendo executado na mesma máquina.

Problema: parece haver algo que limita o número de conexões simultâneas ao serviço da web de back-end. Suspeito, o número de conexões simultâneas está chegando a 16.

Eu encontrei este artigo chave da Microsoft explicando como ajustar as configurações do IIS para acomodar aplicativos ASP.NET que fazem muitas solicitações de serviços da Web: http://support.microsoft.com/?id=821268#tocHeadRef

Eu segui os recomendatinos do artigo, mas ainda sem sorte. A configuração que é particularmente interessante é a configuração maxconnection , que eu mesmo dei um maxconnection para 999.

Alguma idéia do que mais poderia estar estrangulando conexões?

Nota: Quando eu cortar o IIS do mix e fazer com que os clientes se conectem diretamente ao serviço Web de backend, ele abrirá quantas conexões forem necessárias, portanto, tenho certeza de que o backend não é o gargalo. Deve ser algo no IIS / ASP.NET-land.

Aqui está a seção relevante do machine.config que tenho certeza que está sendo lido pelo aplicativo (verificado com appcmd.exe ):

                           

A maioria das respostas fornecidas aqui aborda o número de solicitações recebidas para o serviço da Web de back-end, não o número de solicitações de saída que você pode fazer do seu aplicativo ASP.net para o serviço de back-end.

Não é o seu webservice de back-end que está limitando sua taxa de solicitações aqui, é o número de conexões abertas que seu aplicativo de chamada está disposto a estabelecer para o mesmo terminal (a mesma URL).

Você pode remover essa limitação adicionando a seguinte seção de configuração ao seu arquivo machine.config:

        

É claro que você pode escolher um número mais razoável se quiser 50 ou 100 conexões simultâneas. Mas o acima irá abri-lo até ao máximo. Você também pode especificar um endereço específico para a regra de limite aberto acima, em vez do ‘*’, que indica todos os endereços.

Documentação MSDN para System.Net.connectionManagement

Outro ótimo recurso para entender o ConnectManagement no .NET

Espero que isso resolva seu problema!

EDIT: Opa, vejo que você tem o gerenciamento de conexão mencionado no seu código acima. Deixarei minhas informações acima, pois elas são relevantes para futuros questionários com o mesmo problema. No entanto, por favor, note que existem atualmente 4 arquivos machine.config diferentes na maioria dos servidores atualizados!

Existe o .NET Framework v2 em execução tanto em 32 bits quanto em 64 bits, bem como no .NET Framework v4 também em 32 bits e 64 bits. Dependendo das configurações escolhidas para o pool de aplicativos, você pode estar usando qualquer um desses 4 arquivos machine.config diferentes! Por favor, verifique todos os 4 arquivos machine.config normalmente localizados aqui:

  • C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG
  • C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ CONFIG
  • C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Config
  • C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Config

Pode ser possível que você esteja usando uma referência de serviço da Web baseada em WCF? Por padrão, o ServiceThrottlingBehavior.MaxConcurrentCalls é 16.

Você pode tentar atualizar o elemento seu comportamento de referência de

  

(Observe que eu recomendaria as configurações acima.) Consulte o MSDN para obter mais informações sobre como configurar um elemento apropriado.

Eu percebo que a pergunta pode ser bastante antiga, mas você diz que o backend está rodando no mesmo servidor. Isso significa em uma porta diferente, provavelmente diferente da porta padrão 80.

Eu li que quando você usa o elemento de configuração “connectionManagement”, você precisa especificar o número da porta se ele difere do padrão 80.

LINK: configuração maxConnection pode não funcionar mesmo autoConfig = false no ASP.NET

Em segundo lugar, se você optar por usar a configuração padrão (address = “*”) estendida com seu próprio valor específico de back-end, considere colocar o valor específico primeiro! Caso contrário, se uma solicitação for feita, o * corresponde primeiro e o padrão de 2 conexões é obtido. Assim como quando você usa a seção no web.config.

LINK: Elemento para connectionManagement (configurações de rede)

Espero que ajude alguém.

Você tentou definir o valor da propriedade DefaultConnectionLimit estática programaticamente?

Aqui está uma boa fonte de informações sobre essa verdadeira dor de cabeça … ASP.NET Thread Usage no IIS 7.5, IIS 7.0 e IIS 6.0 , com atualizações para a estrutura 4.0.

Consulte a seção “Threading” desta página: http://msdn.microsoft.com/en-us/library/ff647786.aspx , em conjunto com a seção “Conexões”.

Você tentou aumentar o atributo maxconnection da sua configuração processModel?

Se não estiver definido no serviço da Web ou no aplicativo ou servidor (apache ou IIS) que hospeda o consumível do serviço da Web, você poderá criar conexões infinitas até que a falha

Ao fazer testes de desempenho, a medida que eu uso é RPS, ou seja, quantas solicitações por segundo o servidor pode atender com latência aceitável.

teoricamente, um servidor só pode executar tantas solicitações simultaneamente quanto o número de núcleos nele.

Não parece que o problema é o modelo de threads do ASP.net, já que ele pode servir milhares de rps. Parece que o problema pode ser seu aplicativo. Você está usando alguma primitiva de synchronization?

Além disso, o que é a latência em seus serviços da web, eles são muito rápidos para responder (em microssegundos), se não, então você pode querer considerar chamadas assíncronas, assim você não acabar bloqueando

Se isso não resultar em algo, então você pode querer fazer o perfil do seu código usando o Visual Studio ou o Red Hat Profiler.