Is JSF really ready to deliver high performance web applications?

Question

I have heard a lot of good about JSF but as far as I know people also had lots of serious complains with this technology in the past, not aware of how much the situation has improved. We are considering JSF as a probable technology for a social network project. But we are not aware of the performance scores of JSF neither we could really come across any existing high performance website that had been using JSF. People complain about its performance scalability issues.

We are still not very sure if we are doing the right thing by choosing jsf, and thus would like to hear from you all about this and take your inputs into consideration.

Is it possible to configure JSF to satisfy the high performance needs of social networking service ? Also till what extent is it possible to survive with the current problems in JSF. What exactly are its problems ?

I am not worried about the development complexities with JSF what others usually complain about because as per my personal experience I believe that's not at all true, but I am more concerned about what performance and scalability issues. And please don't just abuse it on its old issues linked to previous versions. I just care about the present state whatever had been its past.

score 23 · Answer 1 · answered Feb 18 '12 at 10:29

JSF is most definitely capable of delivering high performance web applications. The app I'm currently working on is completely in JSF and from the log stats I can see that many non-DB intensive pages have minimum execution times of 0ms and average times of less than 10ms.

Some of the Wicket guys have been saying things about JSF' performance, but according to this elaborate benchmark JSF actually performs better than Wicket: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/

Notice that as long as the server isn't saturated, JSF also performs better than GWT. The GWT/JSF benchmark comparison is difficult though, since it's really important that the server for GWT also does the conversion and validation of data in the postback that JSF does. This is something you simply can't leave out in practice (never trust the client). Also, for the GWT vs JSF/Wicket graphs, it should be taken into account that the browser's rendering step is trivial for JSF/Wicket (since they mostly serve ready-to-render HTML), but the GWT client still has some work to do after receiving the server response.

One of the major performance/scalability issues that old JSF versions (prior to 2.0) had, was abusing state saving by putting way too much data in it. Things that absolutely should not have been there where put into it (like constants such as 'foo' as in <my:tag attribute="foo"/>).

JSF 2.0 introduced the partial state saving mechanism, which means only delta state is being saved. In practice this can be very little and reductions of two orders of magnitude compared to JSF 1.x are not uncommon.

After years of using JSF, I can say that except for saving too much state in JSF 1.x, I've never run into any performance issue that I could attribute to JSF. Any performance problems we ever had were always rooted in the DB and/or how we set up back-end services, wrote our queries, etc.

score 8 · Answer 2 · answered Nov 22 '11 at 21:29

All the theoretical in the world can say JSF is wonderful, but just take a look at what your pages look like. It produces massive piles of javascript and other crap that are going to severely handicap your ability to add in modules like jQuery or clean use of CSS. Not saying it can't be done, but at what cost.

Personal experience with a relatively small project and medium complexity. A disaster. It was a mess dealing with all the callbacks and you can't mix in other technologies easily. We had a huge bug that turned out to be caused when using JSTL mixed in with JSF. We never were able to use all the jQuery stuff due to the fact that EVERY link is a javascript callback.

Run away and run away fast.

Also when you say scale, what kind of scale are you talking about. Number of pages, number of users, number of requests per second, number of features. The answers to these may help you. Also when someone tells you it needs to scale ask them to what degree and how fast. The answer will help you tremendously. If you are talking google scale in a week or are you talking about 1000 users and 10000 page views per day in a year.

Almost any framework, short of you typing in responses real time in the background, will scale to meet 99.999% of the use cases.

score 4 · Answer 3 · answered Mar 02 '13 at 00:52

Disclaimer: I like JSF. Anyway, even with the latest RI (Mojarra 2.2.x) or MyFaces, even with the long awaited stateless implementation performance is very poor. This is because of the JSF lifecycle and the fact that each View is (expensively) built for every request.

To get a clue, this is a simple benchmark against a plain java servlet vs a JSF page, both just printing "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)

score 3 · Answer 4 · edited Dec 25 '12 at 19:15

