Eu ouvi muito bem sobre o JSF, mas até onde eu sei, as pessoas também tiveram muitas queixas sérias com essa tecnologia no passado, sem saber o quanto a situação melhorou. Estamos considerando o JSF como uma tecnologia provável para um projeto de rede social. Mas não temos conhecimento das pontuações de desempenho do JSF nem poderíamos realmente encontrar qualquer site de alto desempenho existente que estivesse usando o JSF. As pessoas reclamam de seus problemas de escalabilidade de desempenho.

Ainda não temos muita certeza se estamos fazendo a coisa certa ao escolher o jsf e, portanto, gostaríamos de ouvir de você tudo sobre isso e levar em consideração suas sugestões.

É possível configurar o JSF para satisfazer as necessidades de alto desempenho do serviço de rede social? Também até que ponto é possível sobreviver com os problemas atuais no JSF. Quais são exatamente os seus problemas?

Eu estou não se preocupava com as complexidades de desenvolvimento com JSF que os outros geralmente se queixam, porque de acordo com a minha experiência pessoal eu acredito que isso não é de todo verdade, mas estou mais preocupado com o que problemas de desempenho e escalabilidade. E, por favor, não abuse apenas de seus problemas antigos vinculados a versões anteriores. Eu só me preocupo com o estado presente, qualquer que tenha sido seu passado.

Definitivamente, o JSF é capaz de fornecer aplicativos da web de alto desempenho. O aplicativo no qual estou trabalhando atualmente é completamente em JSF e, pelas estatísticas de log, vejo que muitas páginas que não fazem uso intensivo de banco de dados têm tempos de execução mínimos de 0ms e tempos médios inferiores a 10ms.

Alguns dos caras do Wicket têm dito coisas sobre o desempenho do JSF, mas, de acordo com essa referência elaborada, o JSF realmente tem um desempenho melhor que o Wicket: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/

Observe que, enquanto o servidor não estiver saturado, o JSF também terá um desempenho melhor que o GWT. A comparação de benchmark GWT / JSF é difícil, pois é realmente importante que o servidor para GWT também faça a conversão e validação de dados no postback que o JSF faz. Isso é algo que você simplesmente não pode deixar de lado na prática (nunca confie no cliente). Além disso, para os gráficos GWT x JSF / Wicket, deve-se levar em consideração que a etapa de renderização do navegador é trivial para JSF / Wicket (já que eles geralmente servem HTML pronto para renderizar), mas o cliente GWT ainda tem algum trabalho a fazer. após receber a resposta do servidor.

Um dos principais problemas de desempenho / escalabilidade que as versões antigas do JSF (anteriores à 2.0) tinham, era abusar da economia de estado, colocando muitos dados nela. Coisas que absolutamente não deveriam estar lá onde colocá-lo (como constantes como 'foo' como em <my:tag attribute="foo"/>).

O JSF 2.0 introduziu o partial state savingmecanismo, o que significa que apenas o estado delta está sendo salvo. Na prática, isso pode ser muito pequeno e reduções de duas ordens de magnitude em comparação com o JSF 1.x não são incomuns.

Depois de anos usando o JSF, posso dizer que, exceto para salvar muito estado no JSF 1.x, nunca encontrei nenhum problema de desempenho que pudesse atribuir ao JSF. Quaisquer problemas de desempenho que já tivemos foram sempre enraizados no banco de dados e / ou na forma como configuramos serviços de back-end, escrevemos nossas consultas etc.

Todas as teorias do mundo podem dizer que o JSF é maravilhoso, mas veja como são as suas páginas. Ele produz pilhas maciças de javascript e outras porcarias que prejudicam gravemente sua capacidade de adicionar módulos como jQuery ou uso limpo de CSS. Não estou dizendo que não pode ser feito, mas a que custo.

Experiência pessoal com um projeto relativamente pequeno e de média complexidade. Um desastre. Foi uma bagunça lidar com todos os retornos de chamada e você não pode misturar outras tecnologias facilmente. Tivemos um bug enorme que acabou sendo causado ao usar o JSTL misturado ao JSF. Nunca fomos capazes de usar todo o material do jQuery devido ao fato de que TODO link é um retorno de chamada em javascript.

Fuja e fuja rápido.

Além disso, quando você diz escala, de que tipo de escala você está falando? Número de páginas, número de usuários, número de solicitações por segundo, número de recursos. As respostas para estas podem ajudá-lo. Além disso, quando alguém lhe disser que precisa ser dimensionado, pergunte-lhe em que grau e com que rapidez. A resposta irá ajudá-lo tremendamente. Se você estiver falando da escala do Google em uma semana ou estiver falando de 1000 usuários e 10000 visualizações de página por dia em um ano.

Quase todas as estruturas, com exceção de você digitar respostas em tempo real em segundo plano, serão dimensionadas para atender a 99,999% dos casos de uso.

