JSF Tuning

Question

Se ejecuta en un problema donde JSF se está llenando nuestras sesiones.Hemos tenido un bloqueo del sistema, el otro día.Envía el Montón de IBM para la revisión y encontraron que hemos tenido algunas sesiones tan grande como el de los 50M.Encontraron componentes JSF en la sesión y algunos muy grandes.

Así, hay ningún tipo de ajuste que se puede hacer?Elementos de configuración para mirar?U otra dirección.

Nuestro sistema de construcción es el uso de JSF y Spring para la capa de presentación, la parte final es EJB, Spring y Hibernate todos los que se ejecutan en WebSphere 6.1.

Answer 1

JSF es una tecnología útil, pero ciertamente puedes ahorcarte con ella.

Parece que está inflando el tamaño del estado de vista (al establecer valores grandes en los componentes) o está filtrando referencias a componentes en otro estado de sesión (lo que sería malo). Otro posible culpable sería una vista excesivamente grande (he visto que la facilidad con 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 qué efecto tendrá el uso de estos en el tamaño del estado.

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

JSF guarda 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 separados 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 se encripta, 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 Atrás), se almacenan varias vistas.

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

La mayoría de las aplicaciones JSF creadas por IDE tienen beans de respaldo. Sería posible, a través del alcance del bean de sesión, mantener el estado durante más tiempo del que desea, ejerciendo presión sobre la sesión. Como suele haber un bean de respaldo por página, cuantas más páginas tenga, mayor será el problema. Verifique su faces-config.xml para ver si esta es una fuente potencial de problemas.

Algo más 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 oído hablar de que ha muerto a causa de JSF y excesivo de la creación de objetos.El otro también se utiliza Spring y Hibernate. en la parte final.Perfiles con OptimizeIt mostró que el backend de respuesta fue del orden de milisegundos para todas las solicitudes, pero se podía tiempo de la representación del navegador de nuevo con cronómetro porque tomó tanto tiempo - 30 segundos hasta varios minutos.Memoria consumida por el cliente era ridículo.

Yo era sólo un observador, no un miembro de ese equipo de proyecto.Voy a tener que preguntar si el problema era siempre fijo y, si es así, ¿cuál es la solución que podría haber sido.

Pero si hay dos puntos que hacen que una tendencia, yo diría que JSF podría ser errónea.Personalmente, creo que se mantenga alejado de ella por completo.

Por qué no probar una Primavera de front-end web y ver si eso ayuda?Si usted sigue la Primavera lenguaje, debe ser una cuestión relativamente sencilla de sustitución de JSF con JSTL basado en la Jsp y la Primavera de los controladores.

Answer 3

Estaba trabajando en un proyecto JSF y descubrí que teníamos un error al agregar múltiples elementos JSF h: form. Como resultado, se incluye una copia de todo el estado de vista con cada formulario. Reducir a 1 formulario por página afeitó 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 intentar buscar en MyFaces Orchestra . Esta es una biblioteca que proporciona un alcance de conversación, por lo que una vez que un usuario haya 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, vaya siempre con un pequeño número de vistas por sesión. También evite mantener los beans de respaldo en la sesión tanto como sea posible. Use una etiqueta personalizada para crear el objeto de datos solo para el siguiente ciclo de solicitud. También podemos usar Spring Web Flow con JSF, que introduce el alcance de la vista y el alcance del flujo si tenemos largos flujos de trabajo en la aplicación para reducir el no de vistas configuradas en la sesión. JSF se puede utilizar para crear fácilmente una interfaz de usuario enriquecida, lo que ayuda a construir una aplicación Weba similar a la aplicación de escritorio. Asigne un montón específico al marco JSF para hacer su trabajo. Pero use la memoria eficientemente en el lado de la aplicación y asegúrese de que no haya pérdidas de memoria. Todas las pérdidas de memoria deben investigarse y corregirse durante el desarrollo mismo. Utilice siempre un generador de perfiles para encontrar pérdidas 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é las vistas serializadas antiguas en la sesión, de manera efectiva, nunca dejándolas liberar para que puedan ser recolectadas. Tuve un problema grave 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 la persistencia de sesión en la base de datos, y utilizará el algoritmo menos utilizado para expulsar las sesiones menos utilizadas de la memoria. Tiene un alto rendimiento (cuando está configurado correctamente) y lo ayudará de manera concreta y rápida.

Answer 8

Un poco de un viejo tema, pero me encontré con esto recientemente. A menudo, la vista y el estado de la vista se almacenan (como se mencionó anteriormente) y llena la sesión para permitir que el botón de retroceso funcione. Hay parámetros para ordenar esto en los descriptores de implementación (web.xml) que deben establecerse.

Varias instancias de ciertas bibliotecas pueden necesitar más de una configuración de parámetros, como cuando se usan MyFaces y JSF RI. Por defecto, se pueden establecer en algunos valores bastante altos (20 y 16, respectivamente). Esto significa que puede usar 20 veces el espacio que debería estar (¿partes de?) En la sesión.

Answer 9

Consejos de ajuste JSF para el entorno de producción:
 - El uso de imágenes, CSS y recursos de JavaScript debe realizarse mediante etiquetas HTML estándar (img,link,script) no del lado del servidor, y asegúrese de configurar #{request.contextPath} antes de la URL para evitar problemas de rutas relativas.
 - Caché de secciones estáticas de la página (menu,header,footer) usando omnifaces cache
 - Establezca refresh-period variable en -1
 - establezca project-stage en Producción
 - Revise sus filtros de código, si los hay

Además, consulte mi artículo " Servidor Java Caras en aplicaciones de la vida real & Quot; en DZone, le dará una visión completa de JSF en entornos de desarrollo, prueba y producción.