Słyszałem wiele dobrego o JSF, ale o ile wiem, ludzie mieli również wiele poważnych skarg na tę technologię w przeszłości, nieświadomi tego, jak bardzo sytuacja się poprawiła. Rozważamy JSF jako prawdopodobną technologię dla projektu sieci społecznościowej. Ale nie jesteśmy świadomi wyników JSF ani nie mogliśmy naprawdę natknąć się na żadną istniejącą witrynę o wysokiej wydajności, która korzystałaby z JSF. Ludzie narzekają na problemy ze skalowalnością wydajności.

Nadal nie jesteśmy pewni, czy robimy właściwą rzecz, wybierając jsf, dlatego chcielibyśmy usłyszeć od ciebie wszystko na ten temat i wziąć pod uwagę twoje uwagi.

Czy można skonfigurować JSF tak, aby spełniał wysokie wymagania usługi sieci społecznościowej? Także do jakiego stopnia można przetrwać przy obecnych problemach w JSF. Jakie dokładnie są jego problemy?

Ja nie martwi się o zawiłości rozwoju z JSF, co inni narzekają, bo zazwyczaj jak na moje osobiste doświadczenia uważam, że nie jest to w ogóle prawda, ale jestem bardziej zaniepokojony tym, co kwestie wydajności i skalowalności. I proszę nie nadużywaj go tylko w stosunku do starych problemów związanych z poprzednimi wersjami. Zależy mi tylko na obecnym stanie, niezależnie od jego przeszłości.

JSF zdecydowanie jest w stanie dostarczać aplikacje internetowe o wysokiej wydajności. Aplikacja, nad którą obecnie pracuję, jest całkowicie w JSF i ze statystyk dziennika wynika, że ​​wiele stron nieobsługujących DB ma minimalny czas wykonania wynoszący 0 ms i średni czas krótszy niż 10 ms.

Niektórzy faceci z Wicket mówią coś o wydajności JSF, ale zgodnie z tym skomplikowanym testem porównawczym, JSF faktycznie osiąga lepsze wyniki niż Wicket: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/

Zauważ, że dopóki serwer nie jest nasycony, JSF działa również lepiej niż GWT. Porównanie testu porównawczego GWT / JSF jest jednak trudne, ponieważ naprawdę ważne jest, aby serwer GWT przeprowadzał również konwersję i sprawdzanie poprawności danych w postback, który robi JSF. Jest to coś, czego po prostu nie można pominąć w praktyce (nigdy nie ufać klientowi). Ponadto w przypadku wykresów GWT vs. JSF / Wicket należy wziąć pod uwagę, że etap renderowania przeglądarki jest prosty dla JSF / Wicket (ponieważ w większości obsługują one gotowy do renderowania HTML), ale klient GWT wciąż ma trochę pracy zrobić po otrzymaniu odpowiedzi serwera.

Jednym z głównych problemów z wydajnością / skalowalnością, które występowały w starszych wersjach JSF (wcześniejszych niż 2.0), było nadużywanie funkcji oszczędzania stanu poprzez umieszczanie w nim zbyt dużej ilości danych. Rzeczy, które absolutnie nie powinny być tam, gdzie zostały w nim umieszczone (takie jak stałe takie jak „foo” jak w <my:tag attribute="foo"/>).

JSF 2.0 wprowadził ten partial state savingmechanizm, co oznacza, że ​​zapisywany jest tylko stan delta. W praktyce może to być bardzo mało, a redukcje o dwa rzędy wielkości w porównaniu do JSF 1.x nie są rzadkie.

Po latach używania JSF mogę powiedzieć, że z wyjątkiem zapisywania zbyt dużego stanu w JSF 1.x, nigdy nie napotkałem żadnego problemu z wydajnością, który mógłbym przypisać JSF. Wszelkie problemy z wydajnością, jakie kiedykolwiek mieliśmy, były zawsze zakorzenione w bazie danych i / lub w jaki sposób konfigurowaliśmy usługi zaplecza, pisaliśmy nasze zapytania itp.

