私はJSFについて多くの良い話を聞いたことがありますが、私が知っている限りでは、人々が過去にこの技術に多くの深刻な不満を抱いていたこともあります。私たちは、JSFをソーシャルネットワークプロジェクトの有望なテクノロジーと考えています。しかし、JSFのパフォーマンススコアを認識しておらず、JSFを使用していた既存の高性能Webサイトに実際に出くわすこともできませんでした。人々はパフォーマンスのスケーラビリティの問題に不満を持っています。

jsfを選択することで正しいことを行っているかどうかはまだよくわかりません。したがって、このことについてすべてお聞きになり、入力を考慮したいと思います。

ソーシャルネットワーキングサービスの高性能ニーズを満たすようにJSFを構成することは可能ですか？また、JSFの現在の問題でどの程度まで生き残ることができるのか。問題は何ですか？

私はない 私の個人的な経験のとおり、私はそれがすべて真実ではないと考えているので、他の人が普通に文句を言う何JSFと開発の複雑さを心配したが、私はより多くのものを、パフォーマンスとスケーラビリティの問題が心配です。また、以前のバージョンにリンクされている古い問題で悪用しないでください。過去に何があったとしても、私は現在の状態に関心があるだけです。

JSFは、間違いなく高性能のWebアプリケーションを配信できます。現在作業中のアプリは完全にJSFにあり、ログ統計から、多くの非DB集約ページの最小実行時間が0ミリ秒、平均時間が10ミリ秒未満であることがわかります。

Wicketの男の中には、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より前）が抱えていた主要なパフォーマンス/スケーラビリティの問題の1つは、大量のデータを格納することで状態の保存を悪用することでした。絶対にそこにあるべきではないもの（例えば、「foo」などの定数<my:tag attribute="foo"/>）。

JSF 2.0は、partial state savingデルタ状態のみが保存されることを意味するメカニズムを導入しました。実際には、これはごくわずかであり、JSF 1.xと比較して2桁の削減は珍しくありません。

JSFを何年も使用した後、JSF 1.xで状態を保存しすぎることを除いて、JSFに起因するパフォーマンスの問題に遭遇したことは一度もありません。これまでに発生したパフォーマンスの問題は、常にDBに起因していた、および/またはバックエンドサービスの設定方法、クエリの作成方法などでした。

世界のすべての理論はJSFは素晴らしいと言うことができますが、あなたのページがどのように見えるかを見てください。JavaScriptやその他のがらくたが大量に生成され、jQueryなどのモジュールを追加したり、CSSをクリーンに使用したりする能力が大幅に低下します。それができないと言っているわけではありませんが、どのような費用がかかります。

比較的小規模なプロジェクトで複雑さが中程度の個人的な経験。災害。それはすべてのコールバックを扱う混乱であり、他のテクノロジーを簡単に混在させることはできません。JSFと混合したJSTLを使用しているときに発生することが判明した大きなバグがありました。すべてのリンクがjavascriptコールバックであるため、jQueryのすべてを使用することはできませんでした。

逃げて、速く逃げます。

また、スケールと言うとき、どのようなスケールについて話しているのですか。ページ数、ユーザー数、1秒あたりのリクエスト数、機能数。これらに対する答えはあなたを助けるかもしれません。また、誰かがあなたにスケーリングをする必要があると言ったら、それらをどの程度、どのくらいの速さで尋ねます。答えは非常に役立ちます。1週間でGoogleスケールについて話している場合、または1年に1日あたり1000人のユーザーと10000ページビューについて話している場合。

バックグラウンドで応答をリアルタイムで入力することを除いて、ほとんどすべてのフレームワークは、ユースケースの99.999％を満たすように拡張されます。

免責事項：私はJSFが好きです。とにかく、最新のRI（Mojarra 2.2.x）またはMyFacesであっても、待望のステートレスな実装 パフォーマンスであっても、非常に貧弱です。これは、JSFのライフサイクルと、各ビューがすべてのリクエストに対して（高価に）構築されるためです。

手がかりを得るために、これは単純なJavaサーブレット対JSFページに対する単純なベンチマークであり、どちらも「hello world」を印刷するだけです。

サーブレット

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：Performance Comparison at DZone Javalobby：

... この記事では、ほとんどのSPI Java Webフレームワークがサーバーによって提供される部分的な変更に対してどれほど効果的であるかを検討します。サーバー通信のないイベント、つまり（可能な）サーバー制御のないイベントには興味がありません。

それらの測定方法

clientで実行される視覚的な変更に関してクライアントに送信されるコードの量を測定します。

たとえば、コンポーネントの小さな視覚的変更（一部の新しいデータ）については、サーバーからのコードはそれほど多くないと予想されます。つまり、プレーンHTMLとして必要な、JavaScriptに埋め込まれた新しいマークアップ、または新しいデータを含む高レベルの命令は、視覚化。そうしないと、たとえば、完全なコンポーネントまたはページゾーンが再構築され、帯域幅とクライアントの電力（およびサーバーの電力）が浪費されるなど、何かがおかしいようです。

パブリックデモを使用するため、明確で詳細なベンチマークを取得することはありません。しかし、フレームワークには非常に大きな違いがあります。

テスト手法は非常に簡単で、誰もが特別なインフラストラクチャなしで実行できます。FireFoxとFireBugが必要です。このテストでは、FireFox 3.6.8とFireBug 1.5.4が使用されます。

「Show XMLHttpRequests」が有効になっている場合、FireBug Consoleはサーバーの応答を示すAJAX要求を記録します...

テストされたフレームワーク

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

...明らかに、重大なパフォーマンスペナルティのないJSF実装はPrimeFacesだけです...

誰かが私が見たいと思うものを見つけた場合、私は適切な比較を見つけることができませんでした（パフォーマンスのため）！

一般にFaceletsには問題があり、これは私見では使用するのがかなり不便です。それは実際に必要なものよりも4倍冗長であり、原始的なものから一歩踏み出した後は手作業が多すぎます。HybridJavaは、JSF内のプレゼンテーションエンジンとしてFaceletsの優れた代替品になります。同じジョブを実行し（特に、さらに多くの「バインディング」とIDを作成します）、キーストロークがはるかに少なくなります。

だから私は同様のベンチマークを投げ入れたかった。私はツイッターのブートストラップのサンプルページを取り、それをxhtml strictに変換した。その後、Hello、Worldを返すApplicationScoped CDI Beanを1つだけセットアップしました。ページにEL式を配置します。JSFバージョンでは、JSFリソースハンドラーを使用し、JSPXバージョンでは、HTMLスタイルのcssおよびjs includeを使用しました。

メインページの読み込み時間をテストするために、Apacheベンチを使用しました。テストは、最適化されていないTomEE + v1.5.2サーバーで実行されました。各ベンチマークを5回実行し、測定を行う前にフルGCを実行しました。ブーストテストは、JVMを再起動せずに同じJVMインスタンスで実行されました。libpathでAPRを利用できますが、それがこのテストに影響するかどうかわかりません。

JSFは低速ですが、処理量が非常に少ないため、全体ではありません。何されていないページがより複雑になるにつれて立証することで、直線的または指数関数的にJSF / JSPXスケールを行います。

私が気づいたことの1つは、JSPFが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は、JavaコードをJavaスクリプトに変換します。そのため、クライアント側でjavaスクリプトとして実行されます。また、cssをgwtアプリケーションに統合することもできます。一般に、gwtは軽量で、すべてのブラウザーで問題なく実行できます。私はJSFについてあまり知りません。しかし、dt、JSFはGWTほど柔軟ではないと思います。