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.
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.
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.
Our initial estimation regarding the impact of large component trees on a JSF applications performance were verified by the test results. We found that
- 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.
- 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.
- 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.
- 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.