Czy JSF naprawdę jest gotowy do dostarczania aplikacji internetowych o wysokiej wydajności? [Zamknięte]

16

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.

aklin81
źródło
7
ptrthomas.wordpress.com/2009/05/15/jsf-sucks Wiem, że odpowiedź nadeszła od głównego architekta JSF, który uzasadnia każdą decyzję, ale dla mnie ktoś, kto zna niektóre technologie sieciowe i cierpiał, nawet z JSF 2.0, Facelets i SEAM, to kpina. Nawet James Gosling mówi: „Nienawidzę JSF z pasją”. Chciałbym użyć Wicket lub Tapestry i całkowicie uniknąć JSF i jego problemów.
Falcon
12
@ ThorbjørnRavnAndersen Nie zgadzam się z tobą delikatnie. Myślę, że lepiej jest podać więcej wyjaśnień niż tylko powiedzieć: „Nienawidzę JSF”
Chiron
6
@ ThorbjørnRavnAndersen Rozumiem twój punkt widzenia, ale naprawdę zachęcam ludzi do podania dodatkowych informacji. Na przykład denerwujące głosowanie bez komentarza zawsze mnie denerwuje.
Chiron,
3
@Chiron, pytanie nie brzmi, czy JSF jest użyteczny, czy nie, ale czy JSF można wykonać. Ludzie, którzy zaczynają od odłożenia ram, najprawdopodobniej nie mogą odpowiedzieć na rzeczywiste pytanie. Chciałbym też wiedzieć, czy sam mam aplikację JSF.
3
> Nawet James Gosling powiedział: „Nienawidzę JSF z pasją”. - Dobrze wiadomo, że to był błąd, ponieważ chciał powiedzieć JSP. Posłuchaj uważnie tego fragmentu. Chodzi o to, co zostało stworzone w odpowiedzi na klasyczną ASP, a było to JSP, a nie JSF.
Arjan Tijms

Odpowiedzi:

24

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.

Arjan Tijms
źródło
1
0 ms ... Myślę, że twoje środki pomiaru wymagają spojrzenia.
gbjbaanb 30.09.13
2
@gbjbaanb Nie sądzę, pochodzą one ze statystyk, które były dość profesjonalnie skonfigurowane. Zauważ, że mówię o minimalnym czasie i o stronach nieobsługujących DB . Strony wykonujące się w tym czasie oczywiście nie miały na sobie 1000 komponentów rozłożonych na 100, w tym. Mówimy tutaj o stosunkowo prostych stronach, może 10 komponentach, 1 szablon główny, może 1 dołączony, na serwerze, który działa od jakiegoś czasu, więc wszystko jest gorące i zapamiętuje. Średni czas jest wyższy (10 ms, jak wspomniałem) i także o 90% wyższy. Max może być wszystkim.
Arjan Tijms
Sytuacja jest taka, że ​​ten świat krytykuje tylko te rzeczy, które są w stanie rozwiązać wszystkie problemy. Ale rozwiązanie wszystkich problemów zawsze ma swoją cenę i wymaga wielkiego zapału i entuzjazmu. W zespołach widziałem, że zaczynają się rozwijać, nawet nie rozumiejąc cyklu życia. Obejmuje stromą krzywą uczenia się, ale jest piękna i niezwykła.
Shirgill Farhan,
Wąskie gardło jest bardziej prawdopodobne w bazie danych / IO i przepustowości (mobilne ...) niż sam serwer. Java jest naprawdę szybka, jeśli jest dobrze używana.
Christophe Roussy,
8

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.

Bill Leeper
źródło
3
-1 dla dowolnej skali ramowej. To tak, jakby powiedzieć „nie przejmuj się wydajnością”.
Raynos,
3
Sama publikowana platforma internetowa będzie skalowana, w tym JSF. Wszyscy mówią, że tak, gdyby nie, byłby to dość gówniany schemat. To powiedziawszy, wiele osób robi z tym głupie rzeczy i zwykle tam pojawiają się problemy ze skalowaniem.
Bill Leeper
1
to prawda, ale niektóre frameworki zachęcają do robienia rzeczy z utrudnianiem skalowania, albo dlatego, że frameworki to zachęcają, albo sprzyja społeczności. Twierdziłbym, że te ramy nie skalują się.
Raynos,
Bit „jak mierzyć skalowanie” może być komentarzem do pytania?
4

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)
gpilotino
źródło
1
Nie sądzę, że prosta strona helloworld może być reprezentatywna lub znacząca. Poważne porównanie musi zawierać niezbędne informacje, takie jak numery wersji, zastosowana konfiguracja itd. Przeczytaj porównanie JSF i Wicket w poprzedniej odpowiedzi.
lu4242
Pozwól mi się nie zgodzić. Naprawdę uważam, że w najprostszym bezstanowym kontekście jsf jest 5 razy wolniejszy niż jsp. Sprawdzanie, czy w bardziej złożonych scenariuszach wydajność jsf jest najgorsza, jest banalne. Albo mogę podać więcej testów porównawczych dla najbardziej leniwych :-) jsf implementacja to mojarra 2.2, jak wspomniano powyżej, z glassfish 3
gpilotino
„... jsf jest 5 razy wolniejszy niż jsp ...” Myślę, że błąd tutaj nie bierze pod uwagę przepustowości i leżącego u podstaw zachowania jsp vs jsf. Jest to zbyt skomplikowane do wyjaśnienia, ale w tym przypadku czas odpowiedzi jest oczywiście wolniejszy, ponieważ jsf ma efekt współbieżności, którego nie ma jsp. Ale na koniec dokładniejsze jest porównywanie cykli na sekundę. Ponadto Mojarra nie jest tym samym co MyFaces, więc obie implementacje mają różne liczby z punktu widzenia wydajności. Uwaga: w tym przypadku efekt współbieżności jest przesadzony.
lu4242
W rzeczywistości absurdem jest porównywanie zwykłego serwletu z JSF. Jedyne sensowne porównanie to „aplikacja” wykonana za pomocą JSP / serwletów w porównaniu z inną „aplikacją”, która robi dokładnie to samo za pomocą JSF. Dlaczego? ponieważ JSF zapewnia wbudowane rozwiązania do renderowania / ajax / navigation / validation, rzeczy, które należy zrobić od zera lub ręcznie w JSP. Nawet jeśli porównanie jest interesujące z punktu widzenia wydajności (żaden framework nie będzie szybszy niż servlet / jsp), JSP nie pasuje do JSF, ponieważ nie robi nawet najmniejszej części tego, co JSF robi dla ciebie.
lu4242
„porównywanie zwykłego serwletu z JSF jest całkowicie absurdalne”. nie, nie jest. obie technologie mają dostarczać treści. dlatego biorę pod uwagę konteksty bezstanowe, w których walidacja i inne rzeczy po prostu się nie liczą. „czas odpowiedzi jest oczywiście wolniejszy, ponieważ jsf ma efekt współbieżności, którego nie ma jsp”, czy nie jest to sam problem skalowalności? o myfaces, afaik mojarra to najszybsza implementacja na świecie (
zbadam
3

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.

lu4242
źródło
3

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ć!

Martijn Verburg
źródło
2

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.

Dima
źródło
1

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)
Jonathan S. Fisher
źródło
-3

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.

Joenan
źródło
1
Nie odpowiada na pytanie, które dotyczy wydajności JSF, a nie rekomendacji ramowej. W każdym razie GWT jest zwykle lubiany przez ludzi, którzy nie znają JavaScript ^^
Danubian Sailor