cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
Subject RE: Cocoon 2.0 Scalability Disappointment
Date Sat, 01 Dec 2001 18:32:51 GMT
>-----Original Message-----
>From: Chris Finn [mailto:yarnfish2001@yahoo.com]
>
>--- 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.

As I did load tests with the RC1 I made the same experience.
With the help of OptimizeIt (http://www.vmgear.com/) I discovered
that most resource is burning the ClassLoader and stuff.
See thread http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=99857216131771&w=2

Berin was talking about a Active Monitor. But I don't know if
he implemented this.

>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.

Ok the "algorithm" is:
JVM.totalMemory() > Heapsize && JVM.freeMemory < Freememory
Heapsize and Freememory are the paramters from the cocoon.xconf
file.
If this is true the StoreJanitor kicks in, forces the gc() and
frees some Objects out of the stores.
See
   http://xml.apache.org/cocoon/userdocs/concepts/storejanitor.html
This document describes how to set the parameters.

>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.

Yeah something like a performance guide. Because every
release rises the same questions up ;).

>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.

I see, that's to consider. Maybe we should change this.
But it would be interesting the hear the other devs
to this issue.
But we should avoid to much active threads.

>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
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message