myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Andraschko <andraschko.tho...@gmail.com>
Subject Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x
Date Fri, 13 Dec 2013 08:51:02 GMT
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