나는 JSF에 대해 많은 것을 들었지만, 사람들이 과거 에이 기술에 대해 심각한 불만을 많이 가지고 있었지만 상황이 얼마나 개선되었는지는 알지 못했습니다. 우리는 JSF를 소셜 네트워크 프로젝트를위한 가능한 기술로 고려하고 있습니다. 그러나 우리는 JSF의 성능 점수를 알지 못하고 있으며 JSF를 사용했던 기존의 고성능 웹 사이트를 실제로 접할 수도 없습니다. 사람들은 성능 확장 성 문제에 대해 불평합니다.

우리는 jsf를 선택하여 올바른 일을하고 있는지 여전히 확실하지 않으므로 이에 대해 여러분의 의견을 듣고 입력 사항을 고려하고 싶습니다.

소셜 네트워킹 서비스의 고성능 요구를 충족하도록 JSF를 구성 할 수 있습니까? 또한 JSF의 현재 문제로 어느 정도까지 생존 할 수 있습니다. 정확히 무엇이 문제입니까?

나는 하지 내 개인적인 경험에 따라 내가 그 모든 사실에 아니다 믿기 때문에 다른 사람들이 일반적으로 불평 무엇 JSF와 개발의 복잡성에 대한 걱정,하지만 난 더 어떤 성능과 확장 성 문제에 대한 우려입니다. 그리고 이전 버전과 관련된 이전 문제로만 남용하지 마십시오. 나는 과거의 현재 상태에 관심이 있습니다.

JSF는 고성능 웹 애플리케이션을 가장 잘 전달할 수 있습니다. 현재 작업중 인 응용 프로그램은 JSF에 완전히 있으며 로그 통계에서 DB를 많이 사용하지 않는 많은 페이지의 최소 실행 시간이 0ms이고 평균 시간이 10ms 미만임을 알 수 있습니다.

개찰구들 중 일부는 JSF의 성능에 대한 일을 말하고 있지만, 실제로 수행하는 더 나은 개찰구 이상이 정교한 벤치 마크 JSF에 따라되었습니다 http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/

서버가 포화 상태가 아닌 한 JSF는 GWT보다 성능이 우수합니다. GWT / JSF 벤치 마크 비교는 GWT 용 서버가 JSF가하는 포스트 백에서 데이터의 변환 및 유효성 검사를 수행하는 것이 매우 중요하기 때문에 어렵습니다. 이것은 실제로 당신이 실제로 떠날 수없는 것입니다 (클라이언트를 믿지 마십시오). 또한 GWT 대 JSF / Wicket 그래프의 경우 브라우저의 렌더링 단계가 JSF / Wicket에서 사소한 것임을 고려해야합니다 (대부분 렌더링 준비가 된 HTML을 제공하기 때문에) GWT 클라이언트는 여전히 서버 응답을받은 후 수행하십시오.

이전 JSF 버전 (2.0 이전) 의 주요 성능 / 확장 성 문제 중 하나는 너무 많은 데이터를 저장하여 상태 저장을 남용하는 것입니다. (foo와 같은 상수와 같이) 어디에 넣었을 때 절대로 거기에 없었던 것들 <my:tag attribute="foo"/>.

JSF 2.0에는이 partial state saving메커니즘이 도입되어 델타 상태 만 저장됩니다. 실제로 이것은 매우 적을 수 있으며 JSF 1.x와 비교할 때 두 자릿수의 감소는 드문 일이 아닙니다.

몇 년 동안 JSF를 사용한 후에 JSF 1.x에서 너무 많은 상태를 저장하는 것을 제외하고는 JSF에 기인 할 수있는 성능 문제가 발생하지 않았다고 말할 수 있습니다. 우리가 경험했던 모든 성능 문제는 항상 DB에 뿌리를두고 있으며 백엔드 서비스를 설정하고 쿼리를 작성하는 방법 등입니다.

