131 messaggi dal 06 giugno 2011
Buonasera, in questi giorni vi sto tartassando di domande ( lo so che mi odiate già), da premettere che ho già affrontato questo problema , effettuando ricerche,prove, forum msdn, ma non sono riuscito a risolvere.(view pregenerate, ngen)

Premetto che sto facendo i test in una macchina abbastanza veloce (ssd,16gb ram i7overclock) quindi su una macchina di un cliente i tempi possono solo aumentare.

Arrivo subito al dunque, il problema è il classico startup di ef(so che perde del tempo per generarsi le view e quantaltro), perde secondo me troppo tempo (nella mia macchina circa 30 secondi). Quindi il cliente quando apre la mia applicazione deve aspettare 30+ secondi, ovviamente c'è una splashcreen con un barprogress infinite, prima di accedere al menu e alla dashboard, utilizzo sql server, ef 6.1.3 code first, le migrazioni manuali, wpf mvvm.
Il db è composta da circa 330 tabelle tra cui 60/70 entita con relazione uno a molti.

Aggiungo il link di SednaContex(per capire la struttura del mio db):
https://drive.google.com/open?id=0B0IzbkNqehmaZXl0T213Q1IwaVE

Quando avvio la mia applicazione io effettuo un controllo del modello per vedere se ci sono stati cambiamenti, in tal caso di eseguire la migrazione.


La maggior parte del tempo lo perde proprio li...piu dopo faccio una query fittizia (cold query) per far in modo che quando l'utente (finalmente) entra non avra qualla sensazioni di freeze quando fara la prima query.

**************Compatible******************
 var sednaContext = new SednaContext(dbHelper.CreateConnectionString(Ditta, ditte?.DirectoryDitta));
            var compatibleWithModel = sednaContext.Database.CompatibleWithModel(true);
            if (!compatibleWithModel)
            {
                var result = RunMigrations();
            }
*******Fine Compatible: 14987ms***

**************ColdQuery******************
var   datiDitta = datiDittaRepository.Prendi(string.Empty);//coldquery

********Fine Cold Query: 13748ms******


Come si puo vedere in questo esempio ho aggiunto il tempo che ci sta per eseguire, soltanto queste due operazioni circa 28 secondi + altri secondi per caricare il menu e la mainview, ma sono pochi secondi quindi non è importante.

Ora volevo capire se c'è qualcosa di sbagliato nella mia implementazione, se ci sono altri metodi, o implementazioni per poter risolvere il problema, perchè penso che ci sono in giro software fatti con ef e sopratutto molto piu grandi di questo... spero che qualcuno possa aiutarmi perchèe questo problema c'è lho da molto tempo ma l'ho ignorato, ma adesso è diventato di primaria importanza


EDIT:
ho creato un programma console per rendere megli olidea dove mi stampa a video il tempo che ci vuole per confrontare il modello e per la cold query

https://drive.google.com/open?id=0B0IzbkNqehmaX1dUN3ZWWEJTMHM
Modificato da brux88 il 25 maggio 2016 18.07 -




Vi aggiorno con alcune prove (senza risultato):

Ho provato anche con ngen vi posto lo screenshot dove si vede il risultato, le creazioni di tutte le dll con ngen, e tramite windows process la verifica che utilizza le immagini native, ma il risultato non è cambiato:


https://drive.google.com/open?id=0B0IzbkNqehmaMkRsXzYyc25RRHc

Per quanto riguarda le pre generate view con vs 2015 non me li fa f are perche mi da un errore di compilazione di un path troppo lungo, ho letto che con il nuovo compilatore rosylin c'è questa limitazione ma non so....
Modificato da brux88 il 26 maggio 2016 10.21 -
497 messaggi dal 08 febbraio 2009
Difficile trovare una soluzione che vada bene per tutti.

Primo, ho abolito il controllo del database.
In pratica lo lascio al software di installazione. Quando migro dalla versione A alla versione B, l'installer sa quali aggiornamenti fare al DB e li esegue.
Questo evita di farmi controllare il DB tutti gli avvii quando non ce n'è bisogno.
E' stato un po' difficile metterlo in pratica (quando rilasciamo una nuova versione dobbiamo curare anche lo script di migrazione) ma lato esecuzione ha velocizzato di un buon 30% i tempi di avvio

Secondo, come detto in un altro post, abbiamo usato un fork di EF che consente di salvare il mapping del database su file.
In questo modo al primo avvio ci mette un attimino di più (deve memorizzare il mapping su disco), però dal secondo in avanti fa molto prima.

