Lista definitiva de etapas para o teste de linha de base do SQL Server?

Antes de executar um teste de desempenho / linha de base para um aplicativo que usa o SQL Server, desejo poder definir a instância para um estado "limpo", sem reiniciar a instância. Existem etapas que eu tendem a seguir, mas quero criar uma lista definitiva que esteja na sequência correta e que não tenha etapas redundantes.

Esta lista de etapas realiza a configuração do SQL Server para um estado "limpo"?

A sequência é lógica / correta?

Existem etapas redundantes?

CHECKPOINT              -- Write all dirty pages

DBCC DROPCLEANBUFFERS   -- All should be clean after checkpoint?

DBCC FREEPROCCACHE      -- Clear the plan cache

DBCC FREESYSTEMCACHE    -- Is this necessary after FREEPROCCACHE?

DBCC FREESESSIONCACHE   -- May not be necessary if distributed queries aren't used, but want to catch all scenarios

EXEC SP_UPDATESTATS     -- Refresh stats

'BEGIN TESTING!'

— Eric Higgins
fonte

Para sua informação, o DROPCLEANBUFFERSteste é bom para testar, mas nem sempre é preciso. Se você estiver referenciando uma tabela de alto volume, é muito provável que você quase sempre tenha páginas na memória, e o tempo de IO não será um grande fator nessa consulta. Você pode colocar mais peso no IO do que é realista nesse caso.

— JNK

Você está falando sobre testes em um ambiente de produção ou em um ambiente de teste isolado?

— Bopapa_1979

Qualquer pessoa que teste em um ambiente Prod deve ser demitida. :) Sim, ambientes de teste.

— Eric Higgins

Primeiro, eu recuaria e perguntaria quais medidas você planeja coletar durante o teste. Se você estiver contando leituras lógicas por consulta, por exemplo, não precisará liberar o cache. Sou muito fã de usar leituras lógicas porque é independente de os dados serem armazenados em cache ou em disco - e na produção, é difícil adivinhar se os dados de uma consulta serão armazenados em cache ou não (a menos que você armazene em cache todo o banco de dados na memória) . Se você ajustar para minimizar as leituras lógicas, o aplicativo será mais rápido, independentemente de os dados estarem em cache ou não.

Em seguida, eu questionaria o que está mudando entre as execuções. Por exemplo, executando EXEC SP_UPDATESTATS em cada banco de dados, conforme sugerido, você vai redefinir as estatísticas das tabelas que foram atualizadas. No entanto, a menos que você esteja atualizando estatísticas com o fullscan, está obtendo linhas aleatórias da tabela - isso não é muito repetitivo, e eu não acho que você realmente queira fazer isso. Em vez disso, convém restaurar os bancos de dados entre cada execução para sempre testar exatamente os mesmos dados. Se seus testes estiverem fazendo inserções / atualizações / exclusões, eles podem ter perfis de desempenho diferentes a cada execução, se você não estiver restaurando o banco de dados (porque eles estão adicionando / alterando dados, além de alterar estatísticas nos dados) - e ainda pior,

— Brent Ozar
fonte

Muito bons pontos, o objetivo é ter tudo idêntico entre as corridas. As medidas que estou fazendo neste caso @ hand são tempos de execução para funções específicas em um aplicativo (x segundos para retornar a lista ao aplicativo, y segundos para adicionar um item da fila, etc.). O que está mudando entre os testes pode ser partes do código do aplicativo e não objetos SQL, objetos SQL e não código do aplicativo ou configurações no nível da instância / banco de dados, como simultaneidade sem alterações no código do aplicativo. Se eu fosse adicionar uma restauração fora do portão antes de cada teste, como você se sente sobre a minha lista acima @ nesse ponto? Estou faltando alguma coisa ou a sequência precisa de algum trabalho?

— Eric Higgins

Brent, você está considerando a CPU nos seus testes?

— AK

@EricHiggins Em vez de testar várias coisas ao mesmo tempo, eu testaria as peças individualmente. Prefiro testar as consultas diretamente e ver quais alterações afetam o desempenho lá. Por exemplo, execute um rastreamento SQL enquanto executa funções específicas no aplicativo e continue reproduzindo esse rastreamento enquanto faz alterações de índice / configuração para melhorar o desempenho e observe coisas como leituras lógicas e métricas da CPU nos rastreamentos.

— Brent Ozar

@AlexKuznetsov Na verdade, não fui eu quem testou - foi Eric quem fez a pergunta. Quando faço esse tipo de trabalho, analiso as métricas da CPU no nível da consulta e no servidor em geral.

— Brent Ozar

Utilizamos um gerador de carga de terceiros (e temos uma pessoa em período integral dedicada ao desenvolvimento de testes de carga). Então, meus testes são precisos para a transação, sequência, número de usuários, etapas exatas executadas no aplicativo ... tudo. Portanto, não preciso necessariamente olhar para as métricas de tipo de painel do SQL. O software de teste de carga controla os tempos de resposta dos módulos do aplicativo em milissegundos. Portanto, fazer uma restauração do banco de dados é uma boa ideia. Preciso verificar com sanidade os outros passos que estou fazendo para ter certeza de que estou cumprindo o estado "Limpo" que estou buscando antes de cada rodada de teste.

— Eric Higgins