Performance of JFS2

[wildrook]

Hello,

We use Richfaces in quite big project (about 35.000 visitors per day) www.buho21.com and recently migrated from 3.3.0 GA to 3.3.3 CR1 with JSF 2 support. Great work guys! We almost have no problem with CR1, everything works Ok, but we don't find any improvements in performance :-(

JSF is too expensive parsing and store XML views.

My questions are:

1. Is JSF 2 in 3.3.3 support Partial State Holder? Memory consumption still the same, views consumes a lot of memory on server side, or probably we do something wrong.

2. Is it possible to configure your own state manager in JSF2? Seems that in 3.3.3 <state-manager> tag is ignored in faces-config.

3. Will Richfaces 4.0 be better in performance than 3.3? And in general what recomendations, best practices you can recomend to optimize performance (cpu and memory)?

Thank you in advance! Good job!

[wildrook]

Forgot to add: we use Mojarra implementation.

[nbelaevski]

Hi Anton,

1. Is JSF 2 in 3.3.3 support Partial State Holder? Memory consumption still the same, views consumes a lot of memory on server side, or probably we do something wrong.

Here is the excerpt from partial state saving parameter documentation: "For applications versioned at 1.2 and under, the runtime must not use the  partial state saving mechanism". As 3.3.3 is using JSF 2.0 in back compatibility mode (i.e. versioned as 1.2 application), partial state saving is not used.

2. Is it possible to configure your own state manager in JSF2? Seems that in 3.3.3 <state-manager> tag is ignored in faces-config.

Yes, it is possible to configure your own state manager for JSF2 with 3.3.3. It is recommended to use/extend org.ajax4jsf.application.AjaxStateManager, as it sets special flag for JSF2 state manager when RF AJAX request happens.

3. Will Richfaces 4.0 be better in performance than 3.3? And in general what recomendations, best practices you can recomend to optimize performance (cpu and memory)?

Definitely yes! We are going to remove xHTML parsers that are correcting response + another performance optimizations.

P.S. Please take a look: http://in.relation.to/Bloggers/JSF20RoadmapForRichFaces

[ilya_shaikovsky]

according to possible optimizations using current version:

At first I was pretty wondered why do you tell that performance is pretty bad I saw much more simplier sites which worked much more badly. I must admit that you implementation looks pretty good from performance point of view especially if this just one of the first versions. Maybe I missed some cases with real problems while checking? Point me then to them.

First points which I quickly see which could be improved:

• you could use the scripts and styles from single pack instead of loading all the resources separatelly. (look for our load script and styles strategies)
  • additionally you could even create packs of resources which contains only resources needed by your application using richfaces maven dependency plugin. But in this case you will have to pack them on your own.
• you could use css sprites for your images used in styles

B.t.w. feel free to use uor RF in production page http://community.jboss.org/wiki/RichFacesInProduction

[wildrook]

Thank you very much for your answer and suggestions!

As I told JSF has 2 performance problems: high memory consumption and cpu, compared to other web technologies such as JSP, ASP, PHP.

For instance website with 1.000 web open sessions could consume in JSP only some MBytes of memory (or nothing depends on a design of your session object), but JSF technology by default requiers GBytes of memory for highload sites, because stores all views in a session object. One visitor can open many pages during their session, so there is a strong limitation for session time and number of views per session. We solved this problem implementing our own State Holder which stores more requested views in a memory and other views in a hard drive in compressed format, this is not very good solution, but works fine. We can do nothing regarding the CPU load, because of forced xml parsing for each request, only we had to buy better servers :-)

Seems that 4.0 will solve some performance problems, observing how you work I have no doubt that JSF is a right choice for websites.

[armdev]

Hello, I start use JSF 2.0 implementation from Apache Myfaces, integrated with Tomahawk, PrimeFaces and PrettyFaces.

I wait richfaces 4 for integrating. But I need more information about JSF 2.0 performance. JSF 1.2 used a lot of memory in application where I use 99%

requests bean.

But I want develop big application for web and not only corporate sites. And how we can imrove performance, is JSF 2 better than JSF 1.2?

If I integrate richfaces it will start use his State Manager? If we use requests beans or view scope beans is JSF will not use a lot of memory?

Have you best configuration example for JSF 2.0???

However I think performance problem not only web framework problem. If we want use a lot of components/validators/converters we must use also a lot of memory for it. But for a lot of users we will have problems....

