(...)
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) http://memojo.com?page=SantiagoGalaBlog
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
