--- Gerhard Froehlich <[EMAIL PROTECTED]> wrote: > 6) Look at the store parameters > (store,store-janitor,...) in the > cocoon.xconf file and customize them -as recommended > in the comments- for > your testing machine(s).
This is one of the most important things to get right. The other thing I found to have a significant improvement on scalability was setting the -Xnoclassgc parameter on the Sun JDK 1.3.1--if I understand the documentation for this option correctly, it reduces the frequency of need for garbage collection by permitting the memory allocated to unused classes to be reused (instead of having to be collected and/or compacted). Less fragmentation means less collection means better response times. My particular experience with RC1 was that performance degrades over time under high stress--not clear if it is my particular app or XSPs in general. With 10 simultaneous threads hitting the same page, requests 1-500 perform lightning fast, 500-100 about 50% slower, and then from there on out gradually slowing down even further until a significant drop in load occurs. I've also found that *not* specifying an -Xms parameter seems to improve performance as well. That could be because I don't have the store janitor settings right, but I did see mention on an IBM site that suggested this for some cases. Finally, turn on the verbose garbage collection JVM options to see if there are issues with too much GCing. For the long term, let me make two proposals: 1) Would it make sense to start a document, either as part of the Cocoon document base, or as part of the Complete Idiot's Guide to Cocoon, of the best practices for tuning an application? I think we all have our tips and tricks we could collect, and based on the periodic complaints that come up in cocoon-users about performance, it might be a useful guide. I can start collecting info and putting something together with a little guidance on where it should reside, format, etc. And of course, your best suggestions. 2) In observing the verbose GC messages and behavior under stress, I got to thinking about whether it would make sense to add a feature to the janitor that caused a full GC after a given period of idle time (regardless of the current memory state)? The goal would be to reduce the probability of those nasty full GC calls (which can hang the server for long periods of time) hitting during peak load times by keeping the decks clean during idle times. If the server has been idle for a minute (or a time interval specified in the cocoon.xconf) do a GC. If you have bursty sets of requests, the pending cleanup can be like a timebomb waiting for the next request to cause all the clean up and GC to occur. By trying to distribute some of this "deep cleaning" into the idle times, we might be able to avoid some of the nasty requests. Or, it could be that I still haven't figured out the best way to set the janitor settings. ;) In which case, see suggestion 1. Chris __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
