portals-jetspeed-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Jetspeed Performance tips
Date Fri, 21 Mar 2003 21:03:38 GMT
Shan Gopalakrishnan wrote:

>> About Spring 2001 some profiling and tuning was done, by the IBM team, 
>> David, Raphael and myself. I don't know of other such effort since 
>> then. This led to rundata and some other objects pooling in turbine, 
>> and some changes of String concatenation to StringBuffer.append(). We 
>> also discovered a lot of duplicated initializations and similar stuff. 
>> It is always funny to see how big bugs can hide in code.
> --------->> This really makes us think twice whether we can use it for 
> production. I would appreciate if profiling/tuning can be treated much 
> frequently to develop a healthy framework.  Hopefully some of our 
> results /analysis will help the development team.

We have a Jetspeed derivative running on a dual PentiumIII with 1GB of 
RAM and external DB. It is taking a sustained load of 600 sessions a 
day, with about 6000 portal page views a day.

We have yet to see a problem with it. You see normally loads around 2-3% 
on this machine. I think it can handle up to ten times the current load 
with no problem, and then we will start putting more "iron" to the task. 
We routinely restart tomcat to make minor changes (let's say every 7-15 
days). But otherwise it runs unnoticed

You should not plan for more than about 50-60% sustained cpu load. I 
would put a dual PentiumIII box for each 10 expected concurrent requests 
in the system. (as a rule of thumb). This will be more fault tolerant, 
as you can add/remove machines by just taking them out of the scheduler 
and waiting till sessions expire.

If a user asks for a page every minute, and service takes a second, 10 
concurrent requests mean 600 simultaneous users.

In all the experiments I have seen (always on 1GB dual PentiumIII 
machines), Jetspeed degrades sharply at about 50 concurrent requests, 
and this has not changed in the last year. You could be seeing the same 
behaviour, but scaled to your CPU, RAM and architecture. I would try to 
use less concurrent requests (at a sustained rate) to test the limits. 
Try several hours with 20, then 50, etc. Also, notice that the server 
hotspot VM needs time to see hotspots and optimize them, and during 
method compilation it actually slows down the whole system.

>> If the problem is that some "bunches" of objects get into "old" space 
>> because they are pointed by persistent objects, then a juditious 
>> ammount of "= null" on recycling can help a lot. I've just checked 
>> DefaultJetspeedRunData and it is disposed properly (unless something 
>> is broken down in Turbine and it is not really disposed).
> ----->>>Good point. I used to wonder how Jetspeed (team) will handle for 
> the inherent problems of Turbine ??

We can ask them to patch (in fact, David is committer in turbine-2) We 
have done it in the past, and will do it again if needed.

During some period Raphael had to patch turbine and we used a patched 
version, until we got the needed changes inside turbine.

> Thanks a lot for all your information.
> - Shan

Santiago Gala
High Sierra Technology, S.L. (http://hisitech.com)

To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org

View raw message