세계의 모든 이론가들은 JSF가 훌륭하다고 말할 수 있지만 페이지가 어떻게 보이는지 살펴보십시오. jQuery 또는 CSS를 깔끔하게 사용하는 것과 같은 모듈에 추가하는 기능을 심각하게 방해 할 수있는 대량의 자바 스크립트 및 기타 쓰레기를 생성합니다. 할 수 없다고 말하지는 않지만 얼마의 비용이 든다.

비교적 작은 프로젝트와 중간 정도의 복잡성에 대한 개인적인 경험. 재앙. 모든 콜백을 처리하는 것이 엉망이었고 다른 기술과 쉽게 혼합 할 수 없습니다. JSTL과 JSTL을 함께 사용할 때 발생하는 거대한 버그가있었습니다. 우리는 모든 링크가 자바 스크립트 콜백이라는 사실 때문에 모든 jQuery를 사용할 수 없었습니다.

도망 치고 빨리 도망 가세요.

또한 규모를 말할 때 어떤 종류의 규모에 대해 이야기하고 있습니까? 페이지 수, 사용자 수, 초당 요청 수, 기능 수 이에 대한 답변이 도움이 될 수 있습니다. 또한 누군가가 당신에게 말할 때 그것은 어느 정도 나 얼마나 빨리 물어볼 필요가 있습니다. 대답은 당신에게 큰 도움이 될 것입니다. 일주일에 Google 규모로 대화하거나 1 년에 하루에 약 1000 명의 사용자와 10000 페이지 조회수를 말하는 경우

백그라운드에서 실시간으로 응답을 입력하지 않는 거의 모든 프레임 워크는 사용 사례의 99.999 %를 충족하도록 확장됩니다.

면책 조항 : JSF를 좋아합니다. 어쨌든 최신 RI (Mojarra 2.2.x) 또는 MyFaces를 사용하더라도 오랫동안 기다려온 상태 비 저장 구현 성능이 매우 열악합니다. 이는 JSF 수명주기와 각 요청이 모든 요청에 ​​대해 (고가) 구축되어 있기 때문입니다.

실마리를 얻으려면, 이것은 "hello world"만 인쇄하는 일반 Java 서블릿과 JSF 페이지에 대한 간단한 벤치 마크입니다.

서블릿

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)

JSF의 성능 (Mojarra 2.1.7 및 MyFaces 2.1.7)을보다 명확하게 이해하고 Apache Wicket (1.4.20 및 1.5.5)과 유사한 프레임 워크와 비교하려면이 내용을 살펴보십시오. 심층 비교 (2012 년 5 월) :

JSF 2 및 Wicket 이해 : 성능 비교

좋은 부분은 사용 가능한 모든 것 (코드, 실험 데이터, 테스트 재생 방법에 대한 지침, 자세한 철저한 보고서)입니다. JSF 성능에 대한 모든 질문을 해결하고 Apache MyFaces가 수행 할 수있는 작업을 확인할 수 있습니다.

실제로 결정적이지는 않지만 약간 도움이 될만한 기사는 Server Centric Java Frameworks : DZone Javalobby의 성능 비교입니다 .

... 이 기사에서는 대부분의 SPI Java 웹 프레임 워크가 서버에서 제공하는 부분 변경에 얼마나 효과적인지 검토 합니다. 서버 통신이없는 이벤트, 즉 (가능한) 서버 제어가없는 이벤트에는 관심이 없습니다.

그들이 어떻게 측정 될 것인가

클라이언트에서 수행 된 시각적 변경과 관련하여 클라이언트에게 전송되는 코드의 양을 측정 할 것 입니다.

예를 들어 구성 요소의 사소한 시각적 변경 (일부 새로운 데이터)의 경우 서버의 코드, 즉 일반 HTML로 필요하거나 JavaScript에 포함 된 새 마크 업 또는 새 데이터를 포함하는 일부 고급 명령이 필요하지 않습니다. 시각화. 그렇지 않으면 전체 구성 요소 또는 페이지 영역이 다시 작성되어 대역폭과 클라이언트 전원 (및 서버 전원)이 낭비되는 등의 문제가 발생합니다.

