No se trata de "cuál es el ORM más rápido", ni se trata de "cómo escribir un buen código con ORM". Este es el otro lado: el código se ha escrito, se ha publicado, varios miles de usuarios están llegando a la aplicación, pero se percibe un problema general de rendimiento. Un rastreo de SQL Profiler solo se puede ejecutar durante un corto período de tiempo: 5 minutos ofrece varios cientos de miles de resultados.Seguimiento del rendimiento de ORM
La pregunta es simplemente la siguiente: habiendo usado el Analizador de SQL para reducir un número de consultas lentas (duración mayor que una cantidad dada de tiempo), ¿qué técnicas y soluciones existen para rastrear estas consultas SQL en el componente problemático? Una pregunta relegada es que si un área específica es lenta, ¿cómo podemos identificar el SQL que esta área está ejecutando para que pueda ser filtrado adecuadamente en el Analizador de SQL?
El trasfondo de esto es que tenemos una aplicación bastante grande con una estructura de tabla bastante compleja, y actualmente se basa en el acceso a datos a través de procedimientos almacenados. Si surge un problema de rendimiento de SQL, generalmente es el caso de extraer el generador de perfiles SQL, averiguar si hay algo lento (filtrar por duración) o si el área que se reclama es lenta (filtrar por procedimiento almacenado) y ajustar los procedimientos almacenados (o el esquema - a través de indexación).
Ahora hay un impulso para mover nuestro código de una solución en su mayoría a una solución ORM en su mayoría, sin embargo, la gran presión contra el movimiento es cómo los problemas de rendimiento, si surgen, se remontan a un código problemático. He leído todo y parece que, en la mayoría de las ocasiones, puede implicar herramientas de terceros (herramientas de seguimiento de ORM como NHProf o utilidades de rastreo de .NET como dottrace) que tendríamos que instalar en el servidor. Ahora bien, si se pueden instalar herramientas adicionales en un entorno en vivo es otra pregunta, por lo que si se pueden realizar cosas como esta sin herramientas adicionales, eso puede ser una ventaja.
Estoy interesado principalmente en soluciones con SQL Server 2008, pero es probablemente lo suficientemente genérico para cualquier RDBMS. En cuanto a la tecnología ORM, en esto no tengo un enfoque específico ya que nada está actualmente en uso, así que esté interesado en escuchar cómo las técnicas difieren (o son comunes) entre nHibernate, fluent-nhibernate y Entity Framework. Sin embargo, otros ORM son bienvenidos si ofrecen algo más :-)
He leído How to find and fix performance problems (...), y creo que el problema es simplemente la sección que dice "aislar". Un problema que es fácilmente reproducible solo en un sistema en vivo va a ser difícil de aislar. Las cifras que cité en el párrafo 2 son figuras de los tipos de volúmenes que podemos obtener de un perfil también ...
Si tiene experiencia real de rastreo de ORM en vivo, mucho mejor :-)
Actualización, 2016-10-21: Para completar, eventualmente resolvimos esto para NHibernate escribiendo código y reemplazando los métodos de NHibernate. Los detalles completos en esta otra pregunta ASÍ: NHibernate and Interceptors - measuring SQL round trip times. Espero que este sea un enfoque similar para muchos ORM diferentes.
¿Ya está familiarizado con los diversos DMV e informes que muestran la consulta principal por duración, CPU, IO, etc. en función de las estadísticas del plan de ejecución en lugar de los perfiles? Además, ¿qué versión de SQL Server? Si 2008 existe el almacén de datos de gestión que puede ayudar (aunque supongo que con consultas no parametrizadas emitidas por un ORM puede terminar con muchas consultas similares y planes que dificultan la agregación de los resultados) –
Pregunta interesante, espero aprender algo sobre este tema ya que no tengo una respuesta para ti. – HLGEM
@Martin - perdón, 2008 (pregunta editada). Ahora que mencionas el DMV, que hace sonar las campanas, investigará. La aplicación en este momento se basa en SQL 2000, pero la próxima versión se eleva a 2008. No * demasiado * molesto sobre 2000 soluciones. Aunque una vez que tenemos la consulta, ¿cómo rastreamos eso hacia atrás al módulo que está causando el problema a través de la capa ORM? –