Disclaimer: Eu gosto do JSF. De qualquer forma, mesmo com o RI mais recente (Mojarra 2.2.x) ou MyFaces, mesmo com o tão esperado desempenho de implementação sem estado , é muito ruim. Isso ocorre devido ao ciclo de vida do JSF e ao fato de que cada View é (dispendiosamente) criada para cada solicitação.

Para obter uma pista, essa é uma referência simples entre um servlet java simples e uma página JSF, ambos apenas imprimindo "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)

Se você quiser entender mais claramente o desempenho do JSF (tanto o Mojarra 2.1.7 quanto o MyFaces 2.1.7) e compará-lo com uma estrutura semelhante como o Apache Wicket (1.4.20 e 1.5.5), dê uma olhada neste comparação profunda (MAIO 2012):

Noções básicas sobre JSF 2 e Wicket: comparação de desempenho

A parte boa é que tudo está disponível (código, dados experimentais, instruções sobre como reproduzir o teste, um relatório detalhado e exaustivo). Ele resolverá todas as suas perguntas sobre o desempenho do JSF e você verá o que o Apache MyFaces é capaz de fazer.

Um artigo que pode ajudar um pouco (embora não seja realmente conclusivo) é o Java Frameworks Centrado em Servidor: Comparação de Desempenho no DZone Javalobby:

... Este artigo analisa a eficácia da maioria das estruturas da Web Java SPI em alterações parciais fornecidas pelo servidor. Não estamos interessados ​​em eventos sem comunicação com o servidor, ou seja, eventos sem controle (possível) do servidor.

Como eles serão medidos

Vamos medir a quantidade de código que é enviada ao cliente em relação à alteração visual realizada no cliente .

Por exemplo, para uma pequena alteração visual (alguns novos dados) em um componente, esperamos que não haja muito código do servidor, ou seja, a nova marcação necessária como HTML simples ou incorporada no JavaScript, ou algumas instruções de alto nível que contenham os novos dados. visualizado. Caso contrário, algo parece errado, por exemplo, o componente completo ou a zona da página é reconstruída, desperdiçando largura de banda e energia do cliente (e talvez energia do servidor).

Como usaremos demonstrações públicas, não obteremos uma referência definitiva e refinada . Mas você verá diferenças muito fortes entre estruturas.

A técnica de teste é muito fácil e todo mundo pode fazê-lo sem infraestrutura especial, precisamos apenas do FireFox e FireBug. Neste teste, o FireFox 3.6.8 e o FireBug 1.5.4 são usados.

O console do FireBug quando "Mostrar XMLHttpRequests" está ativado registra qualquer solicitação AJAX mostrando a resposta do servidor ...

Frameworks testados

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

... aparentemente a única implementação do JSF livre de penalidades graves de desempenho é o PrimeFaces ...

Não consegui encontrar uma comparação adequada (para desempenho), se alguém encontrar uma que eu adoraria ver!

Existe um problema com o Facelets em geral que IMHO é uma coisa bastante inconveniente de se usar. É quatro vezes mais prolixo do que realmente necessário e precisa de muito trabalho manual depois que você dá um passo em algo primitivo. O HybridJava seria um bom substituto para o Facelets como mecanismo de apresentação no JSF - ele faz o mesmo trabalho (e muito mais, em particular - ele cria todos os "vínculos" e identificações para você) com muito menos pressionamentos de tecla.

Então, eu queria colocar uma referência semelhante. Peguei uma página de exemplo de bootstrap do twitter e a converti em xhtml strict. Depois disso, configurei exatamente um bean CDI do ApplicationScoped que retornou Olá, Mundo. Eu coloquei a expressão EL na página. Para a versão JSF, usei o manipulador de recursos JSF, para a versão JSPX, usei o estilo HTML css e js includes.

Eu usei o banco apache para testar o tempo de carregamento da página principal. O teste foi realizado em um servidor TomEE + v1.5.2 não otimizado. Executei cada benchmark 5x e, em seguida, executei um GC completo antes de fazer uma medição. Os testes Bost foram realizados na mesma instância da JVM sem reiniciar a JVM. Eu tenho o APR disponível no libpath, mas não tenho certeza se isso afeta esse teste.

O JSF é mais lento, mas não muito, pois estamos lidando com quantidades muito pequenas. O que não é demonstrado é que, à medida que as páginas ficam mais complexas, o JSF / JSPX é dimensionado linear ou exponencialmente.

Uma coisa que notei é que o JSPX produz muito pouco lixo comparado ao JSF. A execução do benchmark na página JSPX fez com que o heap usado pulasse de 184mb para 237mb. A execução do benchmark na mesma JVM na página JSF faz com que o heap usado pule de 108mb para pelo menos 404mb, mas uma coleta de lixo automática é ativada nesse ponto. Parece que o ajuste do seu coletor de lixo para JSF é uma necessidade 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)

O GWT converte seu código java em script java. portanto, ele é executado como um script java no lado do cliente. E também, você pode integrar o css em seus aplicativos gwt. Em geral, o gwt é leve e pode ser executado em todos os navegadores sem nenhum problema. Eu não sei muito sobre JSF. Mas acho que o JSF não é tão flexível quanto o GWT.