He oído muchas cosas buenas sobre JSF, pero que yo sepa, la gente también tuvo muchas quejas graves con esta tecnología en el pasado, sin saber cuánto mejoró la situación. Estamos considerando JSF como una tecnología probable para un proyecto de red social. Pero no conocemos los puntajes de rendimiento de JSF ni realmente podríamos encontrarnos con ningún sitio web de alto rendimiento existente que hubiera estado utilizando JSF. La gente se queja de sus problemas de escalabilidad de rendimiento.
Todavía no estamos muy seguros de si estamos haciendo lo correcto al elegir jsf y, por lo tanto, nos gustaría saber de usted todo esto y tener en cuenta sus aportes.
¿Es posible configurar JSF para satisfacer las necesidades de alto rendimiento del servicio de redes sociales? También hasta qué punto es posible sobrevivir con los problemas actuales en JSF. ¿Cuáles son exactamente sus problemas?
Estoy no estaba preocupado por las complejidades de desarrollo con JSF lo demás por lo general se quejan porque según mi experiencia personal creo que no es del todo cierto, pero estoy más preocupado por lo que los problemas de rendimiento y escalabilidad. Y, por favor, no abuses de sus problemas anteriores vinculados a versiones anteriores. Solo me importa el estado presente, cualquiera que haya sido su pasado.
Respuestas:
JSF es definitivamente capaz de entregar aplicaciones web de alto rendimiento. La aplicación en la que estoy trabajando actualmente está completamente en JSF y de las estadísticas de registro puedo ver que muchas páginas que no son intensivas en DB tienen tiempos de ejecución mínimos de 0 ms y tiempos promedio de menos de 10 ms.
Algunos de los chicos de Wicket han estado diciendo cosas sobre el rendimiento de JSF, pero de acuerdo con este elaborado punto de referencia, JSF realmente funciona mejor que Wicket: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/
Tenga en cuenta que siempre que el servidor no esté saturado, JSF también funciona mejor que GWT. Sin embargo, la comparación de referencia GWT / JSF es difícil, ya que es realmente importante que el servidor para GWT también realice la conversión y validación de datos en la devolución de datos que hace JSF. Esto es algo que simplemente no puede dejar de lado en la práctica (nunca confíe en el cliente). Además, para los gráficos GWT vs JSF / Wicket, se debe tener en cuenta que el paso de representación del navegador es trivial para JSF / Wicket (ya que en su mayoría sirven HTML listo para renderizar), pero el cliente GWT todavía tiene algo de trabajo para hacer después de recibir la respuesta del servidor.
Uno de los principales problemas de rendimiento / escalabilidad que tenían las versiones antiguas de JSF (anteriores a 2.0) era abusar del ahorro de estado al poner demasiados datos en él. Cosas que absolutamente no deberían haber estado allí donde se pusieron en él (como constantes como 'foo' como en
<my:tag attribute="foo"/>).JSF 2.0 introdujo el
partial state savingmecanismo, lo que significa que solo se está guardando el estado delta. En la práctica, esto puede ser muy poco y las reducciones de dos órdenes de magnitud en comparación con JSF 1.x no son infrecuentes.Después de años de usar JSF, puedo decir que, excepto por guardar demasiado estado en JSF 1.x, nunca me he encontrado con ningún problema de rendimiento que pueda atribuir a JSF. Cualquier problema de rendimiento que tuvimos siempre estuvo arraigado en la base de datos y / o en cómo configuramos los servicios de fondo, escribimos nuestras consultas, etc.
fuente
Todos los teóricos del mundo pueden decir que JSF es maravilloso, pero solo eche un vistazo a cómo se ven sus páginas. Produce montones masivos de javascript y otros tipos de basura que perjudicarán severamente su capacidad de agregar módulos como jQuery o el uso limpio de CSS. No digo que no se pueda hacer, pero a qué costo.
Experiencia personal con un proyecto relativamente pequeño y mediana complejidad. Un desastre. Fue un desastre tratar con todas las devoluciones de llamada y no se pueden mezclar fácilmente en otras tecnologías. Tuvimos un gran error que resultó ser causado al usar JSTL mezclado con JSF. Nunca pudimos usar todas las cosas de jQuery debido al hecho de que CADA enlace es una devolución de llamada de JavaScript.
Huye y huye rápido.
También cuando dices escala, de qué tipo de escala estás hablando. Número de páginas, número de usuarios, número de solicitudes por segundo, número de funciones. Las respuestas a estas pueden ayudarlo. Además, cuando alguien le diga que necesita escalar, pregúntele en qué grado y con qué rapidez. La respuesta te ayudará tremendamente. Si estás hablando de Google scale en una semana o estás hablando de 1000 usuarios y 10000 páginas vistas por día en un año.
Casi cualquier marco, salvo que escriba las respuestas en tiempo real en segundo plano, se escalará para satisfacer el 99.999% de los casos de uso.
fuente
Descargo de responsabilidad: me gusta JSF. De todos modos, incluso con el último RI (Mojarra 2.2.x) o MyFaces, incluso con el tan esperado rendimiento de implementación sin estado es muy pobre. Esto se debe al ciclo de vida de JSF y al hecho de que cada vista se crea (costosamente) para cada solicitud.
Para obtener una pista, este es un punto de referencia simple contra un servlet java simple frente a una página JSF, ambos imprimiendo "hello world"
Servlet
JSF
fuente
Si desea comprender más claramente cómo funciona JSF (tanto Mojarra 2.1.7 como MyFaces 2.1.7) y compararlo con un marco similar como Apache Wicket (ambos 1.4.20 y 1.5.5), eche un vistazo a esto comparación profunda (MAYO 2012):
Comprensión de JSF 2 y Wicket: comparación de rendimiento
Lo bueno es que todo está disponible (código, datos experimentales, instrucciones sobre cómo reproducir la prueba, un informe exhaustivo detallado). Resolverá todas sus preguntas sobre el rendimiento de JSF, y verá lo que Apache MyFaces puede hacer.
fuente
Un artículo que podría ayudar un poco (aunque no es realmente concluyente) es Server Centric Java Frameworks: Comparación de rendimiento en DZone Javalobby:
¡No he podido encontrar una comparación adecuada (para el rendimiento), si alguien encuentra una, me encantaría verla!
fuente
En general, hay un problema con Facelets que, en mi humilde opinión, es bastante incómodo de usar. Es cuatro veces más prolijo de lo que realmente es necesario y necesita demasiado trabajo manual una vez que se aleja de algo primitivo. HybridJava sería un buen reemplazo para Facelets como motor de presentación dentro de JSF: hace el mismo trabajo (y mucho más, en particular, hace todos los "enlaces" e identificadores para usted) con muchas menos pulsaciones de teclas.
fuente
Así que quería lanzar un punto de referencia similar. Tomé una página de ejemplo de bootstrap de Twitter y la convertí en estricta xhtml. Después de eso, configuré exactamente un bean CDI ApplicationScoped que devolvió Hello, World. Puse la expresión EL en la página. Para la versión JSF, utilicé el controlador de recursos JSF, para la versión JSPX, utilicé el estilo HTML css y js incluye.
Usé apache bench para probar el tiempo de carga de la página principal. La prueba se realizó en un servidor TomEE + v1.5.2 no optimizado. Ejecuté cada punto de referencia 5x, luego ejecuté un GC completo antes de tomar una medida. Las pruebas de Bost se realizaron en la misma instancia de JVM sin reiniciar la JVM. Tengo el APR disponible en el libpath, pero no estoy seguro de que eso afecte a esta prueba.
JSF es más lento, pero no mucho, ya que estamos tratando con cantidades muy pequeñas. Lo que no se demuestra es que a medida que las páginas se vuelven más complejas, JSF / JSPX se escala de forma lineal o exponencial.
Una cosa que noté es que JSPX produce muy poca basura en comparación con JSF. Ejecutar el punto de referencia en la página JSPX hizo que el montón usado saltara de 184mb a 237mb. Ejecutar el punto de referencia en la misma JVM en la página JSF hace que el montón usado salte de 108mb a al menos 404mb, pero en ese momento se inició una recolección automática de basura. Parecería que ajustar su recolector de basura para JSF es una necesidad absoluta .
JSF
JSPX
fuente
GWT convierte su código java en script java. por lo tanto, se ejecuta como un script Java en el lado del cliente. Y también, puede integrar css en sus aplicaciones gwt. En general, gwt es ligero y puede ejecutarse en todos los navegadores sin ningún problema. No sé mucho sobre JSF. Pero creo que dt, JSF no es tan flexible como GWT.
fuente