MyFaces performance investigation from a client point of view

[Werner Punz <we...@gmail.com>]

Hello everyone since I was working on it anyway I did some performance 
investigations of one of my testcases (a dialog box utilizing jquery
and doing some refreshes within and outside of it.

Besides that I discovered that we were far behind mojarra peformancewise 
(I recently made performance mesurements on the body replacement part 
where the difference was better on our side, but a load has changed 
there as well), which I now have mostly fixed for that case  I 
discovered some interesting stuff.

First I raised an issue for it under

https://issues.apache.org/jira/browse/MYFACES-2797

By resolving it we gained about 30-40% of raw exection performance, for 
a simple often triggered update case we are about 10% slower than 
Mojarra on the raw javascript execution, but our code works on 
absolutely all desktop browsers including ie6 while Mojarra failed the 
testcase on opera and chrome (probably any webkit based browser)


Note this is for a small html to medium sized html replacement case. We 
probably gain speed on bigger replacements if the server delivers on 
equal ground, due to browser optimizations, we have on dom level.

Anyway:

There are a multitude of performance problems, the ones on my side 
hopefully are mostly fixed. I now can live with the performance 
difference given that we do way much more and probably have it easier 
with maintenance in the future.

The biggest issue was that Mojarras jsf.js was almost twice as fast as 
ours, I pushed the difference down to some 10-15%. The biggest culprit 
was that Mojarras code entirely failed on Webkit and Opera for the 
testcase, while ours worked.

The difference now can probably be attributed to following things after 
the performance update. We are more modularized and have an oo layer 
which also costs some performance (not too much but nevertheless), we 
have a load of browser fixes and solve things probably differently to be 
absolutely safe in seldom corner cases, can deal with control 
detachments, cross form submits submits against controls with embedded 
forms, pps etc..

Mojarra obviously does not have all this, (otherwise it would not have 
failed on chrome and opera) which attributes to another load of 
indirections and code.

Nevertheless after spending the day on performance tweaking we are on 
our side now at an acceptable level for this case (which is small to 
medium sized ppr updates)

The bigger performance difference now is caused by the server which 
attributes to 95% of the refresh.
The biggest issue I could discover from the client, is our rendering of 
way too much inline scripts.

While Mojarra renders for a form update or generally a form only the raw 
html code and some helper functions included separately, we inline the 
oamsubmit functions constantly blowing our page up. While this is not 
bad for normal cases (still costs rendering performance), the oam 
function adds on my side another 10-15% performance loss on dom 
replacement level if a target is refreshed which causes them to be 
rendered.

Another performance shortcut Mojarra seems to take is on ViewScoped 
beans, we restore the bean constantly at every ppr request which does 
something on a viewscoped bean, mojarra seems to take a shortcut here. 
You can see that by using a ViewScoped bean in myfaces the 
deserialisation in the bean is called at every ajax request, in mojarra 
it is not.

I just wanted to post this since people work on performance issues on 
the server side as well.

Werner

Re: MyFaces performance investigation from a client point of view

[Werner Punz <we...@gmail.com>]

Am 09.07.10 08:23, schrieb Ganesh:
>>  Mojarra renders for a form update or generally a form only the raw
>> html code and some helper functions included separately, we inline the
>> oamsubmit functions constantly blowing our page up. While this is not
>> bad for normal cases (still costs rendering performance), the oam
>> function adds on my side another 10-15% performance loss on dom
>> replacement level if a target is refreshed which causes them to be
>> rendered.
>
> Do you see any chance to remove the oam stuff? Mojarra does a simple
> type="submit" and only adds an onclick in the ajax case.
I have not looked deeply into the oamsubmit, afaik they mainly map the 
corresponding commandButton/commandLink to the proper jsf version syntax 
for the decode phase so that the actionEvent can be issued.
Also I think they take care about the scroll to functionality.
But I think oamSubmit can be moved into something on resource level just 
like mojarra has done with mojarra.ab (which I think is something 
similar) and then being included automatically.

I think the problem is no one has touched the code for ages.


 >> Another performance shortcut Mojarra seems to take is on ViewScoped 
 >>beans, we restore the bean constantly at every ppr request which does 
 >>something on a viewscoped bean, mojarra seems to take a shortcut 
 >>here. You can see that by using a ViewScoped bean in myfaces the 
 >>deserialisation in the bean is called at every ajax request, in 
 >>mojarra it is not.

 >I know page, request and session scope. Which one are you referring to?

Page Scoped beans, the page scoped beans are constantly savestated per 
request, probably due to being able to preserve the history. Whether 
this makes sense from a performance point of view is another question 
(as well as it makes the entire aspect of dataset -service layer 
handling way more difficult than it needs)

Re: MyFaces performance investigation from a client point of view

[Ganesh <ga...@j4fry.org>]

Hi,

> While Mojarra renders for a form update or generally a form only the raw 
> html code and some helper functions included separately, we inline the 
> oamsubmit functions constantly blowing our page up. While this is not 
> bad for normal cases (still costs rendering performance), the oam 
> function adds on my side another 10-15% performance loss on dom 
> replacement level if a target is refreshed which causes them to be 
> rendered.

Do you see any chance to remove the oam stuff? Mojarra does a simple type="submit" and only adds an onclick in the ajax case.

> Another performance shortcut Mojarra seems to take is on ViewScoped 
> beans, we restore the bean constantly at every ppr request which does 
> something on a viewscoped bean, mojarra seems to take a shortcut here. 
> You can see that by using a ViewScoped bean in myfaces the 
> deserialisation in the bean is called at every ajax request, in mojarra 
> it is not.

I know page, request and session scope. Which one are you referring to?

Best regards,
Ganesh

Re: MyFaces performance investigation from a client point of view

[Kito Mann <ki...@virtua.com>]

Great work, Werner. It's good to know how things stack up performance-wise,
and which areas can be improved.
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3

Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17



On Thu, Jul 8, 2010 at 11:06 AM, Werner Punz <we...@gmail.com> wrote:

> Hello everyone since I was working on it anyway I did some performance
> investigations of one of my testcases (a dialog box utilizing jquery
> and doing some refreshes within and outside of it.
>
> Besides that I discovered that we were far behind mojarra peformancewise (I
> recently made performance mesurements on the body replacement part where the
> difference was better on our side, but a load has changed there as well),
> which I now have mostly fixed for that case  I discovered some interesting
> stuff.
>
> First I raised an issue for it under
>
> https://issues.apache.org/jira/browse/MYFACES-2797
>
> By resolving it we gained about 30-40% of raw exection performance, for a
> simple often triggered update case we are about 10% slower than Mojarra on
> the raw javascript execution, but our code works on absolutely all desktop
> browsers including ie6 while Mojarra failed the testcase on opera and chrome
> (probably any webkit based browser)
>
>
> Note this is for a small html to medium sized html replacement case. We
> probably gain speed on bigger replacements if the server delivers on equal
> ground, due to browser optimizations, we have on dom level.
>
> Anyway:
>
> There are a multitude of performance problems, the ones on my side
> hopefully are mostly fixed. I now can live with the performance difference
> given that we do way much more and probably have it easier with maintenance
> in the future.
>
> The biggest issue was that Mojarras jsf.js was almost twice as fast as
> ours, I pushed the difference down to some 10-15%. The biggest culprit was
> that Mojarras code entirely failed on Webkit and Opera for the testcase,
> while ours worked.
>
> The difference now can probably be attributed to following things after the
> performance update. We are more modularized and have an oo layer which also
> costs some performance (not too much but nevertheless), we have a load of
> browser fixes and solve things probably differently to be absolutely safe in
> seldom corner cases, can deal with control detachments, cross form submits
> submits against controls with embedded forms, pps etc..
>
> Mojarra obviously does not have all this, (otherwise it would not have
> failed on chrome and opera) which attributes to another load of indirections
> and code.
>
> Nevertheless after spending the day on performance tweaking we are on our
> side now at an acceptable level for this case (which is small to medium
> sized ppr updates)
>
> The bigger performance difference now is caused by the server which
> attributes to 95% of the refresh.
> The biggest issue I could discover from the client, is our rendering of way
> too much inline scripts.
>
> While Mojarra renders for a form update or generally a form only the raw
> html code and some helper functions included separately, we inline the
> oamsubmit functions constantly blowing our page up. While this is not bad
> for normal cases (still costs rendering performance), the oam function adds
> on my side another 10-15% performance loss on dom replacement level if a
> target is refreshed which causes them to be rendered.
>
> Another performance shortcut Mojarra seems to take is on ViewScoped beans,
> we restore the bean constantly at every ppr request which does something on
> a viewscoped bean, mojarra seems to take a shortcut here. You can see that
> by using a ViewScoped bean in myfaces the deserialisation in the bean is
> called at every ajax request, in mojarra it is not.
>
> I just wanted to post this since people work on performance issues on the
> server side as well.
>
> Werner
>
>
>
>
>
>