Cała teoria na świecie może powiedzieć, że JSF jest wspaniały, ale spójrz tylko, jak wyglądają twoje strony. Tworzy ogromne stosy javascript i inne bzdury, które poważnie utrudniają twoją zdolność dodawania modułów takich jak jQuery lub czyste użycie CSS. Nie mówiąc, że nie da się tego zrobić, ale za jaką cenę.

Osobiste doświadczenie ze stosunkowo małym projektem i średnią złożonością. Katastrofa. To był bałagan związany ze wszystkimi wywołaniami zwrotnymi i nie można łatwo łączyć innych technologii. Mieliśmy ogromny błąd, który okazał się być spowodowany przez użycie JSTL zmieszanego z JSF. Nigdy nie byliśmy w stanie użyć wszystkich rzeczy jQuery, ponieważ KAŻDY link jest wywołaniem zwrotnym javascript.

Uciekaj i uciekaj szybko.

Również, gdy mówisz o skali, o jakiej skali mówisz. Liczba stron, liczba użytkowników, liczba żądań na sekundę, liczba funkcji. Odpowiedzi na te pytania mogą ci pomóc. Również gdy ktoś powie Ci, że trzeba skalować, zapytaj go w jakim stopniu i jak szybko. Odpowiedź bardzo ci pomoże. Jeśli mówisz w skali Google za tydzień lub mówisz o 1000 użytkowników i 10000 odsłon dziennie w ciągu roku.

Prawie każdy framework, poza tym, że wpisujesz odpowiedzi w czasie rzeczywistym w tle, skaluje się do 99,999% przypadków użycia.

Uwaga: Lubię JSF. W każdym razie, nawet przy najnowszej wersji RI (Mojarra 2.2.x) lub MyFaces, nawet przy długo oczekiwanej wydajności bezstanowej jest bardzo słaba. Wynika to z cyklu życia JSF i faktu, że każdy widok jest (kosztownie) budowany dla każdego żądania.

Aby uzyskać wskazówkę, jest to prosty test porównawczy w stosunku do zwykłego serwletu Java w stosunku do strony JSF, które drukują tylko „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)

Jeśli chcesz lepiej zrozumieć, jak działa JSF (zarówno Mojarra 2.1.7, jak i MyFaces 2.1.7) i porównać go z podobną strukturą, taką jak Apache Wicket (zarówno 1.4.20, jak i 1.5.5), spójrz na ten dokładne porównanie (MAJ 2012):

Zrozumienie JSF 2 i Wicket: Porównanie wydajności

Zaletą jest to, że wszystko jest dostępne (kod, dane eksperymentalne, instrukcje dotyczące reprodukcji testu, szczegółowy wyczerpujący raport). Rozwiąże wszystkie pytania dotyczące wydajności JSF, a zobaczysz, co potrafi Apache MyFaces.

Artykuł, który może trochę pomóc (choć nie do końca rozstrzygający) to Server Frameworkic Java Frameworks: Porównanie wydajności w DZone Javalobby:

... W tym artykule opisano, na ile skuteczna jest większość platform sieciowych Java SPI przy częściowych zmianach dostarczonych przez serwer. Nie interesują nas zdarzenia bez komunikacji z serwerem, to znaczy zdarzenia bez (możliwej) kontroli serwera.

Jak będą mierzone

Zamierzamy zmierzyć ilość kodu, który jest wysyłany do klienta w odniesieniu do zmian wizualnych dokonanych w kliencie .

Na przykład w przypadku niewielkiej zmiany wizualnej (niektórych nowych danych) w elemencie nie oczekujemy od serwera zbyt wiele kodu, to znaczy nowy znacznik potrzebny jako zwykły kod HTML lub osadzony w JavaScript lub niektóre instrukcje wysokiego poziomu zawierające nowe dane wizualizowane. W przeciwnym razie wydaje się, że coś jest nie tak, na przykład odbudowuje się cały komponent lub strefę strony, marnując przepustowość i moc klienta (a może i moc serwera).

