Profiling SQL Server e / ou ASP.NET

Question

Como um iria sobre perfis de algumas consultas que estão sendo executados a partir de uma aplicação ASP.NET? Existe algum software onde eu trabalho que é executado extremamente lento por causa do banco de dados (eu acho). As mesas têm índices mas ainda arrasta porque está trabalhando com tantos dados. Como posso perfil para ver onde eu possa fazer algumas pequenas melhorias que esperamos levar a melhorias maiores velocidade?

Edit:. Eu gostaria de acrescentar que o servidor web gosta de tempo limite durante estes longos consultas

Answer 1

Sql Server tem algumas excelentes ferramentas para ajudá-lo com esta situação. Estas ferramentas são incorporadas Management Studio (que costumava ser chamado de Enterprise Manager + Query Analyzer).

Use o SQL Profiler para mostrar-lhe as consultas reais provenientes da aplicação web.

Copiar cada um o problema consulta para fora (aqueles que consomem grande quantidade de tempo de CPU ou IO). Executar as consultas com "Mostrar plano de execução real". Esperamos que você vai ver algum índice óbvio que está faltando.

Você também pode executar o Assistente de ajuste (o botão fica ao lado de "display plano de execução real". Ele irá correr as sugestões de consulta e fazer.

Normalmente, se você já tem índices e consultas ainda estão em execução lenta, você terá que re-escrever as consultas de uma maneira diferente.

Manter todas as suas consultas em procedimentos armazenados faz este trabalho muito mais fácil.

Answer 2

Para o perfil SQL Server, use o SQL Profiler .

E você pode usar ANTS Profiler de Red Gate de perfil seu código.

Answer 3

Outra profiler .NET que funciona muito bem com ASP.NET é dotTrace . Eu pessoalmente tenho usado isso e encontrei muitos gargalos no meu código.

Answer 4

Eu acredito que você tem a resposta que você precisa para traçar o perfil das consultas. No entanto, esta é a parte mais fácil do ajuste de desempenho. Uma vez que você sabe que é as consultas e não a rede ou o aplicativo, como você encontrar e corrigir o problema?

O ajuste de desempenho é uma coisa complexa. Mas há alguns lugares para olhar em primeiro lugar. Você diz que estão retornando muitos dados? Você está voltando mais dados do que você precisa? Você está realmente retornando somente as colunas e registros que você precisa? Retornando 100 colunas usando select * pode ser muito mais lento do que devolver os 5 colunas na verdade você está usando.

Os seus índices e estatísticas up-to-date? Olhar para cima como para atualizar statisistcs e re-index em BOL, se você não tiver feito isso em um tempo. Você tem índices em todos os campos de associação? Como sobre os campos na cláusula WHERE.

Você usou um cursor? Você usou subqueries? Que tal união-se você estiver usando-o ele pode ser alterado para união tudo?

As suas consultas sargable (google se familiarizado com o termo.)

Você está usando distinta quando você poderia usar GROUP BY?

Você está recebendo fechaduras?

Existem muitas outras coisas para olhar estes são apenas um ponto de partida.

Answer 5

Se houver uma determinada consulta ou procedimento armazenado que deseja sintonizar, eu descobri ligar estatísticas antes da consulta para ser muito útil:

SET STATISTICS TIME ON
SET STATISTICS IO ON

Quando você ligar estatísticas em Query Analyzer, as estatísticas são mostradas no separador Mensagens do painel Resultados.

estatísticas IO têm sido particularmente útil para mim, porque permite-me saber se eu poderia precisar de um índice. Se eu vejo uma alta contagem de leitura das estatísticas IO, eu poderia tentar adicionar diferentes índices para as tabelas afetadas. Como eu tento um índice, eu executar a consulta novamente para ver se a contagem de leitura tem ido para baixo. Após algumas iterações, eu posso geralmente encontrar o melhor índice (es) para as tabelas envolvidas.

Aqui estão os links para MSDN para comandos estas estatísticas:

SET STATISTICS TIME

SET STATISTICS IO