Perfilado de SQL Server y / o ASP.NET

Question

¿Cómo se podría hacer un perfil de algunas consultas que se ejecutan desde una aplicación ASP.NET? Hay algún software donde trabajo que funciona extremadamente lento debido a la base de datos (creo). Las tablas tienen índices pero aún se arrastra porque está trabajando con muchos datos. ¿Cómo puedo hacer un perfil para ver dónde puedo hacer algunas mejoras menores que con suerte conducirán a mejoras de velocidad más grandes?

Editar: me gustaría agregar que al servidor web le gusta el tiempo de espera durante estas largas consultas.

Answer 1

SQL Server tiene algunas herramientas excelentes para ayudarlo con esta situación. Estas herramientas están integradas en Management Studio (que solía llamarse Enterprise Manager + Query Analyzer).

Use SQL Profiler para mostrarle las consultas reales que provienen de la aplicación web.

Copie cada una de las consultas de problemas (las que consumen mucho tiempo de CPU o IO). Ejecute las consultas con " Mostrar plan de ejecución real " ;. Esperemos que vea algún índice obvio que falta.

También puede ejecutar el asistente de ajuste (el botón está justo al lado de "mostrar el plan de ejecución real". Ejecutará la consulta y hará sugerencias.

Por lo general, si ya tiene índices y las consultas aún se ejecutan lentamente, deberá volver a escribir las consultas de una manera diferente.

Mantener todas sus consultas en procedimientos almacenados hace que este trabajo sea mucho más fácil.

Answer 2

Para perfilar SQL Server, use el SQL Profiler .

Y puede usar ANTS Profiler de Red Gate a perfil su código.

Answer 3

Otro perfilador .NET que funciona muy bien con ASP.NET es dotTrace . Lo he usado personalmente y he encontrado muchos cuellos de botella en mi código.

Answer 4

Creo que tiene la respuesta que necesita para perfilar las consultas. Sin embargo, esta es la parte más fácil del ajuste de rendimiento. Una vez que sepa que son las consultas y no la red o la aplicación, ¿cómo encuentra y soluciona el problema?

El ajuste del rendimiento es algo complejo. Pero hay algunos lugares para mirar primero. ¿Dices que estás devolviendo muchos datos? ¿Está devolviendo más datos de los que necesita? ¿Realmente devuelve solo las columnas y los registros que necesita? Devolver 100 columnas utilizando select * puede ser mucho más lento que devolver las 5 columnas que realmente está utilizando.

¿Están actualizados sus índices y estadísticas? Busque cómo actualizar estadísticas y volver a indexar en BOL si no lo ha hecho en un tiempo. ¿Tiene índices en todos los campos de unión? ¿Qué hay de los campos en la cláusula where?

¿Has usado un cursor? ¿Has usado subconsultas? ¿Qué hay de union? Si lo está utilizando, ¿se puede cambiar a union all?

¿Sus consultas son sargable (google si no está familiarizado con el término)

¿Está usando distintas cuando podría usar group by?

¿Tienes cerraduras?

Hay muchas otras cosas que mirar, estos son solo un punto de partida.

Answer 5

Si hay una consulta particular o un procedimiento almacenado que quiero ajustar, he encontrado que activar las estadísticas antes de la consulta es muy útil:

SET STATISTICS TIME ON
SET STATISTICS IO ON

Cuando activa las estadísticas en el Analizador de consultas, las estadísticas se muestran en la pestaña Mensajes del panel Resultados.

Las estadísticas IO me han sido particularmente útiles, porque me permiten saber si necesito un índice. Si veo un alto recuento de lectura de las estadísticas de IO, podría intentar agregar diferentes índices a las tablas afectadas. Cuando intento un índice, vuelvo a ejecutar la consulta para ver si el recuento de lecturas se ha reducido. Después de algunas iteraciones, generalmente puedo encontrar los mejores índices para las tablas involucradas.

Aquí hay enlaces a MSDN para estos comandos de estadísticas:

ESTABLECER HORA ESTADÍSTICA

SET STATISTICS IO