Buena forma de cronometrar las consultas SQL cuando se utiliza Linq to SQL

Question

¿Existe una buena manera de cronometrar las consultas SQL cuando se utiliza Linq to SQL?Realmente me gusta la función de registro, pero sería fantástico si de alguna manera también pudieras cronometrar esa consulta.¿Algunas ideas?

Answer 1

SQL Profiler para obtener la consulta y la hora, y también la ruta de ejecución en el analizador de consultas para ver dónde están los cuellos de botella.

Answer 2

Como ya dijeron dos personas, SQL Profiler es la herramienta lista para usar que se puede usar para eso.No quiero hacerme eco pero quería elaborar un poco más en detalle:No solo proporciona los tiempos reales de SQL Server (a diferencia de los tiempos del lado de la aplicación donde se agregan al pastel los tiempos de E/S de red, conexión y grupo de conexiones), sino que también le brinda la [a menudo más importante] I. /O cifras estadísticas, información de bloqueo (según sea necesario), etc.

La razón por la que las estadísticas de E/S son importantes es que una consulta muy costosa puede ejecutarse rápidamente y consumir cantidades excesivas de recursos del servidor.Si, por ejemplo, una consulta que se ejecuta a menudo llega a tablas grandes y no hay índices coincidentes resultantes de los escaneos de la tabla, SQL Server almacenará en caché las tablas afectadas en la memoria (si es posible).A veces, esto puede hacer que la misma consulta se ejecute increíblemente rápido mientras, en efecto, está dañando el resto del sistema/aplicación/base de datos al consumir recursos del servidor.

Bloquear información es casi tan importante -> las consultas pequeñas que realizan búsquedas de PK para un solo registro pueden tener malos tiempos debido al bloqueo.Leí en alguna parte que este mismo sitio estuvo plagado de bloqueos en sus primeros días beta.SQL Profiler también es su amigo para identificar y resolver problemas causados ​​por el bloqueo.

Para resumirlo;ya sea que use L2S, EF o ADO simple, si desea asegurarse de que su aplicación "se comporte bien" con la base de datos, tenga siempre listo SQL Profiler durante el desarrollo y las pruebas.¡Vale la pena!

Editar: Desde que escribí la respuesta anterior, he desarrollado una nueva herramienta de creación de perfiles en tiempo de ejecución para L2S que reúne lo mejor de ambos mundos;Estadísticas de E/S y tiempos del lado del servidor de SQL Server, plan de ejecución de SQL Server, alertas de "índice faltante" de SQL Server, combinados con la pila de llamadas administrada para facilitar la búsqueda del código que generó una determinada consulta y algunas opciones de filtro avanzadas. para registrar solo consultas que cumplan ciertos criterios.Además, el componente de registro se puede distribuir con aplicaciones para facilitar la creación de perfiles de consultas en tiempo de ejecución en entornos de clientes en vivo.La herramienta se puede descargar desde:

http://www.huagati.com/L2SProfiler/ donde también podrás obtener una licencia de prueba gratuita de 45 días.

Aquí también se publica una descripción más detallada de los antecedentes y una introducción a la herramienta:
http://huagati.blogspot.com/2009/06/profiling-linq-to-sql-applications.html

...y una muestra/tutorial sobre el uso de algunas de las opciones de filtro más avanzadas está disponible aquí:
http://huagati.blogspot.com/2009/08/walkthrough-of-newest-filters-and.html

Answer 3

Podrías usar un System.Diagnostics.Stopwatch le permitirá realizar un seguimiento del tiempo que se ejecuta la consulta.Solo recuerde que las consultas Linq->SQL no se ejecutan hasta que las enumere.También tenga en cuenta que si está iniciando sesión en Console.Out habrá un impacto significativo en el rendimiento.

Answer 4

Lo que podría hacer es agregar una implementación TextWriter personalizada a DataContext.Log que escribirá el SQL generado en un archivo o memoria.Luego recorra esas consultas, ejecutándolas con código ADO.NET sin formato, rodeando cada una de ellas con un cronómetro.

He usado una técnica similar antes porque parecía que cada vez que estaba desarrollando algún código nunca tenía Profiler abierto, y era muy fácil enviar esos resultados a una página HTML.Seguro que los ejecuta dos veces por solicitud del sitio web, pero es útil ver los tiempos de ejecución lo antes posible en lugar de esperar hasta detectar algo en Profiler.

Además, si va a la ruta de la herramienta SQL, le recomendaría buscar en Google "DMV de consulta más lenta" y obtener un procedimiento almacenado que pueda brindarle estadísticas sobre las consultas más lentas en su base de datos.No siempre es fácil desplazarse por los resultados del generador de perfiles para encontrar las consultas incorrectas.Además, con las consultas correctas sobre el dmv de SQL 2005, también puede realizar pedidos, digamos cpu vs.tiempo y así sucesivamente.

Answer 5

Usamos SQL Profiler para probar nuestras consultas con LLBLGen Pro.

Answer 6

Lo mejor es registrar las consultas en un archivo y usar SQL Profiler para cronometrarlas y modificar los índices de las consultas.