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.

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.

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.

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

glassfish-3.1.2.2$ ab -n 10000 -c 100 http://localhost:8080/mavenproject-web/NewServlet

Server Software:        GlassFish
Server Hostname:        localhost
Server Port:            8080

Document Path:          /mavenproject-web/NewServlet
Document Length:        128 bytes

Concurrency Level:      100
Time taken for tests:   0.970 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      4300000 bytes
HTML transferred:       1280000 bytes
Requests per second:    10307.02 [#/sec] (mean)
Time per request:       9.702 [ms] (mean)
Time per request:       0.097 [ms] (mean, across all concurrent requests)
Transfer rate:          4328.14 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.0      1       5
Processing:     1    9   4.6      8      51
Waiting:        1    8   4.4      7      40
Total:          4   10   4.1      8      51

Percentage of the requests served within a certain time (ms)
  50%      8
  66%     10
  75%     11
  80%     11
  90%     12
  95%     14
  98%     29
  99%     33
 100%     51 (longest request)

JSF

glassfish-3.1.2.2$ ab -n 10000 -c 100 http://localhost:8080/mavenproject-web/xhtml/test/jsf.xhtml

Server Software:        GlassFish
Server Hostname:        localhost
Server Port:            8080

Document Path:          /mavenproject-web/xhtml/test/jsfxhtml
Document Length:        100 bytes

Concurrency Level:      100
Time taken for tests:   4.676 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      4250000 bytes
HTML transferred:       1000000 bytes
Requests per second:    2138.60 [#/sec] (mean)
Time per request:       46.759 [ms] (mean)
Time per request:       0.468 [ms] (mean, across all concurrent requests)
Transfer rate:          887.60 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       6
Processing:     5   46   6.0     46      73
Waiting:        2   45   5.5     45      72
Total:          8   47   5.8     46      73

Percentage of the requests served within a certain time (ms)
  50%     46
  66%     48
  75%     50
  80%     51
  90%     54
  95%     56
  98%     60
  99%     62
 100%     73 (longest request)

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.

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:

... Este artículo revisa la efectividad de la mayoría de los frameworks web SPI Java en los cambios parciales proporcionados por el servidor. No estamos interesados ​​en eventos sin comunicación del servidor, es decir, eventos sin control (posible) del servidor.

Cómo se van a medir

Vamos a medir la cantidad de código que se envía al cliente con respecto al cambio visual realizado en el cliente .

Por ejemplo, para un cambio visual menor (algunos datos nuevos) en un componente, esperamos que no haya mucho código del servidor, es decir, el nuevo marcado necesario como HTML simple, o incrustado en JavaScript, o algunas instrucciones de alto nivel que contengan los nuevos datos. visualizado. De lo contrario, algo parece incorrecto, por ejemplo, se reconstruye el componente completo o la zona de página, desperdiciando ancho de banda y energía del cliente (y tal vez la energía del servidor).

Debido a que utilizaremos demostraciones públicas, no vamos a obtener un punto de referencia definitivo y de grano fino . Pero verá diferencias muy fuertes entre los marcos.

La técnica de prueba es muy fácil y todos pueden hacerlo sin una infraestructura especial, solo necesitamos FireFox y FireBug. En esta prueba se utilizan FireFox 3.6.8 y FireBug 1.5.4.

La consola FireBug cuando "Show XMLHttpRequests" está habilitado registra cualquier solicitud AJAX que muestre la respuesta del servidor ...

Marcos probados

RichFaces , IceFaces , MyFaces / Trinidad , OpenFaces , PrimeFaces , Vaadin , ZK , ItsNat

... aparentemente la única implementación de JSF libre de serias penalizaciones de rendimiento es PrimeFaces ...

¡No he podido encontrar una comparación adecuada (para el rendimiento), si alguien encuentra una, me encantaría verla!

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.

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

jonfisher@peanut:~$ /usr/local/bin/ab -n 10000 -c 100 http://localhost:8080/cdi-jsp/index.jsf
This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /cdi-jsp/index.jsf
Document Length:        2904 bytes

Concurrency Level:      100
Time taken for tests:   2.138 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      32160000 bytes
HTML transferred:       29040000 bytes
Requests per second:    4677.27 [#/sec] (mean)
Time per request:       21.380 [ms] (mean)
Time per request:       0.214 [ms] (mean, across all concurrent requests)
Transfer rate:          14689.55 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.3      1      21
Processing:     1   20   9.0     18      63
Waiting:        1   19   8.8     17      62
Total:          2   21   8.8     20      64

Percentage of the requests served within a certain time (ms)
  50%     20
  66%     23
  75%     25
  80%     27
  90%     32
  95%     39
  98%     46
  99%     50
 100%     64 (longest request)

JSPX

jonfisher@peanut:~$ /usr/local/bin/ab -n 10000 -c 100 http://localhost:8080/cdi-jsp/page2.jspx
This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /cdi-jsp/page2.jspx
Document Length:        2440 bytes

Concurrency Level:      100
Time taken for tests:   1.273 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      26290000 bytes
HTML transferred:       24400000 bytes
Requests per second:    7856.63 [#/sec] (mean)
Time per request:       12.728 [ms] (mean)
Time per request:       0.127 [ms] (mean, across all concurrent requests)
Transfer rate:          20170.98 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    5   2.3      6      20
Processing:     1    8   4.6      6      40
Waiting:        1    8   4.3      6      40
Total:          2   13   3.8     12      41

Percentage of the requests served within a certain time (ms)
  50%     12
  66%     12
  75%     13
  80%     13
  90%     17
  95%     20
  98%     24
  99%     28
 100%     41 (longest request)

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.