An article that might help a little (although not really conclusive) is Server Centric Java Frameworks: Performance Comparison at DZone Javalobby:

...This article reviews how much effective most of the SPI Java web frameworks are on partial changes provided by the server. We are not interested in events with no server communication, that is, events with no (possible) server control.

How they are going to be measured

We are going to measure the amount of code that is sent to client regarding to the visual change performed in client.

For instance for a minor visual change (some new data) in a component we expect not much code from server, that is, the new markup needed as plain HTML, or embedded in JavaScript, or some high level instructions containing the new data to be visualized. Otherwise something seems wrong for instance the complete component or page zone is rebuilt, wasting bandwidth and client power (and maybe server power).

Because we will use public demos, we are not going to get a definitive and fine grain benchmark. But you will see very strong differences between frameworks.

The testing technique is very easy and everybody can do it with no special infrastructure, we just need FireFox and FireBug. In this test FireFox 3.6.8 and FireBug 1.5.4 are used.

The FireBug Console when "Show XMLHttpRequests" is enabled logs any AJAX request showing the server response...

Frameworks tested

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

...apparently the only JSF implementation free of serious performance penalties is PrimeFaces...

I haven't been able to find a proper comparison (for performance), if anyone finds one I'd love to see it!

score 3 · Answer 5 · answered May 21 '12 at 18:48

If you want to understand more clearly how JSF performs (both Mojarra 2.1.7 and MyFaces 2.1.7) and compare it against a similar framework like Apache Wicket(both 1.4.20 and 1.5.5), take a look to this in-deep comparison (MAY 2012):

Understanding JSF 2 and Wicket: Performance Comparison

The good part is everything is available (code, experimental data, instructions about how to reproduce the test, a detailed exhaustive report). It will solve all your questions about JSF performance, and you'll see what Apache MyFaces is able to do.

score 2 · Answer 6 · answered Nov 21 '11 at 07:11

There is a problem with Facelets in general which IMHO is a pretty inconvenient thing to use. It is four times more wordy than indeed necessary and need too much manual work once you make one step off something primitive. HybridJava would be a good replacement for Facelets as presentation engine within JSF - it does the same job (and even much more, in particular - it makes all the "bindings" and ids for you) with much fewer keystrokes.

Jonathan S. Fisher · Answer 7 · 2013-05-01T15:40:58.277

So I wanted to throw a similar benchmark in. I took a twitter bootstrap example page and converted it into xhtml strict. After that, I setup exactly one ApplicationScoped CDI bean that returned Hello, World. I put the EL expression on the page. For the JSF version, I used the JSF resource handler, for the JSPX version, I used HTML style css and js includes.

I used apache bench to test the main page load time. The test was performed on an un-optimized TomEE+ v1.5.2 server. I ran each benchmark 5x, then ran a full GC before taking a measurement. Bost tests were done in the same JVM instance without restarting the JVM. I have the APR available on the libpath, but I'm not sure that affects this test.

JSF is slower, but not by a whole lot, since we're dealing with very small quantities. What is not demonstrated is as the pages get more complex, does JSF/JSPX scale linearly or exponentially.

One thing I noticed is that JSPX is produces very little garbage compared to JSF. Running the benchmark on the JSPX page caused the used heap to jump from 184mb to 237mb. Running the benchmark in the same JVM on the JSF page causes the used heap to jump from 108mb to at least 404mb, but an automatic garbage collection kicked in at that point. It would seem tuning your garbage collector for JSF is an absolute necessity.

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)

score -3 · Answer 8 · answered Dec 25 '12 at 18:53

GWT converts your java code into java script. so it runs as a java script on your client side. And also, you can integrate css into your gwt applications. In general, gwt is light weight and can run across all browsers without any problem. I dont know much about JSF. But I think dt, JSF is not that flexible like GWT.

Is JSF really ready to deliver high performance web applications?

8 Answers8

How they are going to be measured

Frameworks tested

JSF

JSPX

Linked