JSF Tuning

Question

Se está produciendo un problema donde JSF está llenando nuestras sesiones. Tuvimos un bloqueo del sistema el otro día. Envié el Heap a IBM para su revisión y descubrí que teníamos algunas sesiones tan grandes como 50M. Encontraron componentes JSF en la sesión y algunos muy grandes.

Entonces, ¿hay algún ajuste que se pueda hacer? Elementos de configuración a mirar? O en otra dirección.

Nuestro sistema se construye usando JSF y Spring para la capa de presentación, el back-end es EJB, Spring e Hibernate, todos se ejecutan en WebSphere 6.1.

Answer 1

JSF es una tecnología útil, pero sin duda puede ahorcarse con ella.

Parece que, o bien está inflando el tamaño del estado de la vista (estableciendo valores grandes en los componentes) o está filtrando las referencias a los componentes en otro estado de sesión (lo que sería malo). Otro posible culpable sería una visión excesivamente grande (he visto la facilidad con la que las personas pueden construir árboles de IU conducen a gráficos de control muy grandes con tablas de datos en todas partes). Sé que IBM proporciona controles de texto enriquecido y hojas de cálculo. No puedo comentar el efecto que tendrá el uso de estos en el tamaño del estado.

La fruta que cuelga más bajo es comprobar los beans gestionados configurados para el alcance de la sesión en faces-config.xml.

JSF ahorra dos cosas entre solicitudes:

• la vista (todos los controles de la página)
• el estado de vista (el estado de los controles)

Estos están separadas porque algunos controles, como los hijos de una tabla de datos, pueden tener múltiples estados (uno para cada fila). El estado se puede guardar en un campo oculto en el formulario (que, si no está encriptado, puede ser un gran peligro para la seguridad) o en la sesión. Para acomodar múltiples ventanas del navegador que comparten la misma sesión (y, en algunas implementaciones, compatibilidad con el botón de retroceso), se almacenan varias vistas.

• Debe haber una opción de configuración para establecer el número de estados de vista que la aplicación mantendrá en la sesión para un usuario dado en un momento dado.
• Puede medir el tamaño del estado de la vista proporcionando StateManager que mide el tamaño de la vista/estado guardado (configure un StateManager en faces-config.xml con un constructor público que toma un StateManager; consulte los archivos PDF JSF spec para obtener más información; el estado es serializable y puede verificar su tamaño volcándolo en una secuencia).

La mayoría de las aplicaciones JSF construidas con IDE tienen respaldos. Sería posible, a través del alcance del bean Session, aferrarse al estado más tiempo de lo que desee, lo que supondría una carga para la sesión. Dado que tiende a haber un bean de respaldo por página, cuantas más páginas tenga, mayor será el problema. Verifique faces-config.xml para ver si esta es una posible fuente de problemas.

Otra cosa que podría hacer sería configurar un HttpSessionAttributeListener en su web.xml. Puede obtener un stack trace para ayudar a identificar áreas problemáticas en su aplicación.

Answer 2

Este es el segundo sistema que he escuchado que ha muerto debido a JSF y la creación excesiva de objetos. El otro también usó Spring e Hibernate en el back-end. La creación de perfiles con OptimizeIt mostró que la respuesta del servidor era del orden de milisegundos para todas las solicitudes, pero podía cronometrar el tiempo de ejecución del navegador con el cronómetro porque tardaba tanto tiempo, desde 30 segundos hasta varios minutos. La memoria consumida por el cliente era ridícula.

Solo fui un observador, no un miembro de ese equipo de proyecto. Tendré que preguntar si alguna vez se solucionó el problema y, de ser así, cuál podría haber sido la solución.

Pero si dos puntos hacen una tendencia, diría que JSF podría ser fatalmente defectuoso. Personalmente, me mantengo alejado de esto por completo.

¿Por qué no probar un front-end web de Spring y ver si eso ayuda? Si sigues la expresión Spring, debería ser una cuestión relativamente simple reemplazar JSF con JSP basados ​​en JSTL y controladores Spring.

