O tempo de resposta diminui à medida que o dia passa, por onde começar a solução de problemas?

Question

Meu pessoal de TI apenas dá de ombros quando eu faço isso, então estou procurando ajuda.

Acho que esta imagem mostra melhor.

Simplesmente, à medida que o dia avança, o tempo de resposta fica cada vez pior, até que por volta da meia-noite acontece algo que volta a ser quase normal. Estamos no IIS, esta página ainda está no ASP Clássico, mas isso ocorre em todas as páginas até mesmo nas páginas HTML simples, o que eu acho que exclui um problema de conectividade do SQL.

Acho que a minha pergunta é: por onde começo a procurar? Eu passei pelos logs regulares e não vi nada que saltou para mim. Mas, obviamente, algo está acontecendo e não sei por onde começar.

    

Answer 1

Existem várias coisas que podem estar causando isso - infelizmente, provavelmente precisamos de mais algumas informações.

Antes de entrar na minha resposta real, apenas um ponto rápido em suas páginas HTML: em geral, o pool de aplicativos só pode responder a um determinado número de solicitações de cada vez. Se estiver ocupado respondendo a solicitações de páginas dinâmicas, talvez não tenha mais nenhum segmento para veicular as páginas estáticas. Por esse motivo, um problema de código em uma página dinâmica pode criar a ilusão de que as páginas estáticas estão sendo exibidas "lentamente". Meu ponto é, não descarte código ou SQL.

Como exemplo: se você tiver 100 páginas atingindo um banco de dados ou API ao mesmo tempo e todas as 100 estiverem aguardando uma resposta, a solicitação 101 poderá ser bloqueada até 1 dos primeiros 100 completa.

Agora , há muitas coisas que você pode fazer para ajudar a diagnosticar este problema:

• Qual é o seu perfil de carregamento normalmente? Isso faz uma grande diferença - pode ser que você sempre tenha um problema, mas não consegue ver o impacto até o seu site realmente receber carga. Você poderia tentar e testar isso (em teste) com algo como JMeter.

• Habilite os logs do IIS (se você ainda não tiver) e, em seguida, examine-os para ver quais solicitações estão demorando mais tempo. Você pode usar algo como Log Parser (da Microsoft) para executar consultas semelhantes a SQL em seus logs (ou até mesmo despejar seus logs em um banco de dados SQL), se isso facilitar a vida. Depois que você souber quais páginas estão demorando mais tempo, concentre um pouco de sua atenção nelas.

• Seu aplicativo tem logs? Se não, você deve considerar adicionar alguns logs. Se você já tem logs, o que eles dizem? Existem exceções sendo lançadas pelo seu aplicativo? Existe algo que está constantemente falhando?

• Quanta memória é o pool de aplicativos usando? Um vazamento de memória é um candidato óbvio, mas você deve ser bem fácil de ver. Use o Monitor de Desempenho do Windows para rastrear a memória consumida pelo pool de aplicativos durante o dia e veja se isso aumenta conforme o dia passa.

• Como mencionei na abertura, o SQL ainda pode ser um problema . Eu recomendaria dar uma olhada no servidor de banco de dados, para ver se há consultas de longa execução ou bloqueadas (por exemplo, em sys.dm_exec_requests , olhe para o wait_type , wait_time , blocking_session_id e o total_elapsed_time ).

• Verifique quantas conexões seu pool de aplicativos abriu , usando algo como TCPView (outra ferramenta da Microsoft). Seu pool de aplicativos tentará reutilizar conexões sempre que possível, mas você provavelmente verá muitas conexões abertas com o pool de aplicativos. Uma coisa interessante que você pode ver é que agora há muitas conexões abertas para o seu banco de dados SQL ou qualquer API externa que seu aplicativo esteja usando.

• Use uma ferramenta de desempenho e monitoramento de aplicativos. O AppDynamics, ou uma ferramenta semelhante, será capaz de ajudar a identificar partes de baixo desempenho do seu código. Infelizmente, há um pouco de curva de aprendizado para poder usar essas ferramentas com eficiência, mas elas podem ser muito eficientes para ajudar a diagnosticar problemas em seus aplicativos.

Atualizar

Reiniciar o pool de aplicativos pode ajudar a resolver o problema se houver um vazamento de memória, mas você precisa ter cuidado com isso: pode haver alguns impactos negativos. Depois de reiniciar o pool de aplicativos, o aplicativo começará a carregar objetos estáticos na memória, etc. Dependendo da complexidade do aplicativo, isso pode levar muito tempo (pode levar de 5 a 10 minutos ou mais). Durante esse período, as solicitações para o seu servidor podem ser atrasadas, fazendo com que apareça que o problema é exacerbado.

Se você estiver executando um único servidor, seu site poderá ficar temporariamente indisponível enquanto o aplicativo for reiniciado (devido ao fato de o pool de aplicativos estar ocupado e não conseguir responder a solicitações). Se você estiver executando em um farm, com um balanceador de carga, o balanceador de carga poderá eliminar seu servidor enquanto o pool de aplicativos reinicia, o que poderia direcionar todo o tráfego para outros servidores e sobrecarregá-los. Não reinicie o pool de aplicativos em todos os seus servidores ao mesmo tempo e tente "aquecer" pools de aplicativos (simulando solicitações no servidor) antes de reintroduzir servidores no farm.

Em outras palavras: a menos que seja definitivamente um problema com vazamento de memória, pode não valer a pena reiniciar o pool de aplicativos, porque o problema pode voltar a surgir imediatamente.

Observação: Reiniciar o pool de aplicativos não afetará as solicitações em execução no momento. Estes continuarão a ser concluídos, a menos que você desligue forçadamente o pool de aplicativos (por exemplo, Crtl + Alt + Del )

    

Answer 2

Pode ser que o código seja uma porcaria e vazamento de memória, e há um reinício noturno do pool de aplicativos que redefine o estado do aplicativo. Você já tentou depurá-lo de alguma forma? Servidor de teste, depurador, profiler, tudo isso sob alguma forma de carga que se assemelha à produção?

Quero dizer, também vale a pena revisar o desempenho real do servidor para garantir que não haja E / S lenta ou algo mais acontecendo com o servidor. Portanto, trabalhe com seu departamento de TI para descartar isso, claro. Palavras como Perfmon ou Solarwinds ou SCOM podem ser apropriadas, dependendo do seu ambiente. No entanto, você tem que estar disposto a fazer o trabalho do seu lado também.

Eu estive no lugar do cara de TI que é culpado por "aplicativos da web lenta", quando não há literalmente nenhum problema no servidor, mas há problemas no código.