¿Lista definitiva de pasos para la prueba de línea de base de SQL Server?

Antes de ejecutar una prueba de rendimiento / línea de base para una aplicación que utiliza SQL Server, quiero poder establecer la instancia en un estado "limpio", sin reiniciar la instancia. Hay pasos que suelo seguir, pero quiero construir una lista definitiva que esté en la secuencia correcta y que no tenga pasos redundantes.

¿Esta lista de pasos logra configurar SQL Server en un estado "limpio"?

¿Es la secuencia lógica / correcta?

¿Hay pasos 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
fuente

Para su información, DROPCLEANBUFFERSes bueno para las pruebas, pero no siempre es preciso. Si hace referencia a una tabla de alto volumen, es muy probable que casi siempre tenga páginas en la memoria, y el tiempo de E / S no será un factor importante en esa consulta. Puede estar poniendo más peso en IO de lo que es realista en ese caso.

— JNK

¿Estás hablando de probar en un entorno de producción o un entorno de prueba aislado?

— bopapa_1979

Cualquier persona que realice pruebas en un entorno Prod debería ser despedido. :) Sí, entornos de prueba.

— Eric Higgins

Primero, daría un paso atrás y le preguntaría qué medidas planea recolectar durante la prueba. Si está contando lecturas lógicas por consulta, por ejemplo, no necesita liberar el caché. Soy un gran admirador del uso de lecturas lógicas porque es independiente de si los datos están en caché o en el disco, y en producción, es difícil adivinar si los datos de una consulta se almacenarán en caché o no (a menos que guarde en caché toda la base de datos en la memoria) . Si sintoniza para minimizar las lecturas lógicas, la aplicación irá más rápido si los datos están en caché o no.

A continuación, me preguntaría qué está cambiando entre las ejecuciones. Por ejemplo, al ejecutar EXEC SP_UPDATESTATS en cada base de datos como ha sugerido, volverá a muestrear las estadísticas de las tablas que se han actualizado. Sin embargo, a menos que esté actualizando estadísticas con fullscan, obtendrá filas aleatorias de la tabla; eso no es demasiado repetible, y no creo que realmente quiera hacerlo. En cambio, es posible que desee restaurar las bases de datos entre cada ejecución para que siempre esté probando exactamente los mismos datos. Si sus pruebas están haciendo inserciones / actualizaciones / eliminaciones, pueden tener diferentes perfiles de rendimiento en cada ejecución si no está restaurando la base de datos (porque están agregando / cambiando datos, además de cambiar las estadísticas de los datos), y peor aún,

— Brent Ozar
fuente

Muy buenos puntos, el objetivo es tener todo idéntico entre carreras. Las medidas que estoy tomando en este caso @ hand son tiempos de ejecución para funciones específicas en una aplicación (x segundos para devolver la lista a la aplicación, y segundos para agregar un elemento de cola, etc.). Lo que está cambiando entre las pruebas podría ser piezas de código de aplicación y no objetos SQL, objetos SQL y no código de aplicación, o configuraciones de nivel de instancia / base de datos como concurrencia sin cambios en el código de la aplicación. Si tuviera que agregar una restauración fuera de la puerta antes de cada prueba, ¿cómo se siente acerca de mi lista arriba de ese punto? ¿Me estoy perdiendo algo o la secuencia necesita algo de trabajo?

— Eric Higgins

Brent, ¿estás teniendo en cuenta la CPU en tus pruebas?

— AK

@EricHiggins En lugar de probar varias cosas a la vez, probaría las piezas individualmente. Prefiero probar las consultas directamente y ver qué cambios afectan el rendimiento allí. Por ejemplo, ejecute un seguimiento de SQL mientras realiza funciones específicas en la aplicación, y luego siga repitiendo ese seguimiento mientras realiza cambios de índice / configuración para mejorar el rendimiento, y observe cosas como lecturas lógicas y métricas de CPU en los seguimientos.

— Brent Ozar

@AlexKuznetsov No soy el que hace las pruebas, en realidad, Eric es el que hizo la pregunta. Cuando hago este tipo de trabajo, miro las métricas de la CPU a nivel de consulta, así como el servidor en general.

— Brent Ozar

Utilizamos un generador de carga de terceros (y tenemos una persona a tiempo completo dedicada al desarrollo de pruebas de carga). Entonces, mis pruebas son precisas para la transacción, la secuencia, el número de usuarios, los pasos exactos realizados en la aplicación ... todo. Por lo tanto, no necesariamente necesito mirar las métricas de tipo de panel de SQL en absoluto. El software de prueba de carga rastrea los tiempos de respuesta para los módulos de la aplicación hasta el milisegundo. Entonces, hacer una restauración de DB es una buena idea. Necesito verificar la cordura de los otros pasos que estoy haciendo para asegurarme de que estoy logrando ese estado de "pizarra limpia" que estoy buscando antes de cada ronda de pruebas.

— Eric Higgins