2013-07-31 25 views
7

Stiamo utilizzando Grails 2.2.4, WebSphere 8.0.0.5 tutti in esecuzione su AIX 6.1.0.0. Websphere sta usando il JDK IBM:Ricarica GSP dinamico lento in produzione su AIX

Java (TM) SE Runtime Environment (build pap6460_26sr3ifix-20121005_02 (SR3 + IV27268 + IV27928 + IV28217 + IV25699))

IBM J9 VM (build 2.6, JRE 1.6 0,0 AIX ppc64-64 20120919_122629 (JIT abilitato, AOT abilitato)

j9vm - R26_Java626_SR3_iFix_1_20120919_1316_B122629

JIT - r11.b01_20120808_24925ifx1

GC - R26_Java626_SR3_ iFix_1_20120919_1316_B122629 J9CL - 20120919_122629)

JCL - 20120713_01

Il problema è che l'utilizzo:

grails.gsp.enable.reload = true 
grails.gsp.view.dir="/path/to/gsp/views" 

è lento, e con questo intendo un buon 20 secondi per rendere un piccolo GSP. Ciò che è interessante è che nei nostri ambienti di sviluppo locali ci vogliono 2 secondi.

Abbiamo isolato questo problema avendo un controller che non fa nulla tranne chiamare il rendering (..) su un GSP vuoto con nulla nel modello, quindi posso solo supporre che sia la compilation ma potrei sbagliarmi.

Qualcuno si è imbattuto in altri casi in cui il rendering degli SPG è estremamente lento o ha qualche suggerimento, forse è una sorta di strano problema JDK su AIX?

Oltre alla taglia, chi risponde correttamente ottiene i waffle gratuiti.

EDIT appena notato l'altro giorno: ci sono tre ambienti con lo stesso è stato di configurazione e la configurazione e uno di loro funziona bene, quindi è sicuramente una sorta di problema dell'ambiente.

+0

Potrebbe cercare di fare un test gg/path/to/GSP/vista? – JavaDev

+0

Quando si dice ambiente di sviluppo locale, è l'ambiente WAS locale o Tomcat incorporato in Grails? – dmahapatro

+0

Ho il sospetto che tu abbia già guardato l'angolo della memoria, ma mi sono imbattuto in casi simili di oddball sotto pressione di memoria. Una discussione lunga e probabilmente pertinente qui: http://grails.1312388.n4.nabble.com/Grails-performance-restriction-td4642061.html In particolare, la risposta di Graeme il 5 marzo 2013; 5:48 am –

risposta

1

Sono d'accordo con il vostro sospetto che sia il momento della compilazione. Forse grails.gsp.view.dir è lento - forse un file system in rete?

La vera risposta, sfortunatamente, è quella di non abilitare il caricamento del GSP in produzione. È chiaramente inteso come una comodità di sviluppo e non è destinato a funzionare bene in produzione.

+0

Purtroppo non abbiamo scelta dal momento che il requisito è quello di consentire alle persone di cambiarlo al volo. –

+1

Sembra che tu abbia bisogno di un CMS – GreyBeardedGeek

+0

Puoi provare a eseguire la stessa ricarica abilitata, ma usa solo tomcat? Sto indovinando che è stato collegato il problema – JavaDev

0

Stiamo avendo lo stesso problema sulla nostra applicazione che ha cercato di rendere un rapporto Birt a pagina Gsp (ci vuole del tempo 5 minuti su un server prod, Abbiamo usato Tomcat e MySQL), non rispondere, ma un suggerimento che potrebbe aver bisogno di usa il plugin cache di Grails, che ha una capacità di cache gsp pagine in base alle tue esigenze.

grails.org/plugin/cache‎

+0

In realtà stiamo già usando questo –

1

Assicurarsi SiteMesh viene pre-elaborato

grails.views.gsp.sitemesh.preprocess=true 

Inoltre ho il sospetto che questo sia il blocco problema piuttosto che la compilazione problema.

Per almeno ridurre questo problema impostare le seguenti configurazioni

qualcosa di alto a seconda del comfort. Forse ogni ora?

Se il file sta cambiando la data dell'ultima modifica troppo rapidamente è necessario abbassare il livello di dettaglio da

grails.gsp.reload.granularity= Time in milliseconds. 

limitare il numero di classi di essere ricaricato da

grails.reload.excludes 

e

grails.reload.includes 

Ricorda inoltre che il percorso della vista DEVE terminare con una barra. Non l'ho visto nell'esempio che hai fornito.

1

Mentre non riesco a dirti quale sia la causa del tuo problema, posso indicarti uno strumento che potrebbe aiutarti a esaminare il problema delle prestazioni.

Il plugin Grails Miniprofiler è un fantastico strumento per esaminare le prestazioni end to end, fino alla vista (che è dove credete che il vostro problema sia).

Su alcuni SPG su un mio progetto, sono rimasto sorpreso di vedere quanto pesassero alcune visualizzazioni rispetto alle chiamate SQL (tramite il caricamento lazy).

Potresti avere dei sospetti su dove si trovano i problemi, e forse stai colpendo un bug oscuro su quella piattaforma specifica, ma avere numeri difficili da indicare su colli di bottiglia è estremamente utile.

Per quello che vale, non ho visto il problema che hai descritto in nessuno dei miei OS/ambienti. Ma ricordo di aver provato un dolore serio con il tentativo di implementare JBoss 6.1 (da quando è stato risolto), quindi sono sensibile all'idea che Grails potrebbe avere problemi in alcuni ambienti.

Buona fortuna ...

Grails Miniprofiler plugin