Thank you

[bitec]

Anton, hi

Having the real problems with memory in JSF 2.0 application. Have you managed to solve them? Did partial state saving help a lot?

What about using partial state saving together with client safe mechanizm?

Thanks

[jbosscommunity13]

Hello together,

we are writing the year 2012, 15 of July... more than 2 years passed by when this forum-thread started.

We do have tremendous CPU / Memory problems since we migrated to JSF 2.0

Same application, but with JSF 2 (2.1.11Mojarra Impl) and lateste Richfaces 4.2.2.Final.

So far I wrote a lot of Code for analysis and spend many hours on JConsole for Analysis.

In former times a quite simple page that takes customerdata (first Name, last Name, birthday,...) it would take JSF 1.2 (with no other parallel requestes) about 10-15 ms for RESTORE VIEW and RENDER RESPONSE.

Same page today with JSF 2 will take for the same job 200 ms for RESTORE VIEW and 60 ms for RENDER RESPONSE.

When I do paralleTests this has an too strong impact on usability of our application!

For our next rollout, we are forced to go back on JSF 1.2 to keep up Service Level Agreements.

So, what is the solution for better performance? Buy more and faster hardware?

Is that realy it?

Is it just a fact that you need factor 5 or 6 times stronger hardware?

I 've read in a forum that with JSF 2 the Tree is build from scratch everytime! the getter and stetters are cold 6 times! so there is much more going on in restore view...

Does anybody have a possible soultion how to speed up Restore View?

Please take in consideration that at the end all we are trying to do is take 10 input fields from a html:form into our backing Bean.

If I programmed that with Servlet getParameter it would take 1ms.

Abstraction at a high price?

Any experiences to share welcome...

[lfryc]

Hey jbosscommunity13,

we would love to hear from you where the performance bottleneck is based.

In fact, it does not have to be caused by RichFaces, but rather JSF implementation you use.

Please, do a nice work and profile your application and report your findings.

If you will find a cause of bottleneck, you can reach us, discuss a way to change implementation?

In the end, nothing prevents you to send us a patch - this is truly open-source project:

https://community.jboss.org/wiki/ContributorGettingStartedGuide

Does anybody have a possible soultion how to speed up Restore View?

Yes, you can go stateless:

http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/

It would need rewriting lot of parts of your model to back component's state.

This or helping us improve libraries (RF, JSF) you base your work on.

~ Lukas

[jbosscommunity13]

Hi Lukas,

thank you very much for this stateless hint. I think it could be the right way. It works really great! I experience some little hick ups, like <f:messageBundle var="msg"  will not work when I do ajax rerendering on Components like: <h:outputLabel var="#(msg.mylabel ....   which means that the jsf resources (properties) get inaaccessible by EL.

The other thing is, that besides I do unerstand the concept of stateless, we do need a mechanism to simulate ViewExpiredException, because we dont want users to go backwards in the browser and get submited old contents just like that, what is happening right now.

Have you used this stateless workaround and could accomplish all your needs?

We are concernec about letting a team of Developpers that basically know JSF trap into something that they cant explain how it works, leave the standard path.

In our experiences Richfaces being on top of Jsf, is not the cause of the performance problems

We did profilings and we saw the bottleneck immediatly in "restoreView" and "renderResponse" independet if we had richfaces components or not.

Strangely sometimes we had  20ms between an afterPhase of JSF and the following beforePhase of JSF and were wondering what was going on in between to neighbour Phases ???

we strapped down pages to find single point of failures, but thr trueth is, that with every single Component less in the ViewTree the speed got better. When I strapped down to 1 single UiInout Field, performance was best, so the behavior was really linear. And still even with the smallest site the restore view was too long. 20 ms, thats waht we needed in JSF 1.2 for restore view AND render response with all fields and not just one.

A collegue debugged into mojarra and he just saw how long the tree was build.

Thats the way it is now, and we need a solution if we wanna go with JSF 2...

[jbosscommunity13]

Hi Lukas,

I found in the

Mojarra 2.1.12 Release Notes

http://javaserverfaces.java.net/nonav/rlnotes/2.1.12/whatsnew.html

[...]

Pluggable Facelet cache mechanism

This API allows the in-memory cache of Facelet instances to be served from a cache that can be overridden with a custom implementation.

[...]

is that the same direction? didnt find any usage examples...