[richfaces-issues] [JBoss JIRA] Commented: (RF-5383) memory leakage issues during the load testing on rich faces version 3.2

[Alexander Smirnov (JIRA)]

    [ https://jira.jboss.org/jira/browse/RF-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12444618#action_12444618 ] 

Alexander Smirnov commented on RF-5383:
---------------------------------------

I've tested your application under profiler, and other as well. There is no memory leak, but common JSF state saving problem. My tests designed to use clean JSF implementation and RichFaces environment, thus I able to compare memory consumption for a both cases. RichFaces takes about 10% more for a state, but total trend is same as for a clean environment.
There are few suggestions for a performance tuning:

1) JSF components tree state takes big enough memory. In the server-side
state saving ( default JSF behavior ) these objects are stored in the
session. For a many concurrent user connections every user gets own
session object. Possible solution - switch to the client-side state saving.
    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>client</param-value>
    </context-param>

Other possible solution is Facelets behavior that allows to build view
before request processing instead of state saving, but that solution has
sometimes unpredictable side effects. Use web.xml init parameter
together with the <f:view transient="true" > attribute.
    <context-param>
        <param-name>facelets.BUILD_BEFORE_RESTORE</param-name>
        <param-value>true</param-value>
    </context-param>
As an intermediate solution, it is makes sense to create custom FaceletsViewHandler subclass with special state processing for a some pages like menus which does not depends for a saved state. That custom handler could call buildView method instead of real restoreView procedure for a such pages.
2) Facelets library in the "debug" mode stores information about
components and beans up to 5 times for an every user. To disable this mode:
    <context-param>
        <param-name>facelets.DEVELOPMENT</param-name>
        <param-value>false</param-value>
    </context-param>

3) Most filters use buffering for request processing. According to the
profile information, these buffers took big enough memory in the
application. I see a buffer-related parameter in the RichFaces Ajax filter:
        <init-param>
            <param-name>maxRequestSize</param-name>
            <param-value>100000</param-value>
        </init-param>
For a production server, it  makes sense to reduce value to a real page
size or remove that parameter at all.
4) TIDY xml filter is DOM-based, thus it requires a lot of memory. It
would be better to use more optimized "NONE" or "NEKO" one :
    <context-param>
        <param-name>org.ajax4jsf.xmlparser.ORDER</param-name>
        <param-value>NONE</param-value>
    </context-param>

Of course, production deployment have to disable all except "FATAL" log
messages, profiling utilities etc...

P.S This  is not a memory leak problem, but can prevent http session
swap or replication in a claster :
 Non serializable classes for a some session beans, for example:
com.emirates.jfoundation.client.core.contracts.SessionProperty.


> memory leakage issues during the load testing on rich faces version 3.2
> -----------------------------------------------------------------------
>
>                 Key: RF-5383
>                 URL: https://jira.jboss.org/jira/browse/RF-5383
>             Project: RichFaces
>          Issue Type: Bug
>    Affects Versions: 3.2.1
>         Environment: Weblogic 9.1/Jboss4.2.1/Tomcat6.0 on Windows/Linux
>            Reporter: jFoundation java
>            Assignee: Nick Belaevski
>             Fix For: Future
>
>         Attachments: tos-lite.war
>
>
> When we ran the load testing for richfaces UI that we developed with minimum load upto 60 users, there was no issue. But if we increase beyond that load, Heap reaches the maximum heap utilization (as configured in jvm settings) and started taking more time for GC (though GC is happening but very limited objects are getting cleared). once the accumulated space reaches the max heap and started throwing OutOfMemory issue. This is only happening in higher user load. When we did the Profiling, we could not figure out this issue since we were able to do profiling with 1 user load. 
> With reference to this  forum reply , the war file is added as an attachment. The the following scenario is used for load testing.
> Testing Scenario:
> Accommodation Basic Search:
> Open the TOS Application in browser 
> Login with user name as LOCALADMIN and password as LOCALADMIN. Note: both are case sensitive. 
> Open "Quotation & Booking" menu and click on Search Availability 
> Type 'C' in Client text box and select CL100 
> Select 'A' as the Business segment and 'A' as the contact person 
> Enter City name as "Dubai" 
> Click on Search button 
> Search result will be displayed. 
> Click on Logout in the top navigation 
>  
> Flight Search:
> Open the TOS Application in browser 
> Login with user name as LOCALADMIN and password as LOCALADMIN. Note both are case sensitive. 
> Open "Quotation & Booking" menu and click on "Search Availability AA" 
> Enter From city as "DXB", To city as "LON", Departure Date as "1 Jan 2009", Return Date as "2 Jan 2009" and Adults as "1" 
> Click on Search button 
> Search result will be displayed. 
> Click on Logout in the top navigation 
> This war file is tested on Tomcat 6.0.10 and jdk 1.6.0_10

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira