[
https://issues.apache.org/jira/browse/MYFACES-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896654#action_12896654
]
Michael Concini commented on MYFACES-2864:
------------------------------------------
After looking into this a bit further, it looks like there are two places of
particular interest where caching of resource URLs and paths will be useful for
performance.
First is the ResourceHandler and related classes, which I believe is what Leo
is referring to in his comments.
Second is caching around the viewhandler and restoreview support classes to
avoid having to execute the checkResourceExists calls.
My initial patch solves both cases, but potentially could introduce problems
since it affects all calls to ExternalContxt.getResource. Plus it only
partially solves the ResourceHandler case since it doesn't cache values looked
up via other ResourceLoaders besides the ExternalContextResourceLoader.
So, I think what is needed is separate caches for each case. Let me know what
you think and I'll start working on a new patch hopefully later today or
tomorrow. I think the ResourceHandler caching we would want to enable by
default using a ProjectStage check, but I'm open to going either way as to
whether the viewID caching should be default in ProjectStage.Production.
> Allow caching of resources by the default external context impl
> ---------------------------------------------------------------
>
> Key: MYFACES-2864
> URL: https://issues.apache.org/jira/browse/MYFACES-2864
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
> Affects Versions: 2.0.2-SNAPSHOT
> Reporter: Michael Concini
> Assignee: Michael Concini
> Attachments: MYFACES-2864-patch.txt
>
>
> We've seen in our testing significant improvements in performance by caching
> the results of getResource() and getResourcePaths() calls. Adding this
> caching has led to about a 30% increase in throughput on an older JSP
> application, and a doubling of throughput on JSF2/facelets applications that
> utilize templating and composite components. This testing was all done on
> WAS so gains could be different on other servers depending on the behavior of
> their servlet containers.
> In the patch I'm attaching, it currently sets that the default for the
> caching is enabled if the project stage is production and I've defaulted the
> cache size to 500 entries. I've created two context params that allow for
> overriding the size and/or disabling the cache outright.
> There might be a few cases where this will need to be disabled. Most
> prominently would be anyone who adds or removes files to a production
> environment. This could cause problems for an application that generates
> dynamic content on disk instead of in memory, although I don't know if that
> is common enough that we'd want to turn it off by default given the gains
> that the majority of users would see.
> Please review the patch and let me know if there should be any tweaks or if
> anyone feels strongly one way or the other about whether it should be enabled
> or disabled by default. I'll plan on committing Monday based on any consensus.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
