cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Finn <yarnfish2...@yahoo.com>
Subject RE: Cocoon 2.0 Scalability Disappointment
Date Fri, 30 Nov 2001 19:45:28 GMT
--- Gerhard Froehlich <g-froehlich@gmx.de> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message