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:[EMAIL PROTECTED]]
> Sent: Wednesday, August 22, 2001 4:57 PM
> To: [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> >For additional commands, email: [EMAIL PROTECTED]
> >
>
HTMLSerializer.diff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
