JSF是否真的准备交付高性能Web应用程序？[关闭]

16

我听说过很多有关JSF的好处，但据我所知，过去人们也对该技术有很多严重的抱怨，却不知道情况有多大改善。我们正在考虑将JSF作为社交网络项目的可能技术。但是我们不知道JSF的性能得分，也无法真正遇到使用JSF的任何现有高性能网站。人们抱怨它的性能可伸缩性问题。

我们仍然不太确定我们是否通过选择jsf做正确的事情，因此希望听到您的所有意见并考虑您的意见。

是否可以配置JSF以满足社交网络服务的高性能需求？同样，要解决JSF当前的问题，在多大程度上可以生存。它到底有什么问题？

我并不 担心其他人通常会抱怨的与JSF的开发复杂性，因为根据我的个人经验，我认为这并不是真的，但是我更担心什么性能和可伸缩性问题。并且，请不要仅仅在与旧版本相关的旧问题上滥用它。我只是在乎现在的状态，无论过去是什么。

java  web-development  web-applications  web-framework 
— aklin81
source
7
ptrthomas.wordpress.com/2009/05/15/jsf-sucks 我知道JSF首席架构师已经做出了回应，证明了每个决定都是合理的，但是对我来说，即使是JSF，也知道一些Web技术并遭受了痛苦的人2.0，Facelets和SEAM，这很可笑。甚至詹姆斯·高斯林（James Gosling）也说：“我满怀激情地讨厌JSF。” 我将使用Wicket或Tapestry并完全避免JSF及其问题。
— 猎鹰
12
@ThorbjørnRavnAndersen我很不同意你。我认为这是比只是说提供更多的解释：“我讨厌JSF”
— 凯龙
6
@ThorbjørnRavnAndersen我理解您的观点，但我真的鼓励人们提供更多信息。例如，没有评论的否决票总是让我烦恼。
— Chiron
3
@Chiron，问题不是JSF是否可用，而是能否使JSF执行。首先放下框架的人们很可能无法回答实际问题。我也想知道自己维护JSF应用程序。
3
>甚至詹姆斯·高斯林（James Gosling）也说：“我满怀激情地讨厌JSF。” -众所周知，这是一个错误，因为他要说的是JSP。仔细听有问题的片段。它是为响应经典ASP而创建的，它是JSP，而不是JSF。
— Arjan Tijms'2

Answers:

24

JSF绝对有能力交付高性能Web应用程序。我当前正在使用的应用程序完全在JSF中，从日志统计信息中我可以看到许多非DB密集型页面的最小执行时间为0ms，平均时间小于10ms。

一些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客户端仍然需要做一些工作收到服务器响应后执行。

旧的 JSF版本（2.0之前的版本）存在的主要性能/可伸缩性问题之一是，通过在其中存储太多数据来滥用状态保存。绝对不应该放在其中的东西（例如in中的常量，例如'foo' <my:tag attribute="foo"/>）。

JSF 2.0引入了该partial state saving机制，这意味着仅保存增量状态。实际上，这可能很少，并且与JSF 1.x相比减少两个数量级并不罕见。

经过多年使用JSF，我可以说，除了在JSF 1.x中保存过多的状态外，我从未遇到任何可归因于JSF的性能问题。我们曾经遇到过的任何性能问题总是根植于数据库和/或我们如何设置后端服务，编写查询等。

— 阿尔扬·提姆斯（Arjan Tijms）
source
1
0毫秒...我认为您的测量方法需要考虑。
— gbjbaanb
2
@gbjbaanb我不这么认为，这些来自非常专业的统计数据。请注意，我所说的是最短时间和非数据库密集型页面。显然，在这段时间内执行的页面上没有1000个组件，分布在100个include中。我们在这里谈论的是相对简单的页面，在运行了一段时间的服务器上，可能包含10个组件，1个主模板，可能包含1个主模板，因此所有内容都非常热并且在内存中。平均时间更长（如我所说，为10毫秒），也更长了90％。Max可以是任何东西。
— Arjan Tijms
情况是，这个世界只批评那些能够解决所有问题的事物。但是，解决所有问题总是要付出代价，并且需要极大的热情和热情。我在团队中看到的是，他们甚至在不了解生命周期的情况下就开始发展。它涉及陡峭的学习曲线，但既美观又引人注目。
— Shirgill Farhan
与服务器本身相比，瓶颈更可能出现在数据库/ IO和带宽（移动...）中。使用得当，Java确实非常快。
— Christophe Roussy
8

