Hi: I don't know about J1 scalability issues, but HSQL does. Could the DB (in a slow computer and a JVM not optimized for memory) be the problem in this case?
"HyperSonic (HSQLDB): (...) Hypersonic was originally designed as an in-memory database; as a result, operations performed on tables that are larger than available memory tend to run very slowly. This scalability issue relegates Hypersonic to the requirements of small applications. " http://www.devx.com/IBMCloudscape/Article/21773/4165?pf=true Hypersonic works a client at a time: "With other database engines, connection pools are used for reasons that may not apply to HSQLDB. * To allow new queries to be performed while a time-consuming query is being performed in the background. This is not possible with HSQLDB as it blocks while performing the first query and deals with the next query once it has finished it. " http://hsqldb.sourceforge.net/doc/guide/ch04.html > -----Original Message----- > From: Dan Moore [mailto:[EMAIL PROTECTED] > Sent: Monday, November 15, 2004 7:04 PM > To: [EMAIL PROTECTED] > Subject: performance slowdown for 100,000 users, all with same PSML > > > Hi folks, > > I have an application I'm building on top of Jetspeed 1.5--I just > grabbed the WAR from portals.apache.org. The back end is an Oracle > database. > > I end up having around 100,000 users in the turbine_user table. All of > these users have the same PSML and they all have the same role; we're > using the role fallback mechanism. The PSML is stored on the > filesystem, under role/user/<language>/<country>; right now I'm only > using English and the US. > > I was seeing a massive slowdown in our application when we went from > the 3 sample users to the full 100,000, so I'm trouble shooting that. > The average page draw went from 4 seconds to 18 seconds (this is with 4 > simulated users hitting the home page at once). I was able to get > response times of around 4 seconds on my box (it's old and slow) with > the default jetspeed setup (just as downloaded from the site: > hypersonic db, only logging in as an anonymous user). > > I modified the JetspeedSessionValidator to log folks in with a cookie, > but that's the only code change I've made to the vanilla jetspeed war > I'm benchmarking (I profiled it and that method only adds 300 > milliseconds or so). I did make two configuration changes: > > automatic.logon.enable=true > > database.default.maxConnections=20 > > I took a look at this page: > http://nagoya.apache.org/wiki/apachewiki.cgi?JetspeedPerformanceTips > but didn't really notice any huge gains (I did up the number of > connections allowed in TurbineResources.properties and > Torque.properties). In addition, it seems that many of the suggestions > have been incorporated into the defaults. > > The turbine_user and turbine_user_group_role tables have their standard > indices. > > I'm trying to figure out where the extra 15 seconds comes from. I > guess I'm not so concerned about the absolute time it takes (we're > going to deploy on much faster hardware), but I do want to get the > ratio down. > > From just watching the page draw, it seems that the top gets drawn > quickly, then the actual portlets themselves are slow. I see warnings > in the logs about the specific psml files not being found for a given > user--are these a significant slowdown? Should I change > services.Profiler.fallback.country > and > services.Profiler.fallback.language > to be false? > > For one PSML file, is db based PSML a better choice? Is there some > caching that I can turn on that isn't on by default? Is simpler PSML > going to cause any kind of speed up? > > I also searched the mailing list for performance related issues. I saw > this > (http://nagoya.apache.org/eyebrowse/ReadMsg?listName=jetspeed-user @jakarta.apache.org&msgId=1640251) which I plan to try tomorrow morning, but didn't see any other things I should be doing. Any help would be most appreciated. Thanks, Dan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
