[ 
https://issues.apache.org/jira/browse/MYFACES-3586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599392#comment-13599392
 ] 

Leonardo Uribe commented on MYFACES-3586:
-----------------------------------------

I would say the patch is ok to commit it, but the solution using a memory cache 
still doesn't sound too convincing. The reason is this looks just like 
replicate the same work done in apache server, so if you really need something 
like that, do the logic in apache server.

Anyway, if there is no objections, I can commit the code and include it in the 
next release. The patch suppose include a web config param:

org.apache.myfaces.TEMPORAL_RESOURCEHANDLER_CACHE_ENABLED

by default false to enable/disable it. 

In theory the patch "as is" is ok and becomes useful, but I would like to hear 
other opinions, to see how far is really necessary to go.

                
> Performance improvement in Resource loading - HIGH CPU inflating bytes in 
> ResourceHandlerImpl.handleResourceRequest
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: MYFACES-3586
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3586
>             Project: MyFaces Core
>          Issue Type: Improvement
>         Environment: ALL
>            Reporter: Rohit Dilip Kelapure
>         Attachments: MYFACES-3586-1.patch, MYFACES-3586.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> In a high concurrency load test with Apache MyFaces + RichFaces component 
> library we found that under peak load majority of our web container threads 
> were stuck in this call stack 
> at java/util/zip/Inflater.inflateBytes(Native Method)
> at java/util/zip/Inflater.inflate(Inflater.java:249(Compiled Code))
> at 
> java/util/zip/InflaterInputStream.read(InflaterInputStream.java:146(Compiled 
> Code))
> at 
> java/util/zip/InflaterInputStream.read(InflaterInputStream.java:116(Compiled 
> Code))
> at java/io/FilterInputStream.read(FilterInputStream.java:77(Compiled Code))
> at java/io/FilterInputStream.read(FilterInputStream.java:77(Compiled Code))
> at java/io/PushbackInputStream.read(PushbackInputStream.java:133(Compiled 
> Code))
> at 
> org/apache/myfaces/shared_impl/resource/ResourceImpl$ValueExpressionFilterInputStream.read(ResourceImpl.java:117(Compiled
>  Code))
> at java/io/InputStream.read(InputStream.java:175(Compiled Code))
> at java/io/InputStream.read(InputStream.java:97(Compiled Code))
> at 
> org/apache/myfaces/application/ResourceHandlerImpl.pipeBytes(ResourceHandlerImpl.java:402(Compiled
>  Code))
> at 
> org/apache/myfaces/application/ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:357(Compiled
>  Code))
> at 
> org/richfaces/resource/ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:257(Compiled
>  Code))
> at javax/faces/webapp/FacesServlet.service(FacesServlet.java:183(Compiled 
> Code))
> at 
> org/richfaces/webapp/ResourceServlet.httpService(ResourceServlet.java:110(Compiled
>  Code))
> at 
> org/richfaces/webapp/ResourceServlet.service(ResourceServlet.java:105(Compiled
>  Code)) 
> After looking at the src code of  
> org.apache.myfaces.application.ResourceHandlerImpl.handleResourceRequest(FacesContext)
>   I can see that the ResourceHandlerCache caches the Resource metadata ; 
> however the actual output of the resource which is written to the 
> outputstream in ResourceHandlerImpl.pipeBytes is NEVER cached. 
> This causes a scalability problem in our case because each access to the 
> resource involves cracking open a jar, inflating the bytes and parsing a 
> stream of bytes. This is done multiple times for the same resource(say a css 
> file) inside the richfaces jar inspite of the resource not changing. 
> I propose a much needed performance optimization wherein we cache the output 
> of the Resource handled and stash the output byte[] it as softReference in 
> the ResourceHandlerCache.ResourceValue. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to