Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as primarily opinion-based by gnat, gbjbaanb, MichaelT, Kilian Foth, Ozz Oct 2 '13 at 10:38

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

5  
ptrthomas.wordpress.com/2009/05/15/jsf-sucks I know that there has been a response by the JSF chief architect who justifies every decision, but to me, someone who knows some web technologies and who suffered, even with JSF 2.0, Facelets and SEAM, this is mockery. Even James Gosling sais: "I hate JSF with a passion." I'd use Wicket or Tapestry and avoid JSF and its problems altogether. –  Falcon Nov 20 '11 at 16:39
11  
@ThorbjørnRavnAndersen I disagree with you gently. I think it is better to provide more explanation than just saying: "I hate JSF" –  Chiron Nov 20 '11 at 21:09
6  
@ThorbjørnRavnAndersen I understand your point but I really encourage people to provide more info. For example, a down vote without a comment always annoys me. –  Chiron Nov 20 '11 at 22:01
2  
@Chiron, the question is not whether JSF is usable or not, but if JSF can be made to perform. People who start by putting the framework down, can most likely not answer the actual question. Maintaining a JSF application myself, I'd like to know too. –  user1249 Nov 21 '11 at 7:14
2  
@Falcon, anything more specific than a kind of argument like "Android rulez, iPhone sucks"? –  Arjan Tijms Feb 18 '12 at 10:33
show 16 more comments

8 Answers

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.

share|improve this answer
    
0 ms... I think your means of measurement needs looking at. –  gbjbaanb Sep 30 '13 at 13:55
    
@gbjbaanb I don't think so, these came from statistics that were quite professionally set up. Do note that I'm talking about the minimum time and about non-DB intensive pages. Pages executing in such time obviously did not have 1000 components on them spread over 100 includes. We're talking about relatively simple pages here, maybe 10 components, 1 master template, maybe 1 include, on a server that has been running for a while so everything is hot and in memory. Average time is higher (10ms as I mentioned) and 90% higher too. Max can be anything. –  Arjan Tijms Oct 1 '13 at 7:02
add comment

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.

share|improve this answer
2  
-1 for any framework scales. That's like saying "don't care about performance." –  Raynos Nov 22 '11 at 23:14
2  
In and of themselves any published web framework will scale including JSF. They all say they do, it would be a pretty crappy framework if it didn't. That said, many people do stupid things with it and that is usually where the scaling problems arise. –  Bill Leeper Nov 23 '11 at 14:53
1  
true, but some frameworks encourage you to do things with hinder scaling, either because the framework encourages or the community encourages it. I would argue those frameworks don't scale. –  Raynos Nov 23 '11 at 14:59
    
The "how do you measure scaling" bit should perhaps be a comment to the question? –  user1249 Dec 6 '11 at 23:19
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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!

share|improve this answer
add comment

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)
share|improve this answer
    
I don't think a simple helloworld page can be representative or meaningful. A serious comparison must provide necessary information like version numbers, configuration used and so on. Please read the comparison between JSF and Wicket in a previous answer. –  lu4242 Apr 2 '13 at 17:16
    
Let me disagree. I find really meaningful that in the simplest stateless context jsf is 5 times slower than jsp. It's trivial to verify that in more complex scenarios jsf performance get worst. Or i can provide more benchmarks for the laziest :-) jsf implementation is mojarra 2.2 as stated above, with glassfish 3 –  gpilotino Apr 2 '13 at 22:36
    
"... jsf is 5 times slower than jsp ..." I think the mistake here is do not take into account the throughput, and the underlying behavior of jsp vs jsf. It is too complex to explain, but in this case, the response time is obviously slower because jsf has a concurrency effect that jsp do not have. But at the end it is more accurate to compare the cycles per second. Also, Mojarra is not the same as MyFaces, so both implementations has different numbers from performance perspective. Note the concurrency effect in this case is exagerated. –  lu4242 Apr 3 '13 at 1:41
    
In fact, it is completely absurd to compare a plain servlet vs JSF. The only comparison that has sense is an "application" made using JSP/servlets vs another "application" that do exactly the same using JSF. Why? because JSF provide built-in solutions for rendering/ajax/navigation/validation, things that needs to be done from scratch or by hand in JSP. Even if the comparison is interesting from performance perspective (no framework will be faster than servlet/jsp), JSP is no match for JSF, because it doesn't do even a tiny part that what JSF does for you. –  lu4242 Apr 3 '13 at 2:00
    
"it is completely absurd to compare a plain servlet vs JSF". no, it's not. both technologies are supposed to deliver content. this is why i'm taking into account stateless contexts, where validation and other things just doesn't count. "the response time is obviously slower because jsf has a concurrency effect that jsp do not have" isn't this a scalability issue itself ? about myfaces, afaik mojarra it's the fastest implementation around (i'll investigate this) –  gpilotino Apr 3 '13 at 7:59
show 4 more comments

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)
share|improve this answer
add comment

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.

share|improve this answer
    
It doesn't answer the question, which is about JSF performance and not framework recommendation. Anyway, GWT is usually liked by people that don't know JavaScript ^^ –  Łukasz 웃 L ツ Nov 26 '13 at 15:04
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.