performance - DbContext ChangeTracking mata el rendimiento?
entity-framework-4.1 change-tracking (2)
Estoy en el proceso de actualizar una aplicación de EF1 a EF4.1 Creé un DbContext y un conjunto de POCO usando las plantillas "ADO.NET DbContext Generator".
Cuando consulto el DbContext generado, la parte de la base de datos de la consulta tarda 4 ms en ejecutarse (validada con EF Profiler). Y luego toma el contexto unos 40 segundos (en palabras: ¡CUARENTA!) Para hacer lo que sea que haga antes de devolver el resultado a la aplicación.
EF1 maneja la misma consulta en menos de 2 segundos.
Desactivar AutoDetectChanges, LazyLoading y ProxyGeneration me gana 2-3 segundos.
Cuando uso el método de extensión AsNoTracking (), puedo reducir el tiempo total de ejecución a aproximadamente 3 segundos.
Eso indica que ChangeTracking es el culpable.
Pero ChangeTracking es lo que necesito. Debo poder eventualmente persistir todos los cambios sin tener que seleccionar manualmente qué entidades fueron modificadas.
¿Alguna idea de cómo podría resolver ese problema de rendimiento?
¿Es útil la técnica al final de esta documentation ? Alternativamente, he evitado muchas de las trampas en el rendimiento usando una interfaz fluida para declarar declarativamente qué entidades en una transacción dada seguramente no cambiarán frente a las que podrían cambiar (inmutables vs. inmutables). Por ejemplo, si las entidades que guardo son raíces agregadas en las que la raíz o sus entidades hacen referencia a elementos "refdata", esta heurística evita muchas escrituras porque no es necesario rastrear los elementos inmutables. Los elementos mutables se escriben sin control (una debilidad ... Uno que puede o no ser aceptable).
Estoy usando esto con un patrón de repositorio genérico precisamente porque no quiero rastrear cambios o implementar una estrategia específica para cada caso. Si eso no es suficiente, quizás establezca su propio seguimiento de cambios fuera del contexto y agregue entidades según sea necesario.
Sin ver la consulta, no puedo decir con seguridad cuál podría ser el problema. ¿Podría estar relacionado?
¿Por qué el operador Contains () degrada el rendimiento de Entity Framework de manera tan dramática?
Dependiendo de los operadores LINQ que se usen, parece que EF tiene dificultades para convertir algunas consultas a SQL. Tal vez te estás enfrentando a una situación similar aquí.