myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rohit Dilip Kelapure (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Comment Edited] (MYFACES-3586) Performance improvement in Resource loading - HIGH CPU inflating bytes in ResourceHandlerImpl.handleResourceRequest
Date Thu, 26 Jul 2012 20:03:34 GMT

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

Rohit Dilip Kelapure edited comment on MYFACES-3586 at 7/26/12 8:01 PM:
------------------------------------------------------------------------

Increase scalability and performance of JSF Resource handling code by caching the output of
static  resources.
Patch has been built on the 2.0.x trunk stream.
                
      was (Author: kelapure):
    Increase scalability and performance of JSF Resource handling code by caching the output
of static  resources
                  
> 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.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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message