Como eu avalio melhor o desempenho da consulta?

19

Eu tenho 2 procedimentos armazenados, onde o segundo procedimento armazenado é uma melhoria do primeiro.

Estou tentando medir exatamente o quanto isso é uma melhoria.

1 / Medição clock timenão parece ser uma opção, pois recebo diferentes tempos de execução. Pior ainda, às vezes (raramente, mas acontece) o tempo de execução do segundo procedimento armazenado é maior que o tempo de execução do primeiro procedimento (acho que devido à carga de trabalho do servidor naquele momento).

2 / Include client statisticstambém fornece resultados diferentes.

3 / DBCC DROPCLEANBUFFERS, DBCC FREEPROCCACHEsão boas, mas a mesma história ...

4 / SET STATISTICS IO ONpoderia ser uma opção, mas como eu poderia obter uma pontuação geral, pois tenho muitas tabelas envolvidas nos meus procedimentos armazenados?

5 / Include actual execution planpoderia ser uma opção também. Recebo um estimated subtreecostde 0,3253 para o primeiro procedimento armazenado e 0,3079 para o segundo. Posso dizer que o segundo procedimento armazenado é 6% mais rápido (= 0,3253 / 0,3079)?

6 / Usando o campo "Lê" no SQL Server Profiler?

Então, como posso dizer que o segundo procedimento armazenado é x% mais rápido que o primeiro, independentemente das condições de execução (a carga de trabalho do servidor, o servidor em que esses procedimentos armazenados são executados etc.)?

Se não for possível, como posso provar que o segundo procedimento armazenado tem um tempo de execução melhor que o primeiro procedimento armazenado?

Mihai Bejenariu
fonte

Respostas:

17

Eu gosto de usar a ferramenta gratuita SQLQueryStress ao comparar um cenário antes e depois. Com o SQLQueryStress, você pode executar cada procedimento armazenado quantas vezes quiser e obter as estatísticas médias totais de todas as execuções.

Por exemplo, você pode executar cada procedimento armazenado 100 vezes e, em seguida, usar as estatísticas para fazer backup de suas melhorias. "Mais de 100 execuções, minhas melhorias economizam um total de 30 segundos e o processo armazenado faz 1500 menos leituras por execução." Eu acho que você entendeu a ideia.

Se houver parâmetros no processo armazenado, é sempre uma boa ideia verificar se suas melhorias funcionam com muitos conjuntos diferentes de parâmetros. O SQLQueryStress faz algumas coisas legais, permitindo que você substitua os parâmetros na sua consulta para obter uma imagem geral melhor de como o processo armazenado pode estar executando.

Documentação do SQLQueryStress: http://www.datamanipulation.net/sqlquerystress/documentation/documentation.asp

SQLQueryStress

GoodwinSQL
fonte
6

4 / Você pode ir para http://statisticsioparser.com/statisticsioparser/ e colar suas estatísticas para ver a pontuação geral.

Nelson G
fonte
Leituras lógicas: 3101 vs 2943. Read-Ahead lê: 0 vs 8. Contagem de digitalizações: 637 no geral. Leituras físicas: 0 no geral. Leituras lógicas de LOB: 156 no geral.
Mihai Bejenariu
3

Quando você coletar os tempos de execução ao longo de alguns dias para seus dois procedimentos armazenados, vou recomendar que você use esta página inicial

http://www.evanmiller.org/ab-testing/t-test.html

para ver se eles são realmente diferentes.

A diferença de 6% não soa tanto quando se trata de melhorias nos procedimentos armazenados. Cheguei a esperar duas ordens de magnitude do meu colega e finjo estar decepcionado se ele atingir apenas uma ordem de magnitude ...

Ele não precisa usar a página inicial do EvanMiller para provar que sua solução funciona mais rapidamente.

Eu também instalaria o SQLSentrys (edit :) Plan Explorer em http://www.sqlsentry.com/, pois essa é uma ferramenta muito melhorada para comparar planos de execução.

Henrik Staun Poulsen
fonte