Answer 3

Estaba trabajando en un proyecto JSF y descubrí que teníamos un error en el que estábamos agregando elementos JSF h: form. Como resultado, se incluye una copia del viewstate completo con cada formulario. Al reducir a 1 formulario por página, se redujeron las páginas de ~ 2M a ~ 300K.

Answer 4

Es posible que tenga problemas con muchos beans de respaldo como ámbito de sesión.

Puede probar buscando en MyFaces Orchestra. Esta es una biblioteca que proporciona un ámbito de conversación, por lo que una vez que un usuario ha terminado con un conjunto particular de beans, se eliminarán de la sesión.

Entiendo que Spring WebFlow tiene características similares, ¡pero realmente no lo he investigado!

Answer 5

JSF almacena las vistas en sesión para admitir su rica arquitectura basada en componentes (necesita mantener su estado de vista) y puede llenar el montón si no se usa correctamente. Si no tiene grandes flujos de trabajo, siempre vaya con un pequeño número de visitas por sesión. También evite mantener a los backingbeans en sesión tanto como sea posible. Use una etiqueta personalizada para hacer el objeto de datos solo para el siguiente ciclo de solicitud. También podemos usar Spring Web Flow con JSF, que presenta el alcance de la vista y el alcance del flujo si tenemos flujos de trabajo largos en la aplicación para reducir el número de vistas configuradas en la sesión. JSF se puede utilizar para hacer que la interfaz de usuario sea sencilla y fácil, lo que ayuda a crear Webapplication similar a la aplicación de escritorio. Asigne un montón específico al marco JSF para hacer su trabajo. Pero use la memoria de manera eficiente en el lado de la aplicación y asegúrese de que no haya pérdida de memoria. Todas las filtraciones de memoria deben ser investigadas y corregidas durante el desarrollo mismo. Aways usa un generador de perfiles para encontrar fugas de memoria y cuellos de botella de rendimiento que existen en la aplicación.

Mat.

Answer 6

Si está utilizando MyFaces < 1.1.6 hay una gran pérdida de memoria en la forma en que almacena en caché viejas vistas serializadas en la sesión de forma efectiva y nunca las libera para que puedan ser recolectadas. Tuve un problema serio con eso y también tuve sesiones de 50Mb. Una actualización rápida de MyFaces rectificó el problema sin ningún problema.

Answer 7

Configure session persistense en la base de datos, y usará el algoritmo menos utilizado para sacar de la memoria las sesiones menos usadas. Tiene un alto rendimiento (cuando está configurado correctamente) y lo ayudará de manera concreta y rápida.

Answer 8

Un tema viejo, pero lo encontré recientemente. A menudo, el Estado de Vista y Vista se almacena (como se mencionó anteriormente) y completa la sesión para permitir que el botón Atrás funcione. Hay parámetros para ordenar esto en los descriptores de implementación (web.xml) que deben configurarse.

Varias instancias de ciertas bibliotecas pueden necesitar más de una configuración de parámetro, como cuando se usan MyFaces y JSF RI. De forma predeterminada, se pueden establecer en algunos valores bastante altos (20 y 16, creo, respectivamente). Esto significa que puede usar 20 veces el espacio que debería tener para (¿partes de?) La sesión.

Answer 9

sugerencias de ajuste JSF para entornos de producción:
- El uso de imágenes, CSS y recursos de JavaScript debe ser realizado por etiquetas HTML estándar (img,link,script) no del lado del servidor, y asegúrese de ajustar #{request.contextPath} antes de la URL para evitar rutas relativas cuestiones.
- Cache secciones estáticas de la página utilizando (menu,header,footer)omnifaces cache
- Ajuste variable de refresh-period a -1
- fijan a project-stage Producción
- Revisar los filtros de código en su caso

Además, revise mi artículo "Java Server Faces in Real-Life Applications" en la DZone, le dará una idea completa sobre JSF en entornos de desarrollo, prueba y producción.