myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dora Rajappan <dorarajap...@yahoo.com>
Subject Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x
Date Fri, 13 Dec 2013 13:42:35 GMT
Not bad +1 for view pool. 
 
When VIEW_POOL_ENABLED the param  org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is
not considered and not required to set.
org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is valid for state saving client/server.
 
Regards,
Dora Rajappan.



On Friday, December 13, 2013 2:21 PM, Thomas Andraschko <andraschko.thomas@gmail.com>
wrote:
  
Cool leo! Thanks for your effort :)





2013/12/13 Leonardo Uribe <lu4242@gmail.com>

Hi
>
>Finally the code for View Pooling has been comitted. After some performance 
>tests with the know demo application, it has been confirmed the following 
>improvements: 
>
>- A reduction of 25% of the transient memory used, which means a lot less 
>memory is used and it is used at a slower pace. It also means less GC calls
>and a better CPU usage.
>- An improvement of 9% over throughput for non ajax requests. 
>- An improvement from 9% to 30% or even more for ajax request, according to
>the tree size.
>
>These improvements are very good and justify the use of the view pool. But
>in order to be transparent and open with the community we have not explained
>the details behind how the view pool really works. So, I created a blog 
>about this topic that I hope to move it into MyFaces documentation once
>a release of 2.2.0 is out (we have some pending work to do in the 
>documentation area, so I hope to do everything in one step).
>
>http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html
>
>The blog summarize all information about this topic, its origins,
>the reasons behind them and the solution proposed, so we can discuss it later
>if there is any doubt or critic about it. It is a long story but this is 
>something we need to document properly.
>
>regards,
>
>Leonardo Uribe
>
>
>
>
>2013/12/9 Leonardo Uribe <lu4242@gmail.com>
>
>Hi
>>
>>It seems we have an inconsistency between what was proposed to enable the view pool
and the inclusion of the new parameter.
>>
>>At start we have this:
>>
>>
>>org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in the app, by
default false)
>>
>>
>>
>>But if we use an attribute in f:view like "oamEnableViewPool", aiming to select the
views that will use the pool, the previous param does not look good because it overlaps the
attribute.
>>
>>
>>In this case, I think it is better to keep things simple and remove the web config
param and let the pool to be enabled only through the attribute or the entry in faces-config-extension.
I'll do that.
>> 
>>
>>regards,
>>
>>Leonardo Uribe
>>
>>
>>
>>
>>
>>2013/12/9 Thomas Andraschko <andraschko.thomas@gmail.com>
>>
>>Hi Leo,
>>>
>>>sounds fine! thanks :)
>>>
>>>
>>>
>>>
>>>2013/12/9 Leonardo Uribe <lu4242@gmail.com>
>>>
>>>Hi
>>>>
>>>>
>>>>I think we could add it as a parameter for f:view tag, for example call it
oamEnableViewPool. The patch proposed uses already an attribute for disable the pool in some
cases, but after doing some experiments (MYFACES-3831) I have found we need to change some
parts of the algorithm. Specifically I have found that it is not really necessary the check
to disable the pool when VariableMapper  is used because with the code we have in place there
is no way an EL expression should not be the same each time the view is built.
>>>>
>>>>
>>>>A phaselistener is not necessary. I think the best place to set the param
manually is ViewHandler.createView(...).
>>>>
>>>>
>>>>
>>>>regards,
>>>>
>>>>
>>>>Leonardo Uribe
>>>> 
>>> 
>> 
> 
Mime
View raw message