世界上所有的理论都可以说JSF很棒，但是只需看看页面的外观即可。它会产生大量的javascript和其他废话，这将严重妨碍您添加jQuery之类的模块或清理CSS的能力。不是说不能做到，而是要付出什么代价。

具有较小项目和中等复杂性的个人经验。灾难。处理所有回调都是一团糟，您不能轻易地混入其他技术。我们发现有一个巨大的错误，该错误是由将JSTL与JSF混合使用时引起的。由于每个链接都是JavaScript回调，因此我们无法使用所有jQuery的东西。

逃跑，快速逃跑。

同样，当您说规模时，您在说什么规模。页面数，用户数，每秒请求数，功能数。这些问题的答案可能会对您有所帮助。另外，当有人告诉您需要扩展时，请问他们达到什么程度和速度。答案将极大地帮助您。如果您是在一周内谈论Google规模，还是一年中每天谈论1000位用户和10000次页面浏览。

除了在后台实时输入响应之外，几乎所有框架都可以扩展以满足99.999％的用例。

— 比尔·里珀（Bill Leeper）
source
3
-1适用于任何框架比例。这就像在说“不在乎性能”。
— 雷诺斯2011年
3
就其本身而言，任何已发布的Web框架（包括JSF）都可以扩展。他们都说这样做了，如果没有的话，那将是一个非常糟糕的框架。就是说，许多人都用它来做一些愚蠢的事情，通常这就是出现扩展问题的地方。
— Bill Leeper
1
的确如此，但是某些框架鼓励您以阻碍扩展的方式来做事情，因为框架鼓励或社区鼓励这样做。我认为这些框架无法扩展。
— 雷诺斯2011年
“如何测量缩放比例”位应该是对该问题的评论？
4

免责声明：我喜欢JSF。无论如何，即使使用最新的RI（Mojarra 2.2.x）或MyFaces，即使期待已久的无状态实现 性能也非常差。这是由于JSF生命周期以及为每个请求构建（昂贵）每个View的事实。

为了得到一个线索，这是一个针对普通java servlet与JSF页面的简单基准测试，两者都仅打印“ 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
source
1
我认为简单的helloworld页面无法代表或有意义。认真的比较必须提供必要的信息，例如版本号，使用的配置等。请在先前的答案中阅读JSF和Wicket之间的比较。
— lu4242
让我不同意。我发现真正有意义的是，在最简单的无状态上下文中，jsf比jsp慢5倍。验证在更复杂的场景中jsf性能变差是微不足道的。或者，我可以为最懒惰的人提供更多基准：-) jsf实现是如上所述的mojarra 2.2，以及glassfish 3
— gpilotino
“ ... jsf比jsp慢5倍...”我认为这里的错误是没有考虑吞吐量以及jsp与jsf的基本行为。解释起来太复杂了，但是在这种情况下，响应时间显然会变慢，因为jsf具有jsp没有的并发效果。但是最后比较每秒的周期会更准确。另外，Mojarra与MyFaces不同，因此从性能角度来看，这两种实现都有不同的数字。请注意在这种情况下并发效果被夸大了。
— lu4242
实际上，将普通的servlet与JSF进行比较是完全荒谬的。唯一有意义的比较是使用JSP / servlet创建的“应用程序”与使用JSF完全相同的另一个“应用程序”。为什么？由于JSF提供了用于渲染/ ajax /导航/验证的内置解决方案，因此需要从头开始或在JSP中手动完成。即使从性能的角度进行比较很有趣（没有框架会比servlet / jsp更快），但是JSP不能与JSF相提并论，因为JSP所做的甚至都没有JSF为您做的一小部分。
— lu4242 2013年
“将普通的servlet与JSF进行比较是完全荒谬的”。不，这不对。两种技术都应该提供内容。这就是为什么我要考虑无状态上下文的原因，在这种情况下，验证和其他内容根本不起作用。“响应时间明显变慢，因为jsf具有jsp没有的并发效果”这本身不是可扩展性问题吗？关于myfaces，afaik mojarra，这是最快的实现方式（我将对此进行调查）
— gpilotino
3

