Testando a escalabilidade do procedimento armazenado

Eu tenho um aplicativo de email que será solicitado a entregar à interface do usuário o número de novas mensagens para um determinado usuário em cada carregamento de página. Eu tenho algumas variações de coisas que estou testando no nível do banco de dados, mas todas são abstraídas pela chamada de proc armazenada.

Estou tentando bater o banco de dados para ver qual seria o ponto de interrupção (número de solicitações por segundo).

Em poucas palavras, tenho uma tabela como esta userId, newMsgCount com um índice agrupado em userId. O SQL deve ser capaz de servidor centenas ou milhares dessas respostas por segundo. Eu acho que o retardatário é meu aplicativo .NET.

Como posso fazer deste um bom teste para alcançar os resultados com base no desempenho do SQL?

Existe uma ferramenta para isso que eu posso dar a ele um nome de processo armazenado e param para que ele compile meu banco de dados?

Eu quero ver se o banco de dados pode retornar um minuto. de 250 respostas por segundo.

O SQLQueryStress é uma ótima ferramenta para testes de simultaneidade em pequena escala, mas na verdade não depende do trabalho de teste de carga. Um conjunto de ferramentas surpreendentemente pouco conhecido está disponível gratuitamente, da Microsoft, que pode lidar com a maioria dos cenários de teste de estresse do SQL Server, os RML Utilities .

Um resumo muito breve das ferramentas:

• O ReadTrace converte os rastreamentos do Profiler de arquivos .trc em .rml (Replay Markup Language).
• OStress é usado para reproduzir arquivos .rml e .sql em um servidor.
• ORCA (OStress Replay Control Agent) coordena a reprodução nas instâncias distribuídas do OStress.
• O Reporter fornece relatórios de análise de desempenho.

Há um excelente artigo de início rápido da equipe do SQLCat que inclui um banco de dados de amostra e cargas de trabalho, Precision Performance para Microsoft SQL Server usando o RML Utilities 9.0

Você tem a opção de criar uma atividade de criação de perfil para reprodução ou, possivelmente mais apropriada em seu cenário, acionar manualmente um conjunto de scripts .sql que serão reproduzidos via OStress e ORCA.

Ótimas ferramentas para testar carga e investigar problemas de desempenho.

Uma ferramenta que você pode usar é o SQLQueryStress . Para um início rápido, forneça: o procedimento armazenado, as iterações e o número de threads. Em seguida, inicie o teste de estresse. Métricas como segundos da CPU, leituras lógicas, etc ... serão mostradas.

Parece que você é um desenvolvedor .NET. Uma maneira seria escrever um aplicativo pequeno que use multithreading e tenha apenas uma quantidade definida de ocorrências simultâneas no banco de dados e no procedimento armazenado. Execute um rastreamento enquanto isso estiver acontecendo.

Escreva o código do aplicativo para aumentar a quantidade de threads simultâneos em um intervalo específico se desejar aumentar automaticamente a carga no SQL Server.

É assim que eu diria.