You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marcus Crafter <cr...@osa.de> on 2001/08/22 01:32:22 UTC
Re: LoadTest
Hi All,
We've also been experiencing such problems for the last 2 weeks or so,
mainly a decrease in performance/response over time under reasonable
load.
We had a range of errors:
o components not found: fixed recently in avalon's DefaultPool
(also seems to have improved what was before a memory leak)
o multiple sitemap recompilations: fixed recently under article
'sitemap creation threading issue'
o decreased performance over time (100 users lasts about 20 minutes,
50 users lasts about 40 minutes with our application, before
performance drops)
We've been using an up-to-date version of Cocoon2 from trunk CVS and
have been following the discussions on the mailing list very closely.
In our situation, we've noticed that under load the application's
performance and response time decreases dramatically, however the
machine does recover after load has dropped. Once load drops, the
application starts to settle down and returns to a normal state
operating state.
During times of poor performance/response time however, our
application server is *not* out of resources. We've been able to
ascertain that both memory and CPU resources are available.
What could cause such a phenomenon ?
Memory leaks ? I'm not sure if a memory leak would cause a drop in
performance, unless excessive garbage collection was being done (but
we have 2gig of RAM, of which 800 meg is not even touched)
Runaway threads ? Could cause such a problem, but they wouldn't allow
the system to regain itself - or should I not assume this ?
Synchronization problems ? Could there be some synchronization issues
there which force the jvm to queue threads up for entry to a
particular method/code block which is considered to be a critical
area ?
Threading issues ? We've also seen cases in the log files under load
where a single (same) request is handled by 4 separate threads, all
starting in the same second - quite vexing.
Our environment is a on a Sun Enterprise 250 (2x450mhz UltraII, 2gig
ram), with Tomcat 3.2.3, CVS Cocoon2, and our reporting application
(generates various html tables and pdf reports).
If you have any comments, or questions regarding what we've seen,
please feel free to respond.
Cheers,
Marcus
> 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
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&: After Hours : +49 69 49086750
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: LoadTest
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Wed, 22 Aug 2001, Vadim Gritsenko wrote:
> Marcus,
> Do not use cocoon20b2 - this is really old beta release!
> Switch to cocoon_20_branch - that's the RC Berin is talking about.
Yes, sorry, it's been a late night. :-)
We're using the branch, not the b2 release.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: IT'S TIME TO REDO YOUR TESTS, GENTLEMEN!
Posted by Gerhard Froehlich <g-...@gmx.de>.
damn wrong thread...
>Morning Vadim,
>I have just tested cocoon with your patch (by the way, can
>you explain me how to diff between 2 files?).
>It's a little bit late, and I don't know if I did every-
>thing right:
>I shoot only 5 threads against /cocoon/hello.html to test
>your changes. The load is still high, but it seems to be a
>other reason now: java.io.Win32FileSystem.getLastModifiedTime()
>now eats 50% CPU time.
>org.apache.cocoon.components.source.URLSource.getInfos()
>org.apache.cocoon.components.source.URLSource.getLastModified()
>org.apache.cocoon.sitemap.Handler.hasChanged()
>org.apache.cocoon.sitemap.Manager.getHandler()
>org.apache.cocoon.sitemap.Manager.invoke()
>org.apache.cocoon.Cocoon.process()
>are invokers of this method.
>
>I attached the trace file to this mail. I will test it
>again tomorrow. I have a 14 days trail software, that
>should be sufficient :).
>Will catch some sleep now...
>
>Cheers
>Gerhard
AW: LoadTest
Posted by Gerhard Froehlich <g-...@gmx.de>.
Morning Vadim,
I have just tested cocoon with your patch (by the way, can
you explain me how to diff between 2 files?).
It's a little bit late, and I don't know if I did every-
thing right:
I shoot only 5 threads against /cocoon/hello.html to test
your changes. The load is still high, but it seems to be a
other reason now: java.io.Win32FileSystem.getLastModifiedTime()
now eats 50% CPU time.
org.apache.cocoon.components.source.URLSource.getInfos()
org.apache.cocoon.components.source.URLSource.getLastModified()
org.apache.cocoon.sitemap.Handler.hasChanged()
org.apache.cocoon.sitemap.Manager.getHandler()
org.apache.cocoon.sitemap.Manager.invoke()
org.apache.cocoon.Cocoon.process()
are invokers of this method.
I attached the trace file to this mail. I will test it
again tomorrow. I have a 14 days trail software, that
should be sufficient :).
Will catch some sleep now...
Cheers
Gerhard
>-----Ursprungliche Nachricht-----
>Von: Vadim Gritsenko [mailto:vgritsenko@yahoo.com]
>Gesendet: Thursday, August 23, 2001 1:03 AM
>An: cocoon-dev@xml.apache.org
>Betreff: RE: LoadTest
>
>
>Marcus,
>Do not use cocoon20b2 - this is really old beta release!
>Switch to cocoon_20_branch - that's the RC Berin is talking about.
>
>Vadim
>
>> -----Original Message-----
>> From: Marcus Crafter [mailto:crafterm@fztig938.bank.dresdner.net]
>> Sent: Wednesday, August 22, 2001 6:58 PM
>> To: cocoon-dev@xml.apache.org
>> Subject: Re: LoadTest
>>
>>
>> Hi Berin,
>>
>> Hope all is well mate. Thanks again for your advice.
>Please, don't be
>> afraid to give out more! :-)
>>
>> On Wed, 22 Aug 2001, Berin Loritsch wrote:
>>
>> > Marcus Crafter wrote:
>> > >
>> > > We had a range of errors:
>> > >
>> > > o components not found: fixed recently in avalon's
>DefaultPool
>> > > (also seems to have improved what was before a memory leak)
>> >
>> > I'm glad to see this is no longer a problem. Let me know if it rears
>> > its ugly head again.
>>
>> Sure will. :-)
>>
>> > > o decreased performance over time (100 users lasts
>about 20 minutes,
>> > > 50 users lasts about 40 minutes with our
>application, before
>> > > performance drops)
>> >
>> > What is the load (beyond number of users: time between responses, type
>> > of resource).
>>
>> The load actually changed with today's source code. Thanks
>to all that
>> checked in changes today. Yesterday the load was less on our system
>> (averaging between 3 and 6, for 50 and 100 users).
>>
>> With the changes from today (which have helped dramatically)
>> the load is much higher, around 7-14 with the same user counts.
>>
>> Performance in general is actually much better than before,
>even though
>> the machine seems to be under more load.
>>
>> > Probably should use the cocoon_2_0 branch (check the site for
>the proper
>> > name).
>> > That is what is being prepared for production readiness.
>>
>> Ok, we've switched over to the cocoon20b2 branch.
>>
>> > Cocoon.xconf provides attributes to allow you to manipulate
>> > the size of Component pools for Poolable Components:
>> >
>> > pool-min // Minimum number of Components in the pool
>> > pool-max // Maximum number of Components maintained in the pool
>> > pool-grow // Number of Components to add to the pool each
>time we run
>> > out.
>> >
>> > The Pool will basically turn into a Factory when the number of
>> > Components in
>> > the pool exceed pool-max. This is a performance drain.
>>
>> Ok. Excellent advice. :-)
>>
>> We pumped up our pool settings and saw an immediate improvement in
>> general application performance, especially when testing
>directly with
>> Tomcat (vs via a ajp13 connector).
>>
>> I've increased pooling settings on as much components as I
>can in our
>> cocoon.xconf and sitemap.xmap files (min 32 to max 64 for 50
>> simultaneous users).
>>
>> There are still several components which are regularly being
>> decommissioned in the log files during our tests, that I cannot find
>> locations where I can set pooling parameters for. These are:
>>
>> org.apache.cocoon.components.language.markup.xsp.XSPMarkupLanguage
>> org.apache.avalon.excalibur.component.ExcaliburComponentSelector
>>
>> and all generated xsp classes, eg:
>>
>> org.apache.cocoon.www.client.common.mask.mask_xsp_xml
>> (custom generated xsp class).
>>
>> Is it possible to set pooling sizes on these components too ?
>>
>> > Increase your pool sizes and cache sizes. If your JVM is not
>set to use
>> > all 2 gig of RAM, then it will perform garbage collection more often.
>>
>> Yep. Have done already, we're running with mx1526 ms1024m,
>although I
>> missed the MRU settings. I've increased the MRUMemory sizes
>today from
>> 60m to 200m (for each event cache, stream cache, and the store).
>>
>> > > Runaway threads ? Could cause such a problem, but
>they wouldn't allow
>> > > the system to regain itself - or should I not assume this ?
>> >
>> > I don't think this is a problem. You would see your CPU maxed out.
>>
>> I agree.
>>
>> > > Threading issues ? We've also seen cases in the log
>files under load
>> > > where a single (same) request is handled by 4
>separate threads, all
>> > > starting in the same second - quite vexing.
>> >
>> > That _might_ be your Servlet Engine. The last time I ran my tests I
>> > used Caucho's Resin. It is pretty decent, although it has some
>> > synchronization issues of its own regarding archived files
>(i.e. jar files).
>> > They are so severe that the entire JVM crashes.
>>
>> Ouch. Ok, I'll try everything with Resin as well, and also with
>> Tomcat 4. BTW - Have you (or anyone else) experienced
>performance/load
>> problems when using the apache connectors at all ?
>>
>> > > Our environment is a on a Sun Enterprise 250
>(2x450mhz UltraII, 2gig
>> > > ram), with Tomcat 3.2.3, CVS Cocoon2, and our
>reporting application
>> > > (generates various html tables and pdf reports).
>> >
>> > That sounds very impressive. Can I have one? ;P
>>
>> Sure, we have 5 of them here :-)
>>
>> That's it so far. Thanks very much for your advice Berin, we'll
>> continue to test here with the ideas you and others have
>laid out with
>> the current codebase. As we do more testing I'll send in more
>> information.
>>
>> Cheers,
>>
>> Marcus
>>
>>
>> --
>> .....
>> ,,$$$$$$$$$, Marcus Crafter
>> ;$' '$$$$: Computer Systems Engineer
>> $: $$$$: Open Software Associates GmbH
>> $ o_)$$$: 82-84 Mainzer Landstrasse
>> ;$, _/\ &&:' 60327 Frankfurt Germany
>> ' /( &&&
>> \_&&&&' Email : Marcus.Crafter@osa.de
>> &&&&. Business Hours : +49 69 9757 200
>> &&&&&&&:
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
RE: LoadTest
Posted by Vadim Gritsenko <vg...@yahoo.com>.
Marcus,
Do not use cocoon20b2 - this is really old beta release!
Switch to cocoon_20_branch - that's the RC Berin is talking about.
Vadim
> -----Original Message-----
> From: Marcus Crafter [mailto:crafterm@fztig938.bank.dresdner.net]
> Sent: Wednesday, August 22, 2001 6:58 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: LoadTest
>
>
> Hi Berin,
>
> Hope all is well mate. Thanks again for your advice. Please, don't be
> afraid to give out more! :-)
>
> On Wed, 22 Aug 2001, Berin Loritsch wrote:
>
> > Marcus Crafter wrote:
> > >
> > > We had a range of errors:
> > >
> > > o components not found: fixed recently in avalon's DefaultPool
> > > (also seems to have improved what was before a memory leak)
> >
> > I'm glad to see this is no longer a problem. Let me know if it rears
> > its ugly head again.
>
> Sure will. :-)
>
> > > o decreased performance over time (100 users lasts about 20 minutes,
> > > 50 users lasts about 40 minutes with our application, before
> > > performance drops)
> >
> > What is the load (beyond number of users: time between responses, type
> > of resource).
>
> The load actually changed with today's source code. Thanks to all that
> checked in changes today. Yesterday the load was less on our system
> (averaging between 3 and 6, for 50 and 100 users).
>
> With the changes from today (which have helped dramatically)
> the load is much higher, around 7-14 with the same user counts.
>
> Performance in general is actually much better than before, even though
> the machine seems to be under more load.
>
> > Probably should use the cocoon_2_0 branch (check the site for the proper
> > name).
> > That is what is being prepared for production readiness.
>
> Ok, we've switched over to the cocoon20b2 branch.
>
> > Cocoon.xconf provides attributes to allow you to manipulate
> > the size of Component pools for Poolable Components:
> >
> > pool-min // Minimum number of Components in the pool
> > pool-max // Maximum number of Components maintained in the pool
> > pool-grow // Number of Components to add to the pool each time we run
> > out.
> >
> > The Pool will basically turn into a Factory when the number of
> > Components in
> > the pool exceed pool-max. This is a performance drain.
>
> Ok. Excellent advice. :-)
>
> We pumped up our pool settings and saw an immediate improvement in
> general application performance, especially when testing directly with
> Tomcat (vs via a ajp13 connector).
>
> I've increased pooling settings on as much components as I can in our
> cocoon.xconf and sitemap.xmap files (min 32 to max 64 for 50
> simultaneous users).
>
> There are still several components which are regularly being
> decommissioned in the log files during our tests, that I cannot find
> locations where I can set pooling parameters for. These are:
>
> org.apache.cocoon.components.language.markup.xsp.XSPMarkupLanguage
> org.apache.avalon.excalibur.component.ExcaliburComponentSelector
>
> and all generated xsp classes, eg:
>
> org.apache.cocoon.www.client.common.mask.mask_xsp_xml
> (custom generated xsp class).
>
> Is it possible to set pooling sizes on these components too ?
>
> > Increase your pool sizes and cache sizes. If your JVM is not set to use
> > all 2 gig of RAM, then it will perform garbage collection more often.
>
> Yep. Have done already, we're running with mx1526 ms1024m, although I
> missed the MRU settings. I've increased the MRUMemory sizes today from
> 60m to 200m (for each event cache, stream cache, and the store).
>
> > > Runaway threads ? Could cause such a problem, but they wouldn't allow
> > > the system to regain itself - or should I not assume this ?
> >
> > I don't think this is a problem. You would see your CPU maxed out.
>
> I agree.
>
> > > Threading issues ? We've also seen cases in the log files under load
> > > where a single (same) request is handled by 4 separate threads, all
> > > starting in the same second - quite vexing.
> >
> > That _might_ be your Servlet Engine. The last time I ran my tests I
> > used Caucho's Resin. It is pretty decent, although it has some
> > synchronization issues of its own regarding archived files (i.e. jar files).
> > They are so severe that the entire JVM crashes.
>
> Ouch. Ok, I'll try everything with Resin as well, and also with
> Tomcat 4. BTW - Have you (or anyone else) experienced performance/load
> problems when using the apache connectors at all ?
>
> > > Our environment is a on a Sun Enterprise 250 (2x450mhz UltraII, 2gig
> > > ram), with Tomcat 3.2.3, CVS Cocoon2, and our reporting application
> > > (generates various html tables and pdf reports).
> >
> > That sounds very impressive. Can I have one? ;P
>
> Sure, we have 5 of them here :-)
>
> That's it so far. Thanks very much for your advice Berin, we'll
> continue to test here with the ideas you and others have laid out with
> the current codebase. As we do more testing I'll send in more
> information.
>
> Cheers,
>
> Marcus
>
>
> --
> .....
> ,,$$$$$$$$$, Marcus Crafter
> ;$' '$$$$: Computer Systems Engineer
> $: $$$$: Open Software Associates GmbH
> $ o_)$$$: 82-84 Mainzer Landstrasse
> ;$, _/\ &&:' 60327 Frankfurt Germany
> ' /( &&&
> \_&&&&' Email : Marcus.Crafter@osa.de
> &&&&. Business Hours : +49 69 9757 200
> &&&&&&&:
>
>
> ---------------------------------------------------------------------
> 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
Re: LoadTest
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Berin,
Hope all is well mate. Thanks again for your advice. Please, don't be
afraid to give out more! :-)
On Wed, 22 Aug 2001, Berin Loritsch wrote:
> Marcus Crafter wrote:
> >
> > We had a range of errors:
> >
> > o components not found: fixed recently in avalon's DefaultPool
> > (also seems to have improved what was before a memory leak)
>
> I'm glad to see this is no longer a problem. Let me know if it rears
> its ugly head again.
Sure will. :-)
> > o decreased performance over time (100 users lasts about 20 minutes,
> > 50 users lasts about 40 minutes with our application, before
> > performance drops)
>
> What is the load (beyond number of users: time between responses, type
> of resource).
The load actually changed with today's source code. Thanks to all that
checked in changes today. Yesterday the load was less on our system
(averaging between 3 and 6, for 50 and 100 users).
With the changes from today (which have helped dramatically)
the load is much higher, around 7-14 with the same user counts.
Performance in general is actually much better than before, even though
the machine seems to be under more load.
> Probably should use the cocoon_2_0 branch (check the site for the proper
> name).
> That is what is being prepared for production readiness.
Ok, we've switched over to the cocoon20b2 branch.
> Cocoon.xconf provides attributes to allow you to manipulate
> the size of Component pools for Poolable Components:
>
> pool-min // Minimum number of Components in the pool
> pool-max // Maximum number of Components maintained in the pool
> pool-grow // Number of Components to add to the pool each time we run
> out.
>
> The Pool will basically turn into a Factory when the number of
> Components in
> the pool exceed pool-max. This is a performance drain.
Ok. Excellent advice. :-)
We pumped up our pool settings and saw an immediate improvement in
general application performance, especially when testing directly with
Tomcat (vs via a ajp13 connector).
I've increased pooling settings on as much components as I can in our
cocoon.xconf and sitemap.xmap files (min 32 to max 64 for 50
simultaneous users).
There are still several components which are regularly being
decommissioned in the log files during our tests, that I cannot find
locations where I can set pooling parameters for. These are:
org.apache.cocoon.components.language.markup.xsp.XSPMarkupLanguage
org.apache.avalon.excalibur.component.ExcaliburComponentSelector
and all generated xsp classes, eg:
org.apache.cocoon.www.client.common.mask.mask_xsp_xml
(custom generated xsp class).
Is it possible to set pooling sizes on these components too ?
> Increase your pool sizes and cache sizes. If your JVM is not set to use
> all 2 gig of RAM, then it will perform garbage collection more often.
Yep. Have done already, we're running with mx1526 ms1024m, although I
missed the MRU settings. I've increased the MRUMemory sizes today from
60m to 200m (for each event cache, stream cache, and the store).
> > Runaway threads ? Could cause such a problem, but they wouldn't allow
> > the system to regain itself - or should I not assume this ?
>
> I don't think this is a problem. You would see your CPU maxed out.
I agree.
> > Threading issues ? We've also seen cases in the log files under load
> > where a single (same) request is handled by 4 separate threads, all
> > starting in the same second - quite vexing.
>
> That _might_ be your Servlet Engine. The last time I ran my tests I
> used Caucho's Resin. It is pretty decent, although it has some
> synchronization issues of its own regarding archived files (i.e. jar files).
> They are so severe that the entire JVM crashes.
Ouch. Ok, I'll try everything with Resin as well, and also with
Tomcat 4. BTW - Have you (or anyone else) experienced performance/load
problems when using the apache connectors at all ?
> > Our environment is a on a Sun Enterprise 250 (2x450mhz UltraII, 2gig
> > ram), with Tomcat 3.2.3, CVS Cocoon2, and our reporting application
> > (generates various html tables and pdf reports).
>
> That sounds very impressive. Can I have one? ;P
Sure, we have 5 of them here :-)
That's it so far. Thanks very much for your advice Berin, we'll
continue to test here with the ideas you and others have laid out with
the current codebase. As we do more testing I'll send in more
information.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: LoadTest
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Berin,
Thanks very much for your feedback and suggestions - *much* appreciated.
I will try your suggestions today and send in an email later on
tonight with the results.
Cheers,
Marcus
On Wed, 22 Aug 2001, Berin Loritsch wrote:
> Marcus Crafter wrote:
> >
> > Hi All,
> >
> > We've also been experiencing such problems for the last 2 weeks or so,
> > mainly a decrease in performance/response over time under reasonable
> > load.
> >
> > We had a range of errors:
> >
> > o components not found: fixed recently in avalon's DefaultPool
> > (also seems to have improved what was before a memory leak)
>
> I'm glad to see this is no longer a problem. Let me know if it rears
> its ugly
> head again.
>
> > o decreased performance over time (100 users lasts about 20 minutes,
> > 50 users lasts about 40 minutes with our application, before
> > performance drops)
>
> What is the load (beyond number of users: time between responses, type
> of resource).
>
> > We've been using an up-to-date version of Cocoon2 from trunk CVS and
> > have been following the discussions on the mailing list very closely.
>
> Probably should use the cocoon_2_0 branch (check the site for the proper
> name).
> That is what is being prepared for production readiness. The main trunk
> (Cocoon 2.1)
> has some new/experimental components that may contribute to stability
> issues and
> memory leaks.
>
> > In our situation, we've noticed that under load the application's
> > performance and response time decreases dramatically, however the
> > machine does recover after load has dropped. Once load drops, the
> > application starts to settle down and returns to a normal state
> > operating state.
>
> The fact that Cocoon recovers gracefully is a testament to its design.
> This is
> part of the scalability picture. It is understandable that the response
> time
> will decrease under load, but check below for more information:
>
> > During times of poor performance/response time however, our
> > application server is *not* out of resources. We've been able to
> > ascertain that both memory and CPU resources are available.
> >
> > What could cause such a phenomenon ?
>
> Ok. There are two things that can help you: increasing the amount of
> memmory
> your JVM will use (the java -X options), and manipulating the pool sizes
> for
> the Components. Cocoon.xconf provides attributes to allow you to
> manipulate
> the size of Component pools for Poolable Components:
>
> pool-min // Minimum number of Components in the pool
> pool-max // Maximum number of Components maintained in the pool
> pool-grow // Number of Components to add to the pool each time we run
> out.
>
> The Pool will basically turn into a Factory when the number of
> Components in
> the pool exceed pool-max. This is a performance drain.
>
> We should probably ensure their use in Sitemap Components (any takers on
> this?)
>
> > Memory leaks ? I'm not sure if a memory leak would cause a drop in
> > performance, unless excessive garbage collection was being done (but
> > we have 2gig of RAM, of which 800 meg is not even touched)
>
> Increase your pool sizes and cache sizes. If your JVM is not set to use
> all 2 gig
> of RAM, then it will perform garbage collection more often.
>
> > Runaway threads ? Could cause such a problem, but they wouldn't allow
> > the system to regain itself - or should I not assume this ?
>
> I don't think this is a problem. You would see your CPU maxed out.
>
> > Synchronization problems ? Could there be some synchronization issues
> > there which force the jvm to queue threads up for entry to a
> > particular method/code block which is considered to be a critical
> > area ?
>
> The ComponentManagement framework uses Mutexes to control access--which
> is critical
> for Cocoon's stability. However, if you can sustain 100 users for 20
> minutes before
> the slow down occurs, I doubt that synchronization is the culprit.
>
> > Threading issues ? We've also seen cases in the log files under load
> > where a single (same) request is handled by 4 separate threads, all
> > starting in the same second - quite vexing.
>
> That _might_ be your Servlet Engine. The last time I ran my tests I
> used Caucho's
> Resin. It is pretty decent, although it has some synchronization issues
> of its own
> regarding archived files (i.e. jar files). They are so severe that the
> entire JVM
> crashes.
>
> Try another vendor's Servlet Engine--it _could_ be that Tomcat is the
> problem if
> 4 threads are handling the SAME request.
>
> > Our environment is a on a Sun Enterprise 250 (2x450mhz UltraII, 2gig
> > ram), with Tomcat 3.2.3, CVS Cocoon2, and our reporting application
> > (generates various html tables and pdf reports).
>
> That sounds very impressive. Can I have one? ;P
>
> > If you have any comments, or questions regarding what we've seen,
> > please feel free to respond.
>
> Try the tips I laid out. Recapping:
>
> 1) Make sure your JVM is set to use all 2gig of RAM (or however close
> you want to be)
> 2) Play with the pool parameters until you have something that works
> 3) Try another Servlet Engine (If your problems persist then the issue
> is very likely
> with Cocoon)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: LoadTest
Posted by Berin Loritsch <bl...@apache.org>.
Matthew Langham wrote:
>
> Berin (and others),
>
> >>
> the Components. Cocoon.xconf provides attributes to allow you to
> manipulate
> the size of Component pools for Poolable Components:
>
> pool-min // Minimum number of Components in the pool
> pool-max // Maximum number of Components maintained in the pool
> pool-grow // Number of Components to add to the pool each time we run
> out.
> <<
>
> Where have you been successful in adding / changing these attributes to
> increase performance (i.e. which components lend themselves to needing
> higher values)?
The best rule of thumb I can give you is to search your DEBUG logs for
the following phrase:
"ComponentFactory decommissioning instance of " {ClassName follows}
This gives you the name of Components that need to have a higher pool-max.
The way the SoftResourceLimitingPool works is that it decommissions
objects that are beyond the pool-max (defaults to 8) when they are returned.
It creates them as they are needed--so make sure you set your max high
enough. Go by the expected number of simultaneous users during peak
times. Cocoon won't crash when you exceed those values, just slow down.
>
> 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]
> =================================================================
>
> the Components. Cocoon.xconf provides attributes to allow you to
> manipulate
> the size of Component pools for Poolable Components:
>
> pool-min // Minimum number of Components in the pool
> pool-max // Maximum number of Components maintained in the pool
> pool-grow // Number of Components to add to the pool each time we run
> out.
>
> The Pool will basically turn into a Factory when the number of
> Components in
> the pool exceed pool-max. This is a performance drain.
>
> We should probably ensure their use in Sitemap Components (any takers on
> this?)
>
> > Memory leaks ? I'm not sure if a memory leak would cause a drop in
> > performance, unless excessive garbage collection was being done
> (but
> > we have 2gig of RAM, of which 800 meg is not even touched)
>
> Increase your pool sizes and cache sizes. If your JVM is not set to use
> all 2 gig
> of RAM, then it will perform garbage collection more often.
>
> > Runaway threads ? Could cause such a problem, but they wouldn't
> allow
> > the system to regain itself - or should I not assume this ?
>
> I don't think this is a problem. You would see your CPU maxed out.
>
> > Synchronization problems ? Could there be some synchronization
> issues
> > there which force the jvm to queue threads up for entry to a
> > particular method/code block which is considered to be a critical
> > area ?
>
> The ComponentManagement framework uses Mutexes to control access--which
> is critical
> for Cocoon's stability. However, if you can sustain 100 users for 20
> minutes before
> the slow down occurs, I doubt that synchronization is the culprit.
>
> > Threading issues ? We've also seen cases in the log files under
> load
> > where a single (same) request is handled by 4 separate threads,
> all
> > starting in the same second - quite vexing.
>
> That _might_ be your Servlet Engine. The last time I ran my tests I
> used Caucho's
> Resin. It is pretty decent, although it has some synchronization issues
> of its own
> regarding archived files (i.e. jar files). They are so severe that the
> entire JVM
> crashes.
>
> Try another vendor's Servlet Engine--it _could_ be that Tomcat is the
> problem if
> 4 threads are handling the SAME request.
>
> > Our environment is a on a Sun Enterprise 250 (2x450mhz UltraII,
> 2gig
> > ram), with Tomcat 3.2.3, CVS Cocoon2, and our reporting
> application
> > (generates various html tables and pdf reports).
>
> That sounds very impressive. Can I have one? ;P
>
> > If you have any comments, or questions regarding what we've seen,
> > please feel free to respond.
>
> Try the tips I laid out. Recapping:
>
> 1) Make sure your JVM is set to use all 2gig of RAM (or however close
> you want to be)
> 2) Play with the pool parameters until you have something that works
> 3) Try another Servlet Engine (If your problems persist then the issue
> is very likely
> with Cocoon)
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ajp12/ajp13 (was Re: AW: LoadTest)
Posted by Sergio Carvalho <se...@acm.org>.
I had all kinds of problems trying to use the webapp module for tomcat 4, from
compilation hell up to a thrashing system, with race condition-caused httpd
process deaths. I happily switched to mod_proxy for apache, taking the
opportunity to cache results at the same time.
On Fri, 24 Aug 2001 11:41:38 +0200 (CEST), Marcus Crafter
<cr...@fztig938.bank.dresdner.net> wrote:
--
Q
> Hi Matthew,
>
> On Thu, 23 Aug 2001, Matthew Langham wrote:
>
> > Quick question for those of you using Apache+Tomcat: ajp13 or ajp12? From
> > what I have read ajp13 is faster - is this your experience as well and are
> > there any "gotchas"?
>
> We've been using ajp12 for the past year, without problems. We only
> had one issue where if tomcat crashed, httpd would race and try to
> take over the system. This was fixed a while back though.
>
> Recently we've upgraded to ajp13 as we read the same fokelore. So far
> everything has been fine with that too. What are you guys using ?
>
> Anyone have experience/comments about the webapp module in tomcat 4 ?
>
> Cheers,
>
> Marcus
> --
> .....
> ,,$$$$$$$$$, Marcus Crafter
> ;$' '$$$$: Computer Systems Engineer
> $: $$$$: Open Software Associates GmbH
> $ o_)$$$: 82-84 Mainzer Landstrasse
> ;$, _/\ &&:' 60327 Frankfurt Germany
> ' /( &&&
> \_&&&&' Email : Marcus.Crafter@osa.de
> &&&&. Business Hours : +49 69 9757 200
> &&&&&&&:
>
>
> ---------------------------------------------------------------------
> 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
Re: AW: ajp12/ajp13 (was Re: AW: LoadTest)
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi,
On Fri, 24 Aug 2001, Matthew Langham wrote:
> >>
> We've been using ajp12 for the past year, without problems. We only
> had one issue where if tomcat crashed, httpd would race and try to
> take over the system. This was fixed a while back though.
> <<
> We saw that happen on Linux boxes.
We've had it on Sun systems too.
> >>
> Recently we've upgraded to ajp13 as we read the same fokelore. So far
> everything has been fine with that too. What are you guys using ?
> <<
> We are using ajp12 at the moment. Is using ajp13 a significant gain?
We haven't noticed any yet, but our machines weren't under that much
stress before we changed anyway.
Cheers,
M.
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: ajp12/ajp13 (was Re: AW: LoadTest)
Posted by Matthew Langham <ml...@sundn.de>.
Hi,
>>
We've been using ajp12 for the past year, without problems. We only
had one issue where if tomcat crashed, httpd would race and try to
take over the system. This was fixed a while back though.
<<
We saw that happen on Linux boxes.
>>
Recently we've upgraded to ajp13 as we read the same fokelore. So far
everything has been fine with that too. What are you guys using ?
<<
We are using ajp12 at the moment. Is using ajp13 a significant gain?
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]
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
ajp12/ajp13 (was Re: AW: LoadTest)
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
Hi Matthew,
On Thu, 23 Aug 2001, Matthew Langham wrote:
> Quick question for those of you using Apache+Tomcat: ajp13 or ajp12? From
> what I have read ajp13 is faster - is this your experience as well and are
> there any "gotchas"?
We've been using ajp12 for the past year, without problems. We only
had one issue where if tomcat crashed, httpd would race and try to
take over the system. This was fixed a while back though.
Recently we've upgraded to ajp13 as we read the same fokelore. So far
everything has been fine with that too. What are you guys using ?
Anyone have experience/comments about the webapp module in tomcat 4 ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: LoadTest
Posted by Matthew Langham <ml...@sundn.de>.
Quick question for those of you using Apache+Tomcat: ajp13 or ajp12? From
what I have read ajp13 is faster - is this your experience as well and are
there any "gotchas"?
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]
=================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: LoadTest
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
>
> > -----Original Message-----
> > From: Matthew Langham [mailto:mlangham@sundn.de]
> > Sent: Wednesday, August 22, 2001 6:09 AM
> > To: cocoon-dev@xml.apache.org
> > Subject: AW: LoadTest
> >
> >
> > Berin (and others),
> >
> > >>
> > the Components. Cocoon.xconf provides attributes to allow you to
> > manipulate
> > the size of Component pools for Poolable Components:
> >
> > pool-min // Minimum number of Components in the pool
> > pool-max // Maximum number of Components maintained in the pool
> > pool-grow // Number of Components to add to the pool each time we run
> > out.
> > <<
> >
> > Where have you been successful in adding / changing these attributes to
> > increase performance (i.e. which components lend themselves to needing
> > higher values)?
>
> Pipelines - at least <Number of simultaneous users> * <depth of content aggregation>,
> Generators/Transformers/Serializers - at least <amount required to process one request> * <Number of simultaneous users>
> Connectors (if any) - <count of pipeline components to process one request> * <Number of simultaneous users>
>
> This increases performance A LOT if you have >8 simultaneous users (threads) and stock sitemap.
This is a good general rule of thumb. If you find that all this requires too many resources, you might be
able to cut it to 80% of the calculated value. Real world conditions are not as stringent as Load Testing
situations.
To test for more of a "real world" load, random delay ~15 seconds between page loads (it takes some time to read
the content) varied +/- 10 seconds. You will find that Cocoon can handle a much larger number of users that
way, and the calculations above would be somewhat overkill.
The "sadist" loads are necessary to test the robustness of Cocoon--but they don't help in determining the
size of the pools or Cache for real loads.
>
> Vadim
>
> >
> > 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]
> > =================================================================
> >
> > the Components. Cocoon.xconf provides attributes to allow you to
> > manipulate
> > the size of Component pools for Poolable Components:
> >
> > pool-min // Minimum number of Components in the pool
> > pool-max // Maximum number of Components maintained in the pool
> > pool-grow // Number of Components to add to the pool each time we run
> > out.
> >
> > The Pool will basically turn into a Factory when the number of
> > Components in
> > the pool exceed pool-max. This is a performance drain.
> >
> > We should probably ensure their use in Sitemap Components (any takers on
> > this?)
> >
> > > Memory leaks ? I'm not sure if a memory leak would cause a drop in
> > > performance, unless excessive garbage collection was being done
> > (but
> > > we have 2gig of RAM, of which 800 meg is not even touched)
> >
> > Increase your pool sizes and cache sizes. If your JVM is not set to use
> > all 2 gig
> > of RAM, then it will perform garbage collection more often.
> >
> > > Runaway threads ? Could cause such a problem, but they wouldn't
> > allow
> > > the system to regain itself - or should I not assume this ?
> >
> > I don't think this is a problem. You would see your CPU maxed out.
> >
> > > Synchronization problems ? Could there be some synchronization
> > issues
> > > there which force the jvm to queue threads up for entry to a
> > > particular method/code block which is considered to be a critical
> > > area ?
> >
> > The ComponentManagement framework uses Mutexes to control access--which
> > is critical
> > for Cocoon's stability. However, if you can sustain 100 users for 20
> > minutes before
> > the slow down occurs, I doubt that synchronization is the culprit.
> >
> > > Threading issues ? We've also seen cases in the log files under
> > load
> > > where a single (same) request is handled by 4 separate threads,
> > all
> > > starting in the same second - quite vexing.
> >
> > That _might_ be your Servlet Engine. The last time I ran my tests I
> > used Caucho's
> > Resin. It is pretty decent, although it has some synchronization issues
> > of its own
> > regarding archived files (i.e. jar files). They are so severe that the
> > entire JVM
> > crashes.
> >
> > Try another vendor's Servlet Engine--it _could_ be that Tomcat is the
> > problem if
> > 4 threads are handling the SAME request.
> >
> > > Our environment is a on a Sun Enterprise 250 (2x450mhz UltraII,
> > 2gig
> > > ram), with Tomcat 3.2.3, CVS Cocoon2, and our reporting
> > application
> > > (generates various html tables and pdf reports).
> >
> > That sounds very impressive. Can I have one? ;P
> >
> > > If you have any comments, or questions regarding what we've seen,
> > > please feel free to respond.
> >
> > Try the tips I laid out. Recapping:
> >
> > 1) Make sure your JVM is set to use all 2gig of RAM (or however close
> > you want to be)
> > 2) Play with the pool parameters until you have something that works
> > 3) Try another Servlet Engine (If your problems persist then the issue
> > is very likely
> > with Cocoon)
> >
> > ---------------------------------------------------------------------
> > 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
> >
>
> ---------------------------------------------------------------------
> 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
RE: LoadTest
Posted by Vadim Gritsenko <vg...@hns.com>.
> -----Original Message-----
> From: Matthew Langham [mailto:mlangham@sundn.de]
> Sent: Wednesday, August 22, 2001 6:09 AM
> To: cocoon-dev@xml.apache.org
> Subject: AW: LoadTest
>
>
> Berin (and others),
>
> >>
> the Components. Cocoon.xconf provides attributes to allow you to
> manipulate
> the size of Component pools for Poolable Components:
>
> pool-min // Minimum number of Components in the pool
> pool-max // Maximum number of Components maintained in the pool
> pool-grow // Number of Components to add to the pool each time we run
> out.
> <<
>
> Where have you been successful in adding / changing these attributes to
> increase performance (i.e. which components lend themselves to needing
> higher values)?
Pipelines - at least <Number of simultaneous users> * <depth of content aggregation>,
Generators/Transformers/Serializers - at least <amount required to process one request> * <Number of simultaneous users>
Connectors (if any) - <count of pipeline components to process one request> * <Number of simultaneous users>
This increases performance A LOT if you have >8 simultaneous users (threads) and stock sitemap.
Vadim
>
> 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]
> =================================================================
>
> the Components. Cocoon.xconf provides attributes to allow you to
> manipulate
> the size of Component pools for Poolable Components:
>
> pool-min // Minimum number of Components in the pool
> pool-max // Maximum number of Components maintained in the pool
> pool-grow // Number of Components to add to the pool each time we run
> out.
>
> The Pool will basically turn into a Factory when the number of
> Components in
> the pool exceed pool-max. This is a performance drain.
>
> We should probably ensure their use in Sitemap Components (any takers on
> this?)
>
> > Memory leaks ? I'm not sure if a memory leak would cause a drop in
> > performance, unless excessive garbage collection was being done
> (but
> > we have 2gig of RAM, of which 800 meg is not even touched)
>
> Increase your pool sizes and cache sizes. If your JVM is not set to use
> all 2 gig
> of RAM, then it will perform garbage collection more often.
>
> > Runaway threads ? Could cause such a problem, but they wouldn't
> allow
> > the system to regain itself - or should I not assume this ?
>
> I don't think this is a problem. You would see your CPU maxed out.
>
> > Synchronization problems ? Could there be some synchronization
> issues
> > there which force the jvm to queue threads up for entry to a
> > particular method/code block which is considered to be a critical
> > area ?
>
> The ComponentManagement framework uses Mutexes to control access--which
> is critical
> for Cocoon's stability. However, if you can sustain 100 users for 20
> minutes before
> the slow down occurs, I doubt that synchronization is the culprit.
>
> > Threading issues ? We've also seen cases in the log files under
> load
> > where a single (same) request is handled by 4 separate threads,
> all
> > starting in the same second - quite vexing.
>
> That _might_ be your Servlet Engine. The last time I ran my tests I
> used Caucho's
> Resin. It is pretty decent, although it has some synchronization issues
> of its own
> regarding archived files (i.e. jar files). They are so severe that the
> entire JVM
> crashes.
>
> Try another vendor's Servlet Engine--it _could_ be that Tomcat is the
> problem if
> 4 threads are handling the SAME request.
>
> > Our environment is a on a Sun Enterprise 250 (2x450mhz UltraII,
> 2gig
> > ram), with Tomcat 3.2.3, CVS Cocoon2, and our reporting
> application
> > (generates various html tables and pdf reports).
>
> That sounds very impressive. Can I have one? ;P
>
> > If you have any comments, or questions regarding what we've seen,
> > please feel free to respond.
>
> Try the tips I laid out. Recapping:
>
> 1) Make sure your JVM is set to use all 2gig of RAM (or however close
> you want to be)
> 2) Play with the pool parameters until you have something that works
> 3) Try another Servlet Engine (If your problems persist then the issue
> is very likely
> with Cocoon)
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: LoadTest
Posted by Matthew Langham <ml...@sundn.de>.
Berin (and others),
>>
the Components. Cocoon.xconf provides attributes to allow you to
manipulate
the size of Component pools for Poolable Components:
pool-min // Minimum number of Components in the pool
pool-max // Maximum number of Components maintained in the pool
pool-grow // Number of Components to add to the pool each time we run
out.
<<
Where have you been successful in adding / changing these attributes to
increase performance (i.e. which components lend themselves to needing
higher values)?
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]
=================================================================
the Components. Cocoon.xconf provides attributes to allow you to
manipulate
the size of Component pools for Poolable Components:
pool-min // Minimum number of Components in the pool
pool-max // Maximum number of Components maintained in the pool
pool-grow // Number of Components to add to the pool each time we run
out.
The Pool will basically turn into a Factory when the number of
Components in
the pool exceed pool-max. This is a performance drain.
We should probably ensure their use in Sitemap Components (any takers on
this?)
> Memory leaks ? I'm not sure if a memory leak would cause a drop in
> performance, unless excessive garbage collection was being done
(but
> we have 2gig of RAM, of which 800 meg is not even touched)
Increase your pool sizes and cache sizes. If your JVM is not set to use
all 2 gig
of RAM, then it will perform garbage collection more often.
> Runaway threads ? Could cause such a problem, but they wouldn't
allow
> the system to regain itself - or should I not assume this ?
I don't think this is a problem. You would see your CPU maxed out.
> Synchronization problems ? Could there be some synchronization
issues
> there which force the jvm to queue threads up for entry to a
> particular method/code block which is considered to be a critical
> area ?
The ComponentManagement framework uses Mutexes to control access--which
is critical
for Cocoon's stability. However, if you can sustain 100 users for 20
minutes before
the slow down occurs, I doubt that synchronization is the culprit.
> Threading issues ? We've also seen cases in the log files under
load
> where a single (same) request is handled by 4 separate threads,
all
> starting in the same second - quite vexing.
That _might_ be your Servlet Engine. The last time I ran my tests I
used Caucho's
Resin. It is pretty decent, although it has some synchronization issues
of its own
regarding archived files (i.e. jar files). They are so severe that the
entire JVM
crashes.
Try another vendor's Servlet Engine--it _could_ be that Tomcat is the
problem if
4 threads are handling the SAME request.
> Our environment is a on a Sun Enterprise 250 (2x450mhz UltraII,
2gig
> ram), with Tomcat 3.2.3, CVS Cocoon2, and our reporting
application
> (generates various html tables and pdf reports).
That sounds very impressive. Can I have one? ;P
> If you have any comments, or questions regarding what we've seen,
> please feel free to respond.
Try the tips I laid out. Recapping:
1) Make sure your JVM is set to use all 2gig of RAM (or however close
you want to be)
2) Play with the pool parameters until you have something that works
3) Try another Servlet Engine (If your problems persist then the issue
is very likely
with Cocoon)
---------------------------------------------------------------------
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
Re: LoadTest
Posted by Berin Loritsch <bl...@apache.org>.
Marcus Crafter wrote:
>
> Hi All,
>
> We've also been experiencing such problems for the last 2 weeks or so,
> mainly a decrease in performance/response over time under reasonable
> load.
>
> We had a range of errors:
>
> o components not found: fixed recently in avalon's DefaultPool
> (also seems to have improved what was before a memory leak)
I'm glad to see this is no longer a problem. Let me know if it rears
its ugly
head again.
> o decreased performance over time (100 users lasts about 20 minutes,
> 50 users lasts about 40 minutes with our application, before
> performance drops)
What is the load (beyond number of users: time between responses, type
of resource).
> We've been using an up-to-date version of Cocoon2 from trunk CVS and
> have been following the discussions on the mailing list very closely.
Probably should use the cocoon_2_0 branch (check the site for the proper
name).
That is what is being prepared for production readiness. The main trunk
(Cocoon 2.1)
has some new/experimental components that may contribute to stability
issues and
memory leaks.
> In our situation, we've noticed that under load the application's
> performance and response time decreases dramatically, however the
> machine does recover after load has dropped. Once load drops, the
> application starts to settle down and returns to a normal state
> operating state.
The fact that Cocoon recovers gracefully is a testament to its design.
This is
part of the scalability picture. It is understandable that the response
time
will decrease under load, but check below for more information:
> During times of poor performance/response time however, our
> application server is *not* out of resources. We've been able to
> ascertain that both memory and CPU resources are available.
>
> What could cause such a phenomenon ?
Ok. There are two things that can help you: increasing the amount of
memmory
your JVM will use (the java -X options), and manipulating the pool sizes
for
the Components. Cocoon.xconf provides attributes to allow you to
manipulate
the size of Component pools for Poolable Components:
pool-min // Minimum number of Components in the pool
pool-max // Maximum number of Components maintained in the pool
pool-grow // Number of Components to add to the pool each time we run
out.
The Pool will basically turn into a Factory when the number of
Components in
the pool exceed pool-max. This is a performance drain.
We should probably ensure their use in Sitemap Components (any takers on
this?)
> Memory leaks ? I'm not sure if a memory leak would cause a drop in
> performance, unless excessive garbage collection was being done (but
> we have 2gig of RAM, of which 800 meg is not even touched)
Increase your pool sizes and cache sizes. If your JVM is not set to use
all 2 gig
of RAM, then it will perform garbage collection more often.
> Runaway threads ? Could cause such a problem, but they wouldn't allow
> the system to regain itself - or should I not assume this ?
I don't think this is a problem. You would see your CPU maxed out.
> Synchronization problems ? Could there be some synchronization issues
> there which force the jvm to queue threads up for entry to a
> particular method/code block which is considered to be a critical
> area ?
The ComponentManagement framework uses Mutexes to control access--which
is critical
for Cocoon's stability. However, if you can sustain 100 users for 20
minutes before
the slow down occurs, I doubt that synchronization is the culprit.
> Threading issues ? We've also seen cases in the log files under load
> where a single (same) request is handled by 4 separate threads, all
> starting in the same second - quite vexing.
That _might_ be your Servlet Engine. The last time I ran my tests I
used Caucho's
Resin. It is pretty decent, although it has some synchronization issues
of its own
regarding archived files (i.e. jar files). They are so severe that the
entire JVM
crashes.
Try another vendor's Servlet Engine--it _could_ be that Tomcat is the
problem if
4 threads are handling the SAME request.
> Our environment is a on a Sun Enterprise 250 (2x450mhz UltraII, 2gig
> ram), with Tomcat 3.2.3, CVS Cocoon2, and our reporting application
> (generates various html tables and pdf reports).
That sounds very impressive. Can I have one? ;P
> If you have any comments, or questions regarding what we've seen,
> please feel free to respond.
Try the tips I laid out. Recapping:
1) Make sure your JVM is set to use all 2gig of RAM (or however close
you want to be)
2) Play with the pool parameters until you have something that works
3) Try another Servlet Engine (If your problems persist then the issue
is very likely
with Cocoon)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: LoadTest
Posted by Gerd Mueller <ge...@smb-tec.com>.
Hi,
> o decreased performance over time (100 users lasts about 20 minutes,
> 50 users lasts about 40 minutes with our application, before
> performance drops)
I've noticed the same problem. My test setup is rather simple: Tomcat 3.2 or
Jetty, Cocoon 2 b02, IBM JVM on Linux, 1 User that requests always the same
page.
The memory usage of the JVM grows slowly and after some time the GC comes in.
That drops the performance. I've switched off any caching for the pipelines
and then it works quit stable. So, I asume there is a problem with caching.
Also I don't understand why the memory usage slowly grows when switched on
the cache, although I always request the same page (which BTW is build by
content aggregation).
Best Regards,
Gerd
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org