performance - Slow Dynamic GSP Recarga en producción en AIX
grails compilation (5)
Estamos utilizando Grails 2.2.4, WebSphere 8.0.0.5 todos corriendo en AIX 6.1.0.0. Websphere está utilizando el IBM JDK:
Java (TM) SE Runtime Environment (compilación pap6460_26sr3ifix-20121005_02 (SR3 + IV27268 + IV27928 + IV28217 + IV25699))
IBM J9 VM (compilación 2.6, JRE 1.6.0 AIX ppc64-64 20120919_122629 (JIT habilitado, AOT habilitado)
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
El problema es que usar:
grails.gsp.enable.reload = true
grails.gsp.view.dir="/path/to/gsp/views"
es lento, y con eso quiero decir unos buenos 20 segundos para renderizar un pequeño SGP. Lo interesante es que en nuestros entornos de desarrollo local demora 2 segundos.
Hemos aislado este problema al tener un controlador que no hace nada más que invocar render (..) en un GSP en blanco sin nada en el modelo, por lo que solo puedo suponer que es la compilación, pero podría estar equivocado.
¿Alguien ha encontrado otras instancias donde renderizar GSPs es extremadamente lento, o tiene alguna sugerencia, tal vez es algún tipo de extraño problema de JDK en AIX?
Además de la recompensa, quien conteste esto correctamente obtiene gofres gratis.
EDIT Acaba de darse cuenta de esto el otro día: hay tres entornos con la misma configuración y configuración WAS y uno de ellos funciona bien, por lo que definitivamente es algún tipo de problema de entorno.
Estoy de acuerdo con tu sospecha de que es tiempo de compilación. Tal vez you grails.gsp.view.dir es lento, ¿quizás un sistema de archivos en red?
La respuesta real, lamentablemente, es no habilitar la recarga de GSP en la producción. Está claro que es una conveniencia de desarrollo y no tiene la intención de funcionar bien en producción.
Estamos teniendo el mismo problema en nuestra aplicación que intentó generar un informe Birt en la página Gsp (tarda unas 5 veces en el servidor de prod, utilizamos Tomcat y Mysql), no responde, pero hay una sugerencia de que podría necesitar usar el caché Grails plugin, que tiene la capacidad de almacenar en caché las páginas gsp en función de sus necesidades.
Asegúrese de que sitemesh esté siendo preprocesado
grails.views.gsp.sitemesh.preprocess=true
También sospecho que esto es un problema de bloqueo en lugar de compilar un problema.
Para al menos reducir este problema, establezca las siguientes configuraciones
grails.gsp.reload.interval= time in milliseconds.
algo alto dependiendo de tu comodidad. Quizás cada hora?
Si su archivo está cambiando la última hora modificada demasiado rápido, debe reducir la granularidad
grails.gsp.reload.granularity= Time in milliseconds.
Limite la cantidad de clases que se recargan
grails.reload.excludes
y
grails.reload.includes
Recuerde también que la ruta de vista DEBE terminar en barra inclinada. No vi eso en el ejemplo que proporcionaste.
Aunque no puedo decirte cuál es la causa de tu problema, puedo señalarte una herramienta que podría ayudarte a analizar el problema del rendimiento.
El complemento Grails Miniprofiler es una herramienta fantástica para examinar el rendimiento extremo a extremo, hasta llegar a la vista (que es donde crees que es tu problema).
En algunos GSP en un proyecto mío, me sorprendió ver cuán pesados eran algunos puntos de vista con respecto a las llamadas SQL (a través de la carga diferida).
Puede tener sospechas de dónde residen los problemas, y tal vez está atacando un error oscuro en esa plataforma específica, pero tener números difíciles para apuntar a cuellos de botella es extremadamente útil.
Por lo que vale, no he visto el problema que ha descrito en ninguno de mis SO / entornos. Pero recuerdo haber experimentado un gran dolor al intentar implementarlo en JBoss 6.1 (ya que lo resolví), por lo que soy sensible a la idea de que Grails podría tener problemas en algunos entornos.
La mejor de las suertes...
Resultó que el problema era http://grails.org/plugin/grails-melody . ¡Quien sabe!