cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vgritse...@yahoo.com>
Subject RE: IT'S TIME TO REDO YOUR TESTS, GENTLEMEN!
Date Thu, 23 Aug 2001 03:26:07 GMT
Does not work :( 
Can't pool this stuff......

Vadim

> -----Original Message-----
> From: Vadim Gritsenko [mailto:vgritsenko@hns.com]
> Sent: Wednesday, August 22, 2001 5:23 PM
> To: cocoon-dev@xml.apache.org
> Subject: RE: IT'S TIME TO REDO YOUR TESTS, GENTLEMEN!
> 
> 
> Gerhard,
> 
> Could you please try test again with the patch I attached?
> I would appreciate to hear load test results with this patch :)
> 
> Vadim
> 
> > -----Original Message-----
> > From: Gerhard Froehlich [mailto:g-froehlich@gmx.de]
> > Sent: Wednesday, August 22, 2001 4:57 PM
> > To: cocoon-dev@xml.apache.org
> > Subject: AW: IT'S TIME TO REDO YOUR TESTS, GENTLEMEN!
> > 
> > 
> > Hi,
> > just running another load tests against cocoon with the latest
> > sources. I set up the testing like berin recommended in his posting.
> > I didn't get memory issues anymore. memory consumption was always
> > a little bit higher then initial heap-size and constant.
> > 
> > The only thing I worry is the cpu load on my machine (AMD 1,2GHZ). Only
> > 5 simultaneous threads are enough to eat 90% percent cpu time on my machine.
> > I tried to trace down the problem (but this are really suppositions and
> > they're superficial. I have no time to get deeper this days. In the autumn I
> > will
> > take a longer rest from paid-work, only for cocoon of course :-)):
> > 
> > According to my tracing tool (OptimizeIT) most of the cpu time was consumed
> > by the method java.util.ZipFile.open(). As I traced down the thread
> > the first "core" method from cocoon I hit in this tree of method invocations
> > was the process() method of the CachingPipline. Ok that's plausibly of
> > course.
> > But the load is caused through the ClassLoaders, which I suspect unzip the
> > jar files of the libaries, which are used from the different serializer,
> > transformers,... Is this inevitabile? Or can some caching of already loaded
> > classes help on this problem, if it is possible? Or is this a general java
> > problem?
> > 
> > Attached are the report file of my load test and the tracing of
> > java.util.ZipFile.open().
> > I don't want to blame anybody, I just want to participate somehow.
> > 
> > Nice evening
> > 
> > Cheers
> > Gerhard
> > >Cocooners,
> > >
> > >Yesterday I fixed to major memory leaks:
> > > - one is with SitemapSource not releasing pipelines
> > >   (no memory leaks in aggregation!),
> > > - another with mrulist in MRUMemoryStore.
> > >
> > >Right now I have CLI running for >12 hours, it processed >35000 pages,
> > >and still no trace of memory problems.
> > >
> > >When doing your tests (esp. load tests), do not forget to adjust
> > >pool sizes (see Berin's response on "LoadTest" thread), and also
> > >please make sure that "heapsize" attribute of MRUMemoryStores is
> > >between -Xms and -Xmx.
> > >
> > >Vadim
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > >For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> > 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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


Mime
View raw message