공개 데모를 사용할 것이기 때문에 결정적이고 세밀한 벤치 마크를 얻지 못할 것 입니다. 그러나 프레임 워크 간에는 매우 큰 차이점이 있습니다.

테스트 기술은 매우 쉽고 누구나 특별한 인프라없이이를 수행 할 수 있습니다. FireFox와 FireBug 만 있으면됩니다. 이 테스트에서는 FireFox 3.6.8 및 FireBug 1.5.4가 사용됩니다.

"Show XMLHttpRequests"가 활성화 된 경우 FireBug 콘솔은 서버 응답을 보여주는 모든 AJAX 요청을 기록합니다.

테스트 된 프레임 워크

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

... 심각한 성능 불이익이없는 유일한 JSF 구현은 PrimeFaces입니다 ...

누군가 내가 그것을보고 싶은 것을 찾으면 (성능에 대한) 적절한 비교를 찾을 수 없었습니다!

IMHO가 사용하기에 매우 불편한 Facelets에는 일반적으로 문제가 있습니다. 그것은 실제로 필요한 것보다 4 배나 더 장황하며, 일단 원시적 인 것을 한 번만 내면 너무 많은 수동 작업이 필요합니다. HybridJava 는 JSF 내에서 프리젠 테이션 엔진으로 Facelets를 대체 할 수 있습니다. 키 스트로크를 줄이면서 동일한 작업을 수행 할 수 있습니다.

그래서 비슷한 벤치 마크를 던지고 싶었습니다. 트위터 부트 스트랩 예제 페이지를 가져 와서 xhtml 엄격으로 변환했습니다. 그런 다음 Hello, World를 반환하는 ApplicationScoped CDI Bean을 정확히 하나만 설정했습니다. EL 표현식을 페이지에 넣었습니다. JSF 버전의 경우 JSF 리소스 핸들러를 사용하고 JSPX 버전의 경우 HTML 스타일 css 및 js 포함을 사용했습니다.

아파치 벤치를 사용하여 메인 페이지 로딩 시간을 테스트했습니다. 테스트는 최적화되지 않은 TomEE + v1.5.2 서버에서 수행되었습니다. 각 벤치 마크를 5 배로 실행 한 다음 측정하기 전에 전체 GC를 실행했습니다. Bost 테스트는 JVM을 다시 시작하지 않고 동일한 JVM 인스턴스에서 수행되었습니다. libpath에서 APR을 사용할 수 있지만 이것이이 테스트에 영향을 미치는지 확실하지 않습니다.

우리가 매우 적은 양을 다루기 때문에 JSF는 느리지 만 많은 것이 아닙니다. 무엇입니까 없는 페이지가 더 복잡해으로 증명하는 것은, 선형 또는 기하 급수적으로 JSF / JSPX 스케일을 수행합니다.

내가 주목 한 것은 JSPX가 JSF에 비해 쓰레기를 거의 생산하지 않는다는 것입니다. JSPX 페이지에서 벤치 마크를 실행하면 사용한 힙이 184mb에서 237mb로 이동했습니다. JSF 페이지의 동일한 JVM에서 벤치 마크를 실행하면 사용 된 힙이 108mb에서 404mb 이상으로 이동하지만 자동 가비지 콜렉션이 시작됩니다. JSF에 대한 가비지 수집기를 조정하는 것이 절대적으로 필요한 것 같습니다 .

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는 자바 코드를 자바 스크립트로 변환합니다. 클라이언트 측에서 자바 스크립트로 실행됩니다. 또한 CSS를 gwt 애플리케이션에 통합 할 수 있습니다. 일반적으로 gwt는 가벼우 며 모든 브라우저에서 문제없이 실행될 수 있습니다. 나는 JSF에 대해 많이 모른다. 그러나 dt, JSF는 GWT와 같이 유연하지 않습니다.