myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shasi Mitra Yarram <shasimi...@yahoo.com>
Subject JSF Performance and Scalability issues
Date Mon, 07 Sep 2009 15:45:28 GMT
We have developed an application..These are the technologies we've used: 
- JDK 1.4.2 
- JSF 1.1 (Myfaces 1.1.6) 
- Ajax4JSF 1.1.1 
- Tomahawk 1.1.8 
- Tiles 2.1.0 
- Spring 2.5, Spring Security for security layer 
- iBatis 2.0 

Databases: 
- SQL Server 2000, DB2 8, Sybase 

Servers: 
- IBM Websphere 6.0 - JVM memory min - 64MB, max 512MB 
- IBM MQ Series 6.0 
- IBM AIX UNIX, load balacing on 2 servers (Clustered environment), Each unix box has 2 CPUs


Our application uses MQ for lot of business transactions. It is dependent more on MQ than
the database. Among the databases, SQL Server is the main database. DB2 and Sybase is used
for few transactions. 
This application is supposed to take a load of 1000 users in production and give us a response
time of 10 secs. 

As we started with load testing we saw poor response time. We did profiling using Jprofiler
and corrected some inherent application bugs which was causing high JVM utilization. 
As we reached 250 user load, myfaces started eating memory (This was revealed by heap dump).

We tuned myfaces based on various websites and did the following: 
1) State saving mechanism as "server" 
2) Number of views as 3 
3) Streaming resource org.apache.myfaces.component.html.util.StreamingAddResource with t:documentHead

4) Set org.apache.myfaces.SERIALIZE_STATE_IN_SESSION as false. 

By adding the above code, it improved the performance only a bit. 
I later wrote some filters to cache the images and css files. This improved the screen load
performance a bit. 

But the overall response time was not upto the benchmark. We were getting a response time
of 20 secs for 250 user load. We are far from achieving the response time for 1000 user load.

We got the heap dump once again but we saw myfaces continued to eat memory. The object in
heap that is causing the trouble is JspStateManagerImpl$SerializedViewCollection 
I saw in some website that this object tries to save the old view states in some weak hashmap
which nevers gets garbage collected. Thought that could be 
the problem. I found a fix in the website and replaced the corrected jars. Now JspStateManagerImpl
is not storing old views in weak hashmap. 

This actually helped a bit. It reduced the memory utilization. 

But When we run for 500 users, heap dump still shows JspStateManagerImpl object is eating
(Approx 1.6MB). 
I am not sure if 1.6MB size in heap is normal for 500 users!!! 

I know the screen size also makes a lot of difference to give a conclusion upfront. 

But let me provide more information. 
On an average we use 25 components. 

Each screen has list of selectitems for a drop down. The select items is inturn refered by
a managed bean in session. 

Apart from the above object in session, we store only 3 managed beans in session. These managed
beans carry menu and user information. 
JSCookmenu inturn reads the menu object in session and renders the output for every screen.


I wrote a session size calculator jsp to find the size of each of these session objects. 
They are hardly 20~30KB. But JspStateManagerImpl object in session is easily 150KB min. Sometimes
it goes above 450KB. 

We use tomahawk savestate to store some object information. 

I should accept that we do use EL expression statements in many of our screens. 

We have limited usage of datatables. But wherever we have used, we have done managed bean
(in request scope) binding with preservedatamodel as true. 

Wherever JSF components were not needed, we used pure HTML tags enclosed withing f:verbatim.


Each page contains atleast 4 command buttons. Each command button is supposed to call some
other managed bean and render those screens. 
This means apart from the main managed bean, when the screen is rendered the beans referred
by these buttons are instantiated. 
Of course all these managed beans are in request scope. 

Most of the components in our screen use "rendered" attribute to perform some business function.


Now my question is, did I miss anything else in myfaces? Did i miss anything that could help
me tune JSF further? 
Our constraint is we cannot move to JDK 1.5 (which means JSF 1.2 or higher) as it will be
a big infrastructre cost to our clients. 

I know the problem for poor response time could also be due to database, MQ and others. We
are working on them parallely. 
But I want to eliminate all JSF related issues from the picture. 


      Love Cricket? Check out live scores, photos, video highlights and more. Click here http://cricket.yahoo.com
Mime
View raw message