Ponieważ będziemy korzystać z publicznych demonstracji, nie uzyskamy ostatecznego i dokładnego testu porównawczego . Ale zobaczysz bardzo silne różnice między ramami.

Technika testowania jest bardzo łatwa i każdy może to zrobić bez specjalnej infrastruktury, potrzebujemy tylko FireFox i FireBug. W tym teście zastosowano FireFox 3.6.8 i FireBug 1.5.4.

Konsola FireBug, gdy włączona jest opcja „Pokaż XMLHttpRequests”, rejestruje każde żądanie AJAX pokazujące odpowiedź serwera ...

Testowane ramy

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

... najwyraźniej jedyne wdrożenie JSF wolne od poważnych kar za wydajność to PrimeFaces ...

Nie byłem w stanie znaleźć odpowiedniego porównania (wydajności), jeśli ktoś znajdzie takie, chciałbym je zobaczyć!

Występuje problem z Faceletami, z których IMHO jest dość niewygodnym rozwiązaniem. Jest czterokrotnie bardziej pracochłonny niż w rzeczywistości konieczny i wymaga zbyt dużej pracy ręcznej, gdy tylko zrobisz krok z czegoś prymitywnego. HybridJava byłby dobrym zamiennikiem Facelets jako silnika prezentacji w JSF - wykonuje tę samą pracę (a nawet znacznie więcej, w szczególności - sprawia, że ​​wszystkie „powiązania” i identyfikatory są dla Ciebie) przy znacznie mniejszej liczbie naciśnięć klawiszy.

Chciałem więc wrzucić podobny test porównawczy. Wziąłem przykładową stronę z Twitterem i przekonwertowałem ją na xhtml strict. Następnie ustawiłem dokładnie jedną fasolę CDI ApplicationScoped, która zwróciła Hello, World. Umieściłem wyrażenie EL na stronie. W przypadku wersji JSF korzystałem z modułu obsługi zasobów JSF, w przypadku wersji JSPX użyłem stylu CSS CSS i JS.

Użyłem ławki Apache do przetestowania czasu ładowania strony głównej. Test został przeprowadzony na niezoptymalizowanym serwerze TomEE + v1.5.2. Przebiegłem każdy test 5 razy, a następnie wykonałem pełny GC przed wykonaniem pomiaru. Testy Bost przeprowadzono w tej samej instancji JVM bez ponownego uruchamiania JVM. Mam dostępną APR na libpath, ale nie jestem pewien, czy to wpłynie na ten test.

JSF działa wolniej, ale nie za bardzo, ponieważ mamy do czynienia z bardzo małymi ilościami. To, czego nie pokazano, to bardziej skomplikowane strony, czy JSF / JSPX skaluje się liniowo lub wykładniczo.

Zauważyłem tylko, że JSPX produkuje bardzo mało śmieci w porównaniu do JSF. Uruchomienie testu porównawczego na stronie JSPX spowodowało skok używanej sterty z 184 MB do 237 MB. Uruchomienie testu porównawczego w tej samej maszynie JVM na stronie JSF powoduje przeskok używanej sterty z 108 MB do co najmniej 404 MB, ale w tym momencie uruchomiono automatyczne zbieranie śmieci. Wydaje się, że dostrojenie twojego śmieciarza do JSF jest absolutną koniecznością .

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 konwertuje kod Java na skrypt Java. więc działa jako skrypt Java po stronie klienta. Możesz także zintegrować css ze swoimi aplikacjami gwt. Ogólnie rzecz biorąc, gwt jest lekki i może bez problemu działać we wszystkich przeglądarkach. Nie wiem dużo o JSF. Ale myślę, że dt, JSF nie jest tak elastyczny jak GWT.