Solicitações no IIS “Estado do SendResponse” ficou preso por um longo tempo; Aplicativo Web lento do IIS 7.5 / ASP.NET 4.0

Question

Tenho um conjunto de servidores muito cruéis e muito subutilizados que executam algumas máquinas virtuais com o Windows Server 2008 R2 e o IIS 7.5.

O problema: Às vezes, as solicitações demoram muito tempo para serem processadas. O usuário vê o navegador girando, aparentemente sem receber resposta do IIS.

Algumas estatísticas e amp; tentativas de resolução:

• A carga nos servidores (host e VM) é insignificante. A CPU nunca ultrapassa 5%, há 10+ GB de RAM disponíveis, tudo está conectado via MPIO a uma SAN rápida.
• Recebo entre 30 e 50 solicitações por segundo, uma mistura de conteúdo dinâmico e estático, apenas GET e POST. A maioria das ocorrências é armazenada em cache (taxa de acertos de 80%), portanto, a carga na malha / SAN / IO é quase nula.
• O descarregamento do TCP está desativado no host e na máquina virtual, no adaptador de rede e desativando a chaminé TCP
• Os aplicativos da web estão sendo executados no modo integrado do ASP.NET 4.0. Eles não fazem chamadas de longa duração para serviços da Web de terceiros ou algo semelhante.
• Eu tentei o processModel autoConfig, além de configurar maxWorkerThreads, maxConnections, maxIOThreads etc. para números muito altos, sem diferença.
• As consultas de banco de dados estão todas concluídas em menos de um segundo. Eu perfilei por um dia inteiro e não capturei uma única consulta que levaria mais tempo.
• Eu observei muitos contadores de monitores de desempenho; as filas do ASP.NET e as filas de aplicativos estão sempre vazias, nada aparece para ficar na fila (o que não faria sentido de qualquer maneira, considerando que o servidor não está suando muito)
• Identifiquei usando solicitações de lista appcmd que às vezes solicitam ficar "presas" por 20 a 60 segundos no estágio "SendResponse" do IIS. Essa é a única coisa que consegui encontrar até agora que faria algum sentido por que estamos vendo usuários ficando presos quando navegam por aí. Observe que a maioria das solicitações está sendo processada rapidamente, mas parece que solicitações aleatórias de pools de aplicativos diferentes ficam presas aqui.

Alguma ideia do que mais eu posso ver? O que faria com que as solicitações ficassem presas no estágio 'SendResponse' no IIS?

    

Answer 1

Encontrou alguma solução para isso? Eu estou vendo reguarly a mesma coisa por um bom tempo agora, onde o conteúdo estático, como JS, PNG e GIFs estão presos no estado "SendResponse" no módulo "IIS Web Core". Estou na mesma situação com o IIS 7 / ASP.NET 4.0. Estou monitorando isso com este código de administração do Microsoft.Web. , em vez de appcmd.

UPDATE: Em algumas pesquisas, uma possibilidade que eu tenho é que pode ser uma conexão de rede perdida. Em este tópico , a pessoa relata códigos de status do Win32 de 1236 em seus registros do IIS, que é "A conexão de rede era abortado pelo sistema local ". No entanto, não tenho certeza se isso significa que o solicitante cancelou a solicitação ou o servidor da web cancelou a solicitação. É possível que o solicitante possa navegar para outra página em seu site antes que todas essas solicitações HTTP para o conteúdo da página (imagens, JS, etc.) sejam concluídas, o que provavelmente abortaria todas as solicitações pendentes para o servidor da Web (ou seja, ele clica em um link na página quando renderiza pela primeira vez). Eu encontrei alguns códigos de status 1236 Win32 em meus logs do IIS (principalmente para conteúdo estático, como GIF, PNG e JS com alguns deles vinculados a páginas ASPX), no entanto, não tenho certeza se estas são as mesmas solicitações I estou vendo preso no estado "SendResponse".

    

Answer 2

Isso geralmente ocorre devido a dispositivos móveis em conexões de dados lentas que baixam arquivos de recursos grandes. Quando digo "grande" quero dizer em relação à velocidade da conexão.

As solicitações não são "suspensas", elas estão demorando muito, porque dependem da velocidade da rede do usuário. As solicitações serão canceladas se o usuário desconectar, por isso, elas provavelmente aguardarão pacientemente que a página seja carregada.

Verifique os IPs listados ao lado das solicitações "suspensas" e pesquise-os. Provavelmente, você perceberá que eles pertencem a operadoras de telefonia celular.