Problema di prestazioni iniziali con LINQ alle entità quando si utilizzano TPH e tipi complessi, le viste Pregen sembrano non fare nulla?

Question

Sto utilizzando MVC3, ASP.NET 4.5, LINQ su entità, EF5 e SQL Server 2008 R2 e Azure (per live).

Sto creando file csdl, edml, msl e ssdl per il modello in un progetto modello separato.

Questi file sono prodotti dallo sviluppatore Entity di Devart, dove gestisco il mio modello di entità.

Obiettivo: Entity Framework 5

• pigro Caricamento: Abilitato
• Guarda Generation: La vera
• convalida sulla costruzione: Vero
• Metadati Artefatto Processing: Incorpora in Assemblea uscita
• ObjectContext è utilizzato
• Creazione Proxy ObjectContext Abilitata: true.

Ho implementato l'ereditarietà TPH nel mio modello entità, per cui la classe figlio è composta anche da fino a 10 tipi complessi (CTn).

Animal<-Cat(CT1,CT2,CT3 etc) (for example) 

Ogni tipo complesso esegue il mapping alla colonna nella tabella animale generica.

mio LINQ iniziale è:

if (db.Animal.OfType<Cat>().Any(a => a.OwnerId == myOwnerId)) 

Quando questo viene eseguito per la prima volta, si può prendere circa 40 secondi per completare. Le corse successive durano circa 200ms.

Quando analizzo questo ulteriore usando un ORM Profiler, mi dà il codice LINQ come:

Cat.MergeAs(0).Any(a => a.OwnerId == ((Nullable<int>)myOwnerId)) 

ho scoperto una domanda meravigliosa SO: Related SO Question, ma non va abbastanza in profondità. Mentre raccomanda un aggiornamento a EF6, non menziona il nuovo problema di EF6 di dover JIT il runtime EF al primo utilizzo a causa del fatto che è ora esterno al runtime .NET. Forse in una versione successiva di EF6 cioè 6.1.2 questo è risolto.

Una volta che il T-SQL è stato creato da EF, funziona a pieno ritmo molto rapidamente. Ho provato questo in SSMS.

Quindi la mia domanda, a partire da novembre 2014, è composta da:

1) Come posso risolvere i ritardi iniziali di carico per il mio TPH/scenario di tipo complesso, avendo Visualizzazioni pregenerato provato. Ho visto riferimenti a "Compiled Queries".

2) Forse dovrei passare a EF6? Tuttavia, se lo faccio, ora c'è una penalità JIT per il runtime EF stesso, e come dovrei risolvere questo. Mi occupo di siti Web di Azure.

3) Infine ho notato che altre query più dirette hanno beneficiato delle visualizzazioni pregenerate, quindi le sto utilizzando. È solo per questo scenerario di tipo TPH/Complex che non ha impatto. Ci sono situazioni in cui le visualizzazioni pregen non hanno alcun impatto?

4) Potrebbe essere dovuto al tempo necessario per "compilare automaticamente una query" che EF5 può ora eseguire. Avendo pregenerato la vista, immagino che questo sia il prossimo collo di bottiglia. Forse questa funzione di "autocompilare" per entità complesse come la mia richiede molto tempo, quindi si può fare una compilazione manuale proattiva? Questo è ciò che si chiama "CompiledQuery". È importante scrivere questo codice in più o EF6x mi può aiutare qui? Ho il forte sospetto che questa fase di compilazione delle query sia il collo di bottiglia, ma comprendiamo anche che scrivere query compilate non è necessariamente la soluzione più semplice e manutenibile. Al momento abbiamo un lavoro di avvio periodico che scalda solo tutte queste entità complesse, quindi l'utente passa direttamente alla "modalità di esecuzione query calda".

Qualsiasi aiuto con quanto sopra sarebbe molto apprezzato.

EDIT1

ho appena usato Profilo dotTrace di JetBrains che va molto più in profondità, e sembra confermare che il mio collo di bottiglia sta accadendo con:

System.Data.Query.PlanCompiler.PreProcessor.Process(Dictionary[EdmFunctionEdmProperty[]]&) 

Al primo colpo, si spende il 99% del tempo qui, che conferma il mio punto di vista sul fatto che fosse qualcosa a che fare con la generazione del Query Plan. Come risolvo questo problema è un'altra questione.

EDIT2

ho intenzione di testare su EF 6.1.2 dopo qualche buon consiglio e aver seguito eccellente corso di Julie Lerman su Pluralsight.

Answer 1

Ho avuto un problema simile e ho provato diversi approcci per migliorare le prestazioni di "primo successo".

Avete pensato di implementare IProcessHostPreloadClient per pre-riscaldare la cache e effettuare una chiamata iniziale, tramite il modello di Entity Framework, al database?

Questa soluzione ha funzionato per me e ho creato una classe PreWarmCache esempio riportato di seguito:

namespace MyNamespace 
{ 
    public class PreWarmCache : IProcessHostPreloadClient 
    { 
     private static readonly NLog.Logger Logger = NLog.LogManager.GetCurrentClassLogger(); 
     private readonly SystemRepository _systemRepository = new SystemRepository(); 

     public void Preload(string[] parameters) 
     { 
      // Perform initialization and cache loading logic 
      Logger.Debug("Application Started: {0}", _systemRepository.InitAppliation() ? "DB response OK" : "DB response failed"); 
     } 
    } 
} 

Partenza this blog per i dettagli su come collegare questo fino al vostro fornitore di avvio automatico su IIS.