cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject RE: [C2] Loadtest
Date Mon, 20 Aug 2001 15:14:57 GMT
> Hi all, 
> I'm back from the dungeons of load testing. And I don't have particularly
> good news, I'm afraid.
> C2 leaks memory and CPU. The accompanying PNG shows the graphs of a loadtest
> with loadrunner, on tomcat 3.2.1 and C2 cvs version of last week, with 50
> concurrent users surfing around on the simple sample pages (no xsp, no sql,
> just the xml->html pages)
> The graphs don't look good, to say the least. 
> Moreover, when I stopped loadrunner, and monitored the CPU used by java, it
> kept burning 50-70% (even after 2 days). It was sort of cyclic behaviour: it
> dropped to 0%, raised to 50-70%, dropped again to 0%, and so on. I also saw

I *think* that's threads in MRUMemoryStore. Try to use store in thread-less mode. 

> the java process eating memory away (approx. 10MB/h)

I did not noticed this...

> The test was done with loadrunner 6.5 on a single 350 MHz cpu with 196MB
> RAM, OS: NT 4, JVM: Sun JDK1.3.1.
> And now for the really bad news: I don't have a clue as how to find the
> source of such a leak.

Try OptimizeIt. They give 15-days trial pereiod. I found several major leaks with this tool.
(example of a leak: check  "[PROPOSAL] Changing Source interface" thread)

> I could browse step-by-step through the code, but
> this seems a daunting task to say the least. Has anyone some hints as to say
> "I would begin looking there", or "I would first test this and see what
> happens", ... ? I've already been musing about the pooling of the components

With OptimizeIt, I would suggest following strategy:
1) set all pools to the minimum (but not less then required for request processing), ~2-4
2) launch cocoon
3) request resource several times to fill in all pools
4) hit "mark" button in optimizeit
5) request resource
6) hit GC button in optimizeit
7) watch for increase in java objects and look at their allocation backtraces and object graphs.

Good luck,

> (probably components that aren't given back to the pool), but that is also
> pretty hard to find.
> Thanks for any pointers,
> tomK

To unsubscribe, e-mail:
For additional commands, email:

View raw message