L'avvio di Grails è lento

Question

Aiuto! Sto trasferendo una grossa app rubino a Grails - ma l'avvio di Grails della mia applicazione richiede più di 2 minuti.

Ho già impostato dbCreate per "leggere". Mi sono assicurato che il mio desktop windows dual processor di fascia alta dia la necessaria RAM (1 Gig). Non ho installato plugin. Ho 170 classi di dominio che prima erano classi ruby.

All'avvio stampa la riga "Running Grails App .." e si blocca per un lungo periodo prima di stampare la riga "Server in esecuzione".

Ho appena fatto qualcosa dove ho migrato tutti i miei id in bigints. Questo sembra aver peggiorato il problema. Ora ci vogliono circa 10 minuti per l'avvio.

Sono nuovo di Grail, potresti fornirmi qualche altro dettaglio su cosa e dove registrare gli eventi all'avvio? Per quanto riguarda la profilazione del vm, sono passati alcuni anni da quando ho fatto un sacco di Java. Cosa consiglia come il miglior strumento di profilazione da utilizzare adesso?

Che altro posso fare per velocizzare l'avvio di Grails?

Answer 1

Sfortunatamente, non sono sicuro che si possa fare troppo oltre a quello che hai già fatto. Come saprai, all'avvio si verificano molte cose, con tutte le risoluzioni/i caricamenti dei plugin, l'aggiunta di metodi dinamici agli oggetti del dominio e la natura dinamica complessiva di Groovy.

Non sono sicuro di quale versione si sta utilizzando, ma ho chiesto la possibilità di disattivare il controllo delle dipendenze all'avvio in 1.2, poiché ciò aggiunge un po 'di tempo all'avvio.

Mi rendo conto che sopra non è troppo utile, quindi forse questo sarà: ho diviso la mia applicazione in diversi plugin. Uno per gli oggetti dominio, uno per la capacità di creazione di grafici, uno per l'importazione excel, l'altro per alcuni costrutti dell'interfaccia utente di cui avevo bisogno. Non l'ho fatto solo a causa dei tempi di avvio lenti, ma il vantaggio è che posso testare parti del sistema separatamente l'una dall'altra prima di integrare tutto.

Sto per aggiungere una nuova funzionalità che coinvolge almeno 10 nuovi oggetti di dominio e per prima cosa li sviluppo in un plug-in separato con stub per i pochi oggetti con cui devono interagire dall'app principale. Ciò mi consente sia di ridurre i tempi di avvio sia di isolare meglio il mio codice.

Quindi, se è un'opzione per te, prova a separare le cose in modo da poterle lavorare separatamente, il che allevia un po 'il problema. Ci possono essere anche altri vantaggi in termini di avere il tuo team di lavoro su componenti più piccoli separatamente, una migliore modularizzazione, ecc.

Spero che questo sia utile.

Answer 2

Si potrebbe voler vedere se ci sono altre manopole che si possono girare diverse da Grails per risolvere il problema.

Hai provato ad avvicinarti a questo problema di prestazioni? Puoi dare un'occhiata alle prestazioni della scatola e cercare di scoprire qual è il collo di bottiglia. È CPU? È un problema di lettura del disco? Puoi collegare un profiler alla VM e scoprire che cosa sta consumando gran parte del tuo tempo di avvio?

Answer 3

170 classi di dominio è abbastanza grande, ma 2 minuti mi sembrano ancora molto lunghi. Hai un sacco di plugin installati? Impostazioni di debug potenzialmente troppo prolisse?

Sarei curioso di sapere quanto tempo è occorso se hai creato un'app di Grails fresca, copiata in tutti gli oggetti di dominio (e il sottoinsieme di plug-in che gli oggetti di dominio potrebbero dover effettivamente operare) e vedere quanto ci vuole iniziare.

Il suggerimento di Jean di separare le cose, se possibile, è buono. Ho fatto qualcosa di simile su progetti precedenti in cui abbiamo un plug-in di dominio e tutte le nostre altre app si basano su quel plug-in di dominio.

È anche possibile utilizzare grails events per registrare alcune informazioni di temporizzazione all'avvio per vedere dove sono i colli di bottiglia. Cronometrare l'evento "PluginInstalled" dovrebbe essere buono in quanto penso che il plugin di ibernazione sarebbe catturato da questo in aggiunta agli altri plugin.

Answer 4

Potrebbe essersi verificato un problema di dipendenza. Se un plugin che usi si basa su una libreria di Maven con dipendenze "aperte", Grails andrà ad apparire ogni volta se ci sono versioni più recenti da scaricare nell'intervallo. Non ho idea del perché qualcuno lo specifichi in questo modo. Sembra che porti a comportamenti inaffidabili. Per me, il colpevole è la libreria java aws di Amazon, naturalmente utilizzata da un plugin che parla con il cloud di Amazon.

http://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk/1.2.10

notare come alcune delle sue dipendenze sono come questo

org.apache.httpcomponents HttpClient [4.1, 5.0)

sembra che ogni volta, graal è alla ricerca di una nuova versione (e scaricando se esiste, ho appena notato che 4.2-alpha1 di httpclient viene giù quando ho eseguito questa volta).

Rimuovendo che la dipendenza dal plugin e aggiungere manualmente le librerie necessarie alla mia cartella lib, ho ridotto il mio tempo di avvio da> 30 secondi a 1 sec <

Answer 5

Hai provato fondamentali come questi per l'ulteriore distribuzione in un servlet contenitore di vostra scelta o bootwrap sul posto .war?

grails -Ddisable.auto.recompile=true run-app 

grails run-war 

grails war