如果您想更清楚地了解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能够做什么。

— lu4242
source
3

一篇对服务器有帮助的Java框架： DZone Javalobby的性能比较可能会有所帮助（尽管不是很确定）。

... 本文回顾了大多数SPI Java Web框架对服务器提供的部分更改的有效程度。我们对没有服务器通信的事件（即没有（可能）服务器控制的事件）不感兴趣。

如何测量它们

我们将针对客户端中执行的视觉更改来衡量发送给客户端的代码量。

例如，对于组件中的微小视觉变化（一些新数据），我们期望服务器不会提供太多代码，也就是说，需要将新标记作为纯HTML或嵌入在JavaScript中，或者包含新数据的一些高级指令将可视化。否则，似乎有些问题，例如重建了整个组件或页面区域，浪费了带宽和客户端电源（可能还有服务器电源）。

因为我们将使用公共演示，所以我们将不会获得确定的细粒度基准。但是您会看到框架之间的巨大差异。

测试技术非常简单，每个人都可以在没有特殊基础设施的情况下完成这项工作，我们只需要FireFox和FireBug。在此测试中，使用了FireFox 3.6.8和FireBug 1.5.4。

启用“显示XMLHttpRequests”后，FireBug控制台会记录任何显示服务器响应的AJAX请求...

框架测试

RichFaces，IceFaces， MyFaces / Trinidad，OpenFaces，PrimeFaces，Vaadin，ZK，itsNat

...显然唯一不受严重性能损失的JSF实现是PrimeFaces ...

如果有人发现我希望看到它，我就无法找到合适的比较（性能）！

— 马丁·弗伯格（Martijn Verburg）
source
2

通常，Facelets存在一个问题，即IMHO使用起来很不方便。它比实际需要多四倍的罗word，一旦您脱离了原始的东西就需要太多的手工工作。HybridJava可以很好地替代Facelets，作为JSF中的表示引擎-它可以完成相同的工作（尤其是做更多的工作-它为您完成所有的“绑定”和id），而击键次数却少得多。

— 迪玛
source
1

因此，我想提出一个类似的基准测试。我使用了Twitter引导程序示例页面，并将其转换为xhtml strict。之后，我只设置了一个ApplicationScoped CDI bean，它返回了Hello，World。我将EL表达式放在页面上。对于JSF版本，我使用了JSF资源处理程序，对于JSPX版本，我使用了HTML样式css和js includes。

我使用apache Bench来测试主页加载时间。该测试是在未优化的TomEE + v1.5.2服务器上执行的。我将每个基准测试运行了5倍，然后在测量之前运行了完整的GC。在同一JVM实例中完成了Bost测试，而没有重新启动JVM。我在libpath上有可用的APR，但是我不确定这会影响此测试。

JSF速度较慢，但​​不是很慢，因为我们处理的数量很少。什么是不能证明是由于网页变得越来越复杂，确实JSF / JSPX规模的线性或指数。

我注意到的一件事是，与JSF相比，JSPX产生的垃圾很少。在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)
— 乔纳森·费舍尔
source
-3

GWT将您的Java代码转换为Java脚本。因此它在您的客户端上作为Java脚本运行。而且，您可以将css集成到gwt应用程序中。通常，gwt重量轻，可以在所有浏览器上运行而没有任何问题。我对JSF不太了解。但我认为，JSF并不像GWT那样灵活。

— 乔南
source
1
它没有回答有关JSF性能而不是框架建议的问题。无论如何，不​​懂JavaScript的人通常都会喜欢GWT ^^
— Danubian Sailor
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.