JSF-Comparison: MyFaces vs. Mojarra

A couple of weeks ago we published the results of a comparative study about the performance impact of large component trees on JSF implementations. The article is available in German only so here is a brief summary in English.

Key-question was how strong the impact of the size of a JSF-component-tree is on the performance of a given JSF-application. Therefore we created a simple demo application that contained these variation-points:

  • JSF implementation: MyFaces or Mojarra
  • Number of components: The application contained a configurable number of input components (10, 100, 250, 250, 500, 1000, 1500, 2000, 2500, 5000)
  • State-Saving: Server or Clientside

We created deployable artifacts for the cross-product of these configuration properties so that every artifact differed only in one property. Monitoring the runtime behavior under load of each artifact enabled us to benchmark different configurations against each other (e.g. MyFaces, client-side state saving, 1000 components vs. Mojarra, client-side state saving, 1000 components). The tests were executed on a dedicated machine, the runtime environment was isolated from the machine that issued the requests. Every test was executed exclusively on a clean instance of the test environment to ensure the reliability of the generated results. All comparisons are based on Mojarra 2.1.14 and MyFaces 2.1.9.

Lifecycle Duration – MyFaces vs. Mojarra

We expected the number of components in a JSF-view to have significant impact on the lifecycle duration. This expectation was not only confirmed by our test results but we also found that there is a surprising huge difference between both implementations: While Apache MyFaces showed a linear rise for a growing number of components, Mojarras behavior was non-linear and it turned out to be significant slower.

Average Lifecycle Duration

The graph above shows the average time in [ms] taken for a complete lifecycle run depending on the number of components in the component tree. The yellow curve represents Mojarra, the blue curve MyFaces. Server-Side state saving was used in both cases.

Lifecycle Duration – Server vs Client-Side-State-Saving

Changing the state-saving mechanism from server- to client-side effectively relocates view-state from the server to the client. This reduces the required memory on the server for the cost of higher bandwith requirements (due to the state exchanged with every request). Client-side state saving requires the state to be deserialized for every incoming request and serialized for every outgoing response, so we expected to see a significant delay in response time with client-side state saving.

Lifecycle Duration MyFaces
Lifecycle Duration Mojarra

The images above show a significant penalty for client-side state saving for MyFaces while only little difference was visible for Mojarra. Please note that though the difference between both state-saving methods is very low for Mojarra the difference between Mojarra and MyFaces is enormous.

Conclusions

Our initial estimation regarding the impact of large component trees on a JSF applications performance were verified by the test results. We found that

  1. The number of components in the component tree has direct impact on the lifecycle duration and thus on the overall performance of a JSF based application.
  2. Apache MyFaces performs lifecycle runs a lot faster than Mojarra, no matter which state saving mechanism is used. Especially applications with large component trees would benefit from switching to MyFaces.
  3. MyFaces offers an overall  better runtime behavior, when only the observed technical aspects are taken into account. A follow-up with even broader range of technical aspects could help to explain this difference in performance.
  4. The linear rise in lifecycle duration is helpful for scalability assumptions when MyFaces is used.

Our benchmarks were focussed solely on the lifecycle duration as a performance indicator but naturally a lot more factors hold a share in the performance of a web application. This means that if an application suffers from large component trees and there is no chance to  reduce the number of components or switching the implementation is not an option other measures may be taken to improve performance.

Short URL for this post: https://wp.me/p4nxik-1rT
This entry was posted in Build, config and deploy, Did you know?, Java EE, Java Web Frameworks, Politics, Web as a Platform and tagged , , , , , , . Bookmark the permalink.

3 Responses to JSF-Comparison: MyFaces vs. Mojarra

  1. Hi

    I’m Leonardo Uribe from MyFaces Team, and I would like to thank you for the interest in the topic. MyFaces Community has been working a lot for a long time to get the best possible performance, because users deserve a great web framework and this is a topic that has been misunderstood for a long time.

    The linear relationship between number of components in a tree vs time spent in the lifecycle is something nice, and it is something expected too, because the activities described in the lifecycle has a linear complexity.

    But it is surprising that Mojarra has a exponential complexity; in my opinion it is a bug in the implementation, that could potentially impact performance in some applications, but maybe ignored because even in complex applications, the component tree does not grow as fast as you can imagine, thanks to facelets algorithm that compress html chunks in a efficient way. Components created by facelets to wrap up plain html code are significantly smaller and faster than normal components. For example, a plain EL expression embedded is ignificantly faster than use h:outputText component. Facelets can “compress” multiple EL expressions into a single flat component.

    About the effect of composite components over performance I would like to say that MyFaces implementation has been highly optimized in this part. In theory facelets custom user tags could be faster than composite components, but use them disable MyFaces EL caching, which is a very nice optimization. In my opinion, the benefits of use composite components exceed by far the overhead involved in use them. My advice is use them with moderation, specially in cases where you need to create lots of components in the same page. In those cases, use the old way (write a custom Component and Renderer) or use facelets templates is better.

    The methodology used in the comparison is great, but there is an unwanted side effect introduced by c:forEach tag to generate the components. Unfortunately, components created by c:forEach does not take advantage of partial state saving algorithm, so they need to be saved and restored fully. This creates a distortion over the time spent into the lifecycle,
    because if the state is saved fully, save and restore the state takes more time.

    The difference between client side state saving and server side state saving is in client side the state needs to be serialized, encrypted and base64 encoded. In server side state saving by default in MyFaces, the state is serialized but not encrypted or base64 encoded. It is possible to disable serialization in MyFaces and make it faster.

    With the right changes and enabling some flags in MyFaces, it is possible to get even better response times.

    I agree with the conclusions done in the article, but I would like to see this comparision taking into account the suggestions proposed, so people can understand better what’s going on.

    best regards,

    Leonardo Uribe

  2. Thomas Asel Thomas Asel says:

    I agree with the statement that Mojarras behavior in this point can be considered as a bug. According to https://java.net/jira/browse/JAVASERVERFACES-2494 Manfred Riem committed changes to Mojarras 2.1 and 2.2 branches just recently, so Mojarras behavior is expected to improve with the next stable builds.

    You are also totally right with the side effect of using c:forEach to create the component tree. Since possible negative effects would have affected Mojarra and MyFaces equally we were willing to accept those for the sake of convenience.

    There is a lot of context params for both implementations that may improve overall performance when chosen wisely. We do so in our projects to get the maximum speed out of any implementation. However, the overall idea of the comparison is to benchmark both implementations “as is”, so we decided to leave any context params set to their defaults. This enables us to compare the behavior of both implementations out of the box.

    Besides the results presented in the comparison, we were able to improve the performance of a clients JSF project significantly by doing little more than switching from Mojarra to MyFaces. Our conclusion is that MyFaces offers a better run-time behavior than Mojarra (you will certainly be glad to hear that ;-) ). This is especially noteworthy since Mojarra is widely used out there – in fact it is the standard library used e.g. in JBoss AS 7.

    Unfortunately I can’t present any numbers regarding the effect of composite components on performance. Our experience with this is based on observations made in our day-to-day business. A follow-up focusing on the effects of putting stuff in composites, tags or just raw EL expressions in facelets would be very interesting and I expect to see big differences between the implementations again. We don’t have plans for such a benchmark (yet) but maybe there are others that like to come up with some numbers…

    Thank you for adding a valuable view from an implementors perspective with your detailed comment. You and the MyFaces Team are doing a great job and I am glad you shared your opinion on this.

  3. Pingback: JSF Performance Tuning | techscouting through the java news

Leave a Reply