You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by to...@the-ecorp.com on 2001/08/20 16:49:49 UTC
[C2] Loadtest
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
the java process eating memory away (approx. 10MB/h)
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. 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
(probably components that aren't given back to the pool), but that is also
pretty hard to find.
Thanks for any pointers,
tomK
AW: [C2] Loadtest
Posted by Gerhard Froehlich <g-...@gmx.de>.
>I *think* that's threads in MRUMemoryStore. Try to use store in
>thread-less mode.
I just tested it with JMeter:
1. Test
+-------------------------------------------------------------+
cocoon.xconf:
<stream-pipeline
class="org.apache.cocoon.components.pipeline.CachingStreamPipeline"
pool-max="32" pool-min="16" pool-grow="4"/>
<event-pipeline
class="org.apache.cocoon.components.pipeline.CachingEventPipeline"
pool-max="32" pool-min="16" pool-grow="4"/>
<store class="org.apache.cocoon.components.store.MRUMemoryStore">
<parameter name="freememory" value="1000000"/>
<parameter name="heapsize" value="60000000"/>
<parameter name="cleanupthreadinterval" value="10"/>
<parameter name="maxobjects" value="100"/>
<parameter name="usecleanupthread" value="true"/>
<parameter name="threadpriority" value="5"/>
<parameter name="filesystem" value="true"/>
</store>
for both pipelines
+-------------------------------------------------------------+
web.xml
out log level on ERROR
+-------------------------------------------------------------+
jmeter:
6 thread groups a 5 threads
gaussion random timer, with average delay 300ms
and delay devitation 100ms
+-------------------------------------------------------------+
following urls:
/cocoon/hello.html
/cocoon/sites/java.apache.org
/cocoon/sites/jakarta.apache.org
/cocoon/slashdot/slashdot.xml
/cocoon/isyndicate/news.xml
/cocoon/welcome-svg
+-------------------------------------------------------------+
machine:
amd athlon 1,2 ghz
256MB ram
win2k prof sp 2
resin-2.0.1
+-------------------------------------------------------------+
RESULT:
CPU Consumption: 15-30%
RAM Consumption: 40-50MB CONSTANT
+-------------------------------------------------------------+
+-------------------------------------------------------------+
2. Test
Without threads
+-------------------------------------------------------------+
RESULT:
CPU Consumption: 15-30%
RAM Consumption: 40-50MB CONSTANT
+-------------------------------------------------------------+
+-------------------------------------------------------------+
This load test are much confusing. I have studied several results
from different load test in this mailing list last months.
The results are reaching from:
"cocoon2 is the fastest thing I ever seen" to "shit, cocoon2 consume
all of my system resources"
The last load test I read was from berin with quite good results of
the beta2 release. This thread was in the cocoon-user list.
I think, setting up a reference test enviroment with the right tool
and the right (realistic) settings would solve our problems here.
And _I_ would do that before releasing the first release.
I'm using jmeter for my load tests here at home. Neither I don't know
if it is the rigth tool for testing cocoon nor if I configured it
right for cocoon2 (you can't even configure much with jmeter).
I've appended my "test plan" for the jmeter.
In Carstens words:
Comments? Critics? Suggestions? Wishes?
Cheers
Gerhard
RE: [C2] Loadtest
Posted by Vadim Gritsenko <vg...@hns.com>.
>
> 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 components.
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,
Vadim
> (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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2] Loadtest
Posted by Matthew Langham <ml...@sundn.de>.
We have been using JProbe to find the source of memory leaks (the last time
being the sub-sitemap problem a couple of weeks back). JProble allows you to
snapshot the memory and then you can find out which objects remain in memory
after the request has been processed.
So that may be a start in narrowing down where the leaks are coming from.
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel: +49-5251-1581-30 [mlangham@sundn.de - http://www.sundn.de]
=================================================================
-----Ursprüngliche Nachricht-----
Von: tom.klaasen@the-ecorp.com [mailto:tom.klaasen@the-ecorp.com]
Gesendet: Montag, 20. August 2001 16:50
An: cocoon-dev@xml.apache.org
Betreff: [C2] Loadtest
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
the java process eating memory away (approx. 10MB/h)
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. 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
(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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org