JSFは本当に高性能なWebアプリケーションを提供する準備ができていますか？
私はJSFについて多くのことを聞いたことがありますが、私の知る限り、過去にこのテクノロジーについて人々が多くの深刻な不満を抱えていて、状況がどれほど改善されたかはわかりません。私たちはJSFをソーシャルネットワークプロジェクトの有望なテクノロジーとして検討しています。しかし、JSFのパフォーマンススコアを認識していないため、JSFを使用していた既存の高性能Webサイトを実際に見つけることはできません。人々はそのパフォーマンスのスケーラビリティの問題について不満を述べています。
私たちがjsfを選択して正しいことを行っているかどうかはまだはっきりしていません。そのため、これについてすべての意見を聞き、入力を考慮に入れたいと思います。
ソーシャルネットワーキングサービスの高パフォーマンスニーズを満たすようにJSFを設定することは可能ですか？また、JSFの現在の問題をどの程度克服することも可能です。その問題は正確には何ですか？
私はnot JSFの開発の複雑さについて心配しています。私の個人的な経験によれば、それは真実ではないと私は信じているからです。しかし、パフォーマンスとスケーラビリティの問題についてはもっと心配しています。そして、以前のバージョンにリンクされた古い問題を悪用しないでください。過去が何であれ、現在の状態を気にしているだけです。
JSFは、間違いなく、高性能のWebアプリケーションを提供できます。私が現在取り組んでいるアプリは完全にJSFであり、ログの統計から、DBを集中的に使用しない多くのページの最小実行時間が0ミリ秒で、平均時間が10ミリ秒未満であることがわかります。
一部のWicketの人たちはJSFのパフォーマンスについて語っていますが、この手の込んだベンチマークによると、JSFは実際にはWicketよりも優れています： http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx -edition /
サーバーが飽和状態でない限り、JSFはGWTよりもパフォーマンスが優れていることに注意してください。ただし、GWTのサーバーがJSFが行うポストバックでデータの変換と検証も行うことが非常に重要であるため、GWT/JSFベンチマークの比較は困難です。これは、実際には省略できないものです（クライアントを信頼しないでください）。また、GWT対JSF/Wicketグラフの場合、ブラウザーのレンダリング手順はJSF/Wicketにとっては取るに足らないことを考慮に入れる必要があります（それらはほとんどがすぐにレンダリングできるHTMLを提供するため）、GWTクライアントにはまだいくつかの作業がありますサーバーの応答を受け取った後で行います。
oldJSFバージョン（2.0より前）にあった主要なパフォーマンス/スケーラビリティの問題の1つは、データを入れすぎて状態の保存を悪用することでした。絶対に入れるべきではないもの（<my:tag attribute="foo"/>のような「foo」などの定数）。
JSF 2.0はpartial state savingメカニズムを導入しました。つまり、デルタ状態のみが保存されます。実際にはこれはごくわずかであり、JSF 1.xと比較して2桁の減少は珍しいことではありません。
JSFを何年も使用した後、JSF 1.xで保存した状態が多すぎることを除いて、JSFに起因する可能性のあるパフォーマンスの問題に遭遇したことは一度もありません。これまでに発生したパフォーマンスの問題は、常にDBに起因するか、バックエンドサービスの設定方法、クエリの記述方法などに起因しています。
世界の理論はすべて、JSFは素晴らしいと言えますが、ページの外観を見てください。それは、jQueryのようなモジュールを追加したり、CSSをクリーンに使用したりする能力に深刻な障害をもたらす、JavaScriptやその他のがらくたの大量の山を生み出します。それは不可能だとは言わないが、どんな費用で。
比較的小規模なプロジェクトと中程度の複雑さの個人的な経験。災害。それはすべてのコールバックを扱う混乱であり、他のテクノロジーを簡単に混在させることはできません。 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パフォーマンスに関するすべての質問が解決され、Apache MyFacesで何ができるかがわかります。
少しは役立つかもしれませんが（実際には決定的ではありませんが） Server Centric Java Frameworks：Performance Comparison at DZone Javalobby：
...この記事では、 [〜＃〜] spi [〜＃〜] Java webフレームワークは、サーバーによって提供される部分的な変更に基づいています。サーバー通信のないイベント、つまり、（可能性のある）サーバー制御のないイベントには興味がありません。
それらが測定される方法
クライアントで実行された視覚的な変更に関してクライアントに送信されるコードの量を測定します。
たとえば、コンポーネントの小さな視覚的な変更（一部の新しいデータ）の場合、サーバーからのコードはそれほど多くないと予想されます。つまり、プレーンなHTMLとして必要な、またはJavaScriptに埋め込まれた新しいマークアップ、または新しいデータを含む高レベルの命令視覚化。そうでない場合、たとえば、コンポーネントまたはページゾーン全体が再構築され、帯域幅とクライアントの電力（およびおそらくサーバーの電力）を浪費するなど、何か問題があるように見えます。
公開デモを使用するため、明確で細かいベンチマークは取得しません。ただし、フレームワーク間には非常に大きな違いがあります。
テスト手法は非常に簡単で、誰もが特別なインフラストラクチャなしで実行できます。FireFoxとFireBugが必要です。このテストでは、FireFox 3.6.8およびFireBug 1.5.4を使用しています。
「Show XMLHttpRequests」が有効になっている場合、FireBug Consoleはサーバーの応答を示すすべてのAJAXリクエストを記録します...
テストされたフレームワーク
RichFaces 、 IceFaces 、 MyFaces/Trinidad 、 OpenFaces 、 PrimeFaces 、 ヴァーディン 、 [〜＃〜] zk [〜＃〜] 、 ItsNat
...どうやら重大なパフォーマンスペナルティのない唯一のJSF実装はPrimeFacesです...
適切な比較（パフォーマンス）を見つけることができませんでした。誰かが私に見たいと思うものを見つけたら！
Facelets全般に問題があり、IMHOを使用するのはかなり不便です。それは実際に必要なものよりも4倍多く、プリミティブから一歩踏み出すと手作業が多すぎます。 HybridJava は、JSF内のプレゼンテーションエンジンとしてのFaceletsの優れた代替品です。これは、同じ作業を行います（特に、さらに多くの「バインディング」とIDを作成します）。キーストローク。
だから私は同様のベンチマークを投げたかったです。私は Twitter bootstrap example page を取り、それをxhtml strictに変換しました。その後、ApplicationScoped CDI Beanを1つだけセットアップしましたHello、Worldを返しました。EL式をページに配置しました。JSFバージョンの場合はJSFリソースハンドラーを使用し、JSPXバージョンの場合はHTMLスタイルのcssおよびjs includeを使用しました。
Apacheベンチを使用して、メインページの読み込み時間をテストしました。テストは、最適化されていないTomEE + v1.5.2サーバーで実行されました。各ベンチマークを5回実行してから、測定を行う前にフルGCを実行しました。 Bostテストは、JVMを再起動せずに同じJVMインスタンスで実行されました。 libpathで利用可能なAPRを持っていますが、それがこのテストに影響するかどうかはわかりません。
非常に少量を扱っているため、JSFは遅くなりますが、全体としてはそうではありません。 ではないことが示されているのは、ページがより複雑になるにつれて、JSF/JSPXが線形的または指数的にスケーリングすることです。
私が気づいたことの1つは、JSPXはJSFと比較してごみをほとんど生成しないことです。 JSPXページでベンチマークを実行すると、使用済みヒープが184MBから237MBにジャンプしました。 JSFページの同じJVMでベンチマークを実行すると、使用済みヒープが108 mbからleast404 mbにジャンプしますが、自動ガベージコレクションはその点。 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)