Prueba de escalabilidad de procedimientos almacenados

Tengo una aplicación de correo electrónico a la que se le pedirá que envíe a la interfaz de usuario la cantidad de mensajes nuevos para un usuario determinado en cada carga de página. Tengo algunas variaciones de las cosas que estoy probando en el nivel de base de datos, pero todas se resumen en la llamada de proceso almacenada.

Estoy tratando de cerrar la base de datos para ver cuál sería el punto de ruptura (número de solicitudes por segundo).

En pocas palabras, tengo una tabla como este userId, newMsgCount con un índice agrupado en userId. SQL debería poder servir cientos o miles de estas respuestas por segundo. Creo que el rezagado es mi aplicación .NET.

¿Cómo puedo hacer de esta una buena prueba para lograr los resultados de la prueba basados ​​en el rendimiento de SQL?

¿Existe una herramienta para esto que pueda darle un nombre de proceso almacenado y un parámetro para que agregue mi DB?

Quiero ver si el DB puede devolver un minuto. de 250 respuestas por segundo.

SQLQueryStress es una gran herramienta para pruebas de simultaneidad a pequeña escala, pero no está realmente a la altura de las pruebas de carga. Un conjunto de herramientas sorprendentemente poco conocido está disponible de forma gratuita, de Microsoft, que puede hacer frente a la mayoría de los escenarios de pruebas de estrés de SQL Server, las utilidades RML .

Un breve resumen de las herramientas:

• ReadTrace convierte las trazas de Profiler de archivos .trc a .rml (Replay Markup Language).
• OStress se utiliza para reproducir archivos .rml y .sql en un servidor.
• ORCA (Agente de control de reproducción OStress) coordina la reproducción en instancias distribuidas de OStress.
• Reporter proporciona informes de análisis de rendimiento.

Hay un excelente artículo de inicio rápido del equipo de SQLCat que incluye una base de datos de muestra y cargas de trabajo, Precision Performance para Microsoft SQL Server usando RML Utilities 9.0

Tiene la opción de realizar una actividad de generación de perfiles para la reproducción o, posiblemente, más apropiado en su escenario, poner a mano un conjunto de scripts .sql que luego reproducirá a través de OStress y ORCA.

Excelentes herramientas para probar la carga e investigar problemas de rendimiento.

Una herramienta que puede usar es SQLQueryStress . Para un inicio rápido, proporcione: el procedimiento almacenado, las iteraciones y el número de subprocesos. Luego comience la prueba de estrés. Se mostrarán métricas como segundos de CPU, lecturas lógicas, etc.

Parece que eres un desarrollador de .NET. Una forma sería escribir una pequeña aplicación que use subprocesos múltiples y tenga solo una cantidad establecida de visitas simultáneas a la base de datos y al procedimiento almacenado. Ejecute un seguimiento mientras esto sucede.

Escriba el código de la aplicación para incrementar la cantidad de subprocesos concurrentes en un intervalo específico si desea aumentar automáticamente la carga en SQL Server.

Así es como lo haría.