Entity Framework è troppo lento. Quali sono le mie opzioni? [chiuso]

Ho seguito il mantra "Non ottimizzare prematuramente" e ho codificato il mio servizio WCF utilizzando Entity Framework.

Tuttavia, ho profilato le prestazioni e Entity Framework è troppo lento. (La mia app elabora 2 messaggi in circa 1,2 secondi, mentre l'app (legacy) che sto riscrivendo invia 5-6 messaggi nello stesso tempo (l'app legacy chiama sprocs per il suo DB Access).

La mia profilazione punta a Entity Framework che impiega la maggior parte del tempo per messaggio.

Allora, quali sono le mie opzioni?

• Ci sono ORM migliori là fuori?
  (Qualcosa che supporta solo la normale lettura e scrittura di oggetti e lo fa velocemente ..)

• C'è un modo per rendere più veloce Entity Framework?
  ( Nota : quando dico più veloce intendo a lungo termine, non la prima chiamata. (La prima chiamata è lenta (15 secondi per un messaggio), ma non è un problema. Ho solo bisogno che sia veloce per il resto dei messaggi.)

• Qualche misteriosa terza opzione che mi aiuterà a ottenere più velocità dal mio servizio.

NOTA: la maggior parte delle interazioni con il database sono create e aggiornate. Faccio pochissimo selezionando ed eliminando.

Dovresti iniziare profilando i comandi SQL effettivamente emessi da Entity Framework. A seconda della configurazione (POCO, entità Self-Tracking) c'è molto spazio per le ottimizzazioni. È possibile eseguire il debug dei comandi SQL (che non dovrebbe differire tra la modalità di debug e quella di rilascio) utilizzando il ObjectSet<T>.ToTraceString()metodo. Se incontri una query che richiede un'ulteriore ottimizzazione, puoi utilizzare alcune proiezioni per fornire a EF ulteriori informazioni su ciò che stai cercando di realizzare.

Esempio:

Product product = db.Products.SingleOrDefault(p => p.Id == 10);
// executes SELECT * FROM Products WHERE Id = 10

ProductDto dto = new ProductDto();
foreach (Category category in product.Categories)
// executes SELECT * FROM Categories WHERE ProductId = 10
{
    dto.Categories.Add(new CategoryDto { Name = category.Name });
}

Potrebbe essere sostituito con:

var query = from p in db.Products
            where p.Id == 10
            select new
            {
                p.Name,
                Categories = from c in p.Categories select c.Name
            };
ProductDto dto = new ProductDto();
foreach (var categoryName in query.Single().Categories)
// Executes SELECT p.Id, c.Name FROM Products as p, Categories as c WHERE p.Id = 10 AND p.Id = c.ProductId
{
    dto.Categories.Add(new CategoryDto { Name = categoryName });
}

L'ho appena digitato dalla mia testa, quindi non è esattamente come verrebbe eseguito, ma EF in realtà fa delle belle ottimizzazioni se gli dici tutto quello che sai sulla query (in questo caso, che avremo bisogno della categoria- nomi). Ma questo non è come il caricamento ansioso (db.Products.Include ("Categories")) perché le proiezioni possono ridurre ulteriormente la quantità di dati da caricare.

Il nocciolo della questione è che prodotti come Entity Framework saranno SEMPRE lenti e inefficienti, perché eseguono molto più codice.

Trovo anche sciocco che le persone suggeriscano di ottimizzare le query LINQ, guardare l'SQL generato, utilizzare debugger, precompilare, eseguire molti passaggi aggiuntivi, ecc. Cioè perdere molto tempo. Nessuno dice: Semplifica! Tutti vogliono complicare ulteriormente le cose facendo ancora più passi (perdere tempo).

Un approccio di buon senso sarebbe quello di non usare affatto EF o LINQ. Usa un semplice SQL. Non c'è niente di sbagliato in questo. Solo perché c'è una mentalità da branco tra i programmatori e sentono il bisogno di usare ogni singolo nuovo prodotto là fuori, non significa che sia buono o funzionerà. La maggior parte dei programmatori pensa che se incorporano ogni nuovo pezzo di codice rilasciato da una grande azienda, ciò li rende un programmatore più intelligente; non è affatto vero. La programmazione intelligente riguarda principalmente come fare di più con meno mal di testa, incertezze e nel minor tempo possibile. Ricorda: tempo! Questo è l'elemento più importante, quindi cerca di trovare modi per non sprecarlo risolvendo problemi in codice cattivo / gonfio scritto semplicemente per conformarsi a alcuni strani cosiddetti "schemi"

Rilassati, goditi la vita, prenditi una pausa dalla programmazione e smetti di usare funzionalità, codici, prodotti e "schemi" extra. La vita è breve e la vita del tuo codice è ancora più breve, e certamente non è scienza missilistica. Rimuovi livelli come LINQ, EF e altri e il tuo codice verrà eseguito in modo efficiente, scalerà e sì, sarà ancora facile da mantenere. Troppa astrazione è un cattivo "schema".

E questa è la soluzione al tuo problema.

Un suggerimento è usare LINQ to Entity Framework solo per istruzioni CRUD a record singolo.

Per query, ricerche, rapporti e così via più complessi, scrivi una stored procedure e aggiungila al modello Entity Framework come descritto su MSDN .

Questo è l'approccio che ho adottato con un paio dei miei siti e sembra essere un buon compromesso tra produttività e prestazioni. Entity Framework non genererà sempre l'SQL più efficiente per l'attività in questione. E invece di spendere il tempo per capire perché, scrivere una stored procedure per le query più complesse in realtà mi fa risparmiare tempo. Una volta acquisita familiarità con il processo, non è una seccatura aggiungere processi archiviati al modello EF. E ovviamente il vantaggio di aggiungerlo al tuo modello è che ottieni tutta quella bontà fortemente tipizzata che deriva dall'uso di un ORM.

Se stai semplicemente recuperando dati, è di grande aiuto per le prestazioni quando dici a EF di non tenere traccia delle entità che recupera. A tale scopo, utilizza MergeOption.NoTracking. EF genererà semplicemente la query, la eseguirà e deserializzerà i risultati negli oggetti, ma non tenterà di tenere traccia delle modifiche di entità o di qualsiasi altra cosa di quella natura. Se una query è semplice (non passa molto tempo ad aspettare che il database ritorni), ho scoperto che impostarla su NoTracking può raddoppiare le prestazioni della query.

Vedi questo articolo MSDN sull'enumerazione MergeOption:

Risoluzione dell'identità, gestione dello stato e rilevamento delle modifiche

Questo sembra essere un buon articolo sulle prestazioni EF:

Prestazioni e Entity Framework

Dici di aver profilato l'applicazione. Hai profilato anche tu l'ORM? C'è un profiler EF di Ayende che evidenzierà dove puoi ottimizzare il tuo codice EF. Potete trovare qui:

http://efprof.com/

Ricorda che puoi utilizzare un approccio SQL tradizionale insieme al tuo ORM se hai bisogno di migliorare le prestazioni.

Se esiste un ORM più veloce / migliore? A seconda del modello oggetto / dati, potresti prendere in considerazione l'utilizzo di uno dei micro-ORM, come Dapper , Massive o PetaPoco .

Il sito Dapper pubblica alcuni benchmark comparativi che ti daranno un'idea di come si confrontano con altri ORM. Ma vale la pena notare che i micro-ORM non supportano il ricco set di funzionalità degli ORM completi come EF e NH.

Potresti voler dare un'occhiata a RavenDB . Si tratta di un database non relazionale (di nuovo da Ayende) che consente di archiviare i POCO direttamente senza la mappatura necessaria . RavenDB è ottimizzato per le letture e semplifica notevolmente la vita degli sviluppatori eliminando la necessità di manipolare lo schema e di mappare i tuoi oggetti su quello schema. Tuttavia, tieni presente che questo è un approccio significativamente diverso rispetto all'utilizzo di un approccio ORM e questi sono descritti nel sito del prodotto .

Ho trovato la risposta di @Slauma qui molto utile per velocizzare le cose. Ho usato lo stesso tipo di pattern sia per gli inserti che per gli aggiornamenti e le prestazioni sono aumentate alle stelle.

Dalla mia esperienza, il problema non con EF, ma con ORM si avvicina a se stesso.

In generale, tutti gli ORM soffrono di problemi N + 1, query non ottimizzate e così via. La mia ipotesi migliore sarebbe quella di rintracciare le query che causano un degrado delle prestazioni e provare a mettere a punto lo strumento ORM o riscrivere quelle parti con SPROC.

Questa è una semplice opzione non-framework, non-ORM che carica a 10.000 / secondo con circa 30 campi. Funziona su un vecchio laptop, quindi probabilmente più veloce di quello in un ambiente reale.

https://sourceforge.net/projects/dopersistence/?source=directory

Mi sono imbattuto anche in questo problema. Odio scaricare su EF perché funziona così bene, ma è solo lento. Nella maggior parte dei casi voglio solo trovare un record o aggiornare / inserire. Anche semplici operazioni come questa sono lente. Ho recuperato 1100 record da una tabella in un elenco e l'operazione ha richiesto 6 secondi con EF. Per me questo è troppo lungo, anche il risparmio richiede troppo tempo.

Ho finito per creare il mio ORM. Ho estratto gli stessi 1100 record da un database e il mio ORM ha impiegato 2 secondi, molto più velocemente di EF. Tutto con il mio ORM è quasi istantaneo. L'unica limitazione al momento è che funziona solo con MS SQL Server, ma potrebbe essere modificato per funzionare con altri come Oracle. Uso MS SQL Server per tutto adesso.

Se vuoi provare il mio ORM ecco il link e il sito web:

https://github.com/jdemeuse1204/OR-M-Data-Entities

O se vuoi usare nugget:

PM> Install-Package OR-M_DataEntities

Anche la documentazione è disponibile

Ha senso solo ottimizzare dopo aver profilato. Se scopri che l'accesso al DB è lento, puoi convertirlo in stored procedure e mantenere EF. Se scopri che è l'EF stesso a essere lento, potresti dover passare a un ORM diverso o non utilizzare affatto un ORM.

Abbiamo un'applicazione simile (Wcf -> EF -> database) che esegue facilmente 120 richieste al secondo, quindi sono più che sicuro che EF non è il tuo problema qui, detto questo, ho visto importanti miglioramenti delle prestazioni con le query compilate.

Ho usato EF, LINQ to SQL e dapper. Dapper è il più veloce. Esempio: avevo bisogno di 1000 record principali con 4 record secondari ciascuno. Ho usato LINQ per sql, ci sono voluti circa 6 secondi. Sono quindi passato a dapper, ho recuperato 2 set di record dalla singola procedura memorizzata e per ogni record ho aggiunto i sub record. Tempo totale 1 secondo.

Anche la procedura memorizzata utilizzava funzioni di valore di tabella con applicazione incrociata, ho trovato che le funzioni di valore scalare erano molto lente.

Il mio consiglio è di usare EF o LINQ to SQL e per determinate situazioni passare a dapper.

Entity Framework non dovrebbe causare gravi colli di bottiglia. È probabile che ci siano altre cause. Potresti provare a passare da EF a Linq2SQL, entrambi hanno funzionalità di confronto e il codice dovrebbe essere facile da convertire, ma in molti casi Linq2SQL è più veloce di EF.