Essendo un fork non è rilasciato in via ufficiale, potrebbe non funzionare e soprattutto non usa tutte le funzionalità più recenti di EF.
Nel nostro caso va bene, però non so se vada bene per tutti o meno.
131 messaggi dal 06 giugno 2011
Grazie, anchio avevo pensato di gestirlo dal programma che si occupa della aggiornamento, per quanto riguarda il mapping E possibile provarlo ?
11.886 messaggi dal 09 febbraio 2002
Contributi
@JoeRuspante
Ti riferisci a questo, giusto? E' il primo punto indicato qui:
https://www.fusonic.net/en/blog/3-steps-for-fast-entityframework-6.1-code-first-startup-performance/

In pratica, la lentezza è causata dal fatto che nell'approccio code-first non c'è un edmx già pronto che descrive la mappatura che esiste tra il modello relazionale e quello ad oggetti, e perciò EF deve costruirlo.

Infatti, brux, ho provato il tuo esempio e la maggior parte del tempo EF la spende nel costruire il modello. Vedi immagine:
https://onedrive.live.com/redir?resid=2B0F0F6D27852B8E!16707&authkey=!AA7HdTk7Nrnvjg8&v=3&ithint=photo%2cpng

Il pregenerare le view o usare ngen ti dà benefici marginali, in questo caso. Il numero di righe nelle tabelle è ininfluente a questo riguardo.

Per il momento fai bene a mostrare lo splashscreen, ma qui devi prendere una decisione più importante per riuscire a risolvere la cosa definitivamente. Ormai sei arrivato ad avere un DbContext con ben 275 DbSet al suo interno. L'hai lasciato crescere, devi comprendere che la tua situazione attuale è questa:
http://i.telegraph.co.uk/multimedia/archive/02487/overbalanced-truck_2487086k.jpg
Non te la caverai semplicemente toccando qualche parametro di configurazione.

EF è certamente adatto per applicazioni "grandi" e sarebbe stato ancor più d'aiuto se avesse supportato la soluzione del caching del modello di cui parlava JoeRuspante, ma quello serve solo a curare i sintomi.
Il problema di fondo è che il modello non è stato frazionato in insiemi più piccoli, come per esempio facciamo nella vita "reale" dividendo un appartamento in stanze o una biblioteca in settori.

Un'architettura idonea ad affrontare la sfida di una "grande" applicazione, è quella di cui parla Julie Lerman in questa sessione:
https://www.youtube.com/watch?v=rGA_FNew-6g
C'è anche un articolo qui:
https://msdn.microsoft.com/en-us/magazine/jj883952.aspx?f=255&MSPPError=-2147217396
A questo punto, che vuoi fare? Prendi il torno per le corna e ti metti a partizionare, oppure vai ad usare il fork di EF? Oppure semplicemente ignori la cosa e mantieni lo splashscreen?
Modificato da BrightSoul il 31 maggio 2016 20.56 -

Enjoy learning and just keep making
131 messaggi dal 06 giugno 2011
bhe grazie per i link, darò un occhiata il prima possibile ,hai reso benissimo l'ideo sopratutto con il camione XD,comunque è una scelta difficile perchè potrebbe aumentare ancora, io vorrei provare il fork per evitare di rimodellare tutto il mio context, e in caso se non ho miglioramenti significativi, mi sa che dovrò ripartizionare il mio context, non so in che modo ancora ( spero che appena vedo il video ho l'idea piu chiara di come poterlo fare), invece per il fork qualche suggerimento, cosa dovrei fare?
Modificato da brux88 il 01 giugno 2016 10.11 -
497 messaggi dal 08 febbraio 2009
Premesso che la soluzione che indicavo è quella riportata da BrightSoul, per eseguire il Fork dovresti:

- Scaricare la branch di EF da questo link (spero sia l'ultima versione): https://github.com/davidroth/Entityframework6/tree/DbModelStore

- Compilare sulla tua macchina il progetto

- Nel progetto che accede al DB devi usare la DLL creata al punto precedente anzichè quella che normalmente viene scaricata da NuGet
131 messaggi dal 06 giugno 2011
devo sostituire solo la dll EntityFramework.dll?
497 messaggi dal 08 febbraio 2009
No, purtroppo no.

Devi prima di tutto usare la DLL ottenuta compilando il fork di EntityFramework di cui abbiamo parlato.

Poi nel tuo DbContext devi implementare i metodi così come sono riportati nel post che ha segnalato BrightSoul

Fatto questo dovresti essere a posto.

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.