You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ovidiu Predescu <ov...@cup.hp.com> on 2001/08/23 01:24:09 UTC
Re: LoadTest
Vadim,
Are the recent changes applied to main trunk as well as to
cocoon_20_branch?
Thanks,
Ovidiu
On Wed, 22 Aug 2001 19:02:39 -0400, "Vadim Gritsenko" <vg...@yahoo.com> 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.
>
> 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
>
>
---------------------------------------------------------------------
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>.
I usually patch both branches together,
so - yes. Plus, you may want to try patch
I sent to Gerhard - it also should
improve performance a little bit.
Vadim
> -----Original Message-----
> From: ovidiu@orion.rgv.hp.com [mailto:ovidiu@orion.rgv.hp.com]On Behalf Of Ovidiu Predescu
> Sent: Wednesday, August 22, 2001 7:24 PM
> To: Vadim Gritsenko
> Cc: cocoon-dev@xml.apache.org
> Subject: Re: LoadTest
>
>
> Vadim,
>
> Are the recent changes applied to main trunk as well as to
> cocoon_20_branch?
>
> Thanks,
> Ovidiu
>
> On Wed, 22 Aug 2001 19:02:39 -0400, "Vadim Gritsenko" <vg...@yahoo.com> 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.
> >
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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