[
https://jira.jboss.org/jira/browse/RF-5383?page=com.atlassian.jira.plugin...
]
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