Pruebas de estres en SQL Server con SQLCMD

Hemos visto anteriormente las Alternativas de uso de SQLCMD, y claro, vemos que hay varias cosas que podemos realizar. Una de ellas y particularmente la que más me gusta, es aprovecharla para nuestras fases de Testing. Veremos aquí lo fácil que es crear Pruebas de estres en SQL Server con SQLCMD.

Primero. ¿Qué NO es una prueba de estrés?

He visto muchos casos en los que para simular esfuerzos del motor se generan bucles o ciclos de cientos de ejecuciones desde una misma sesión.

Si todo está en una misma conexión, mi amigo/a, no hay simulación de concurrencia, entonces, no hay generación de estrés.

Ejecutar un mismo query varias veces (dentro de un WHILE o colocando un número al GO), ejecuta la sentencia en serie. Así nunca habrán diferentes procesos solicitando el mismo recurso.

Entonces. ¿Qué es una prueba de estrés?

Debes hacer todo lo contrario al caso anterior. Hacer aparecer ejecuciones en paralelo.

Y esto no es cuestión de una magia oscura. Verás que es muy sencillo y puedes aprovechar de tremenda herramienta como es la línea de comandos.

Es tu oportunidad de prenderle fuego a tu SQL Server.

Todo listo para empezar

Ya sabes cómo funcionan las líneas de comando y además seguro que ya viste Cómo usar SQLCMD con SQL Server.

Vamos a hacerlo súper sencillo con tres pasos.

• Un archivo .sql con la consulta que quieres estresar
• Un archivo .bat que llame al primero
• Un archivo .bat que simule la concurrencia

1. El archivo del Query

Escoge aquel que quieres probar su comportamiento mientras tus usuarios le dan con todo. Vamos a simular ejecuciones contínuas al colocarlo dentro de un ciclo.

DECLARE @i INT
SET @i = 0

WHILE (@i < 1000)
BEGIN
	-- Replace with your query
	SELECT 
		[City Key],
		[Salesperson Key],
		SUM(Quantity),
		SUM([Total Including Tax])
	FROM WideWorldImportersDW.Fact.OrderHistory
	GROUP BY 
	City Key,
	[Salesperson Key]
	--

	SET @i = @i + 1
END

Tan sencillo como dejarlo dentro de un loop para que se vaya ejecutando. El tamaño del ciclo depende de tí, puedes cambiar esos 1000 como prefieras. Yo sugeriría que dependiendo de la complejidad de tu consulta, empieces con un número más pequeño y vayas subiendo el esfuerzo.

No vayas a utilizar tu consulta llena de Vistas Anidadas que dentro de un Procedimiento Almacenado llama a los Triggers que actualizan 10 Tablas distribuidas en diferentes Bases de Datos 😉

No es que no puedes hacerlo, pero no queremos matar al servidor desde un principio, ¿cierto?

Yo guardé la consulta en un archivo llamado Query.sql

2. Simplemente llamamos al Query

En un segundo archivo, utilizamos nuestra gran herramienta SQLCMD. Lo único que haremos es llamar al archivo creado en el paso anterior.

sqlcmd -S.\SQL19 -iQuery.sql -dWideWorldImportersDW

Ya has visto la sintaxis de SQLCMD en el post que referencié más arriba. Solamente debes cambiar el nombre de tu servidor luego del parámetro S (colocando instancia si la tienes), el archivo input del parámetro i será el que creamos más arriba y el nombre de la base de datos con el parámetro d.

Si quieres probar la base de datos WideWorldImportes puedes ver este enlace.

A esta simple llamada la nombré RunQuery.bat

3. La clave. Concurrencia

Ya tienes dos archivos. Uno con el Query y otro que lo llama.

Ahora bien, necesitamos simular que diferentes usuarios al mismo tiempo están ejecutando varias llamadas a la consulta que quieres evaluar.

Vamos a hacerlo igual de sencillo. Crearemos un nuevo archivo bat que llame varias veces al SQLCMD que creamos en RunQuery.bat. El código es así de simple.

START RunQuery.bat
START RunQuery.bat
START RunQuery.bat
START RunQuery.bat
START RunQuery.bat
START RunQuery.bat
START RunQuery.bat

Y lo coloqué en un archivo llamado RunStress.bat

Ahora sí, la magia

Ejecuta el archivo RunStress.bat y…

Empezamos a generar el estrés.

¿Qué hacemos en estas pruebas de estres en SQL Server?

En este ejemplo es simple, simulamos 7 usuarios concurrentes que están ejecutando todo el tiempo la consulta que definimos.

¿Puedes simular más usuarios? Por supuesto que sí, incluso hacer más grandes los ciclos del WHILE para la cantidad de ejecuciones se incremente. Claro, te repito, no queremos matar al servidor a la primera así que evalúa cómo hacer tus pruebas en base al esfuerzo que necesitan.

El monitoreo es vital cuando hacemos Testing, no solo para Producción. Así que puedes empezar leyendo sobre Cómo medir el rendimiento en SQL Server, y tal vez después, pueden empezar a Usar los Performance Counters del servidor.

Las pruebas son muy importantes antes de enviar programas a Producción. Justamente hacer pruebas de estrés es un punto muy importante cuando queremos Hacer Testing en SQL Server, así que tienes un primer gran paso avanzado.