cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Morrison" <john.r.morri...@ntlworld.com>
Subject RE: LoadTest
Date Wed, 22 Aug 2001 19:25:41 GMT
I'd have to learn DocBook xml (or whatever is decided upon) first, but yes,
I'll add to the documentation.  It would be useful for people to report real
life hardware and cache/pool combinations no?

J.

> -----Original Message-----
> From: Vadim Gritsenko [mailto:vgritsenko@hns.com]
> Sent: Wednesday, 22 August 2001 3:57 pm
> To: cocoon-dev@xml.apache.org
> Subject: RE: LoadTest
>
>
> This topic is covered in Berin's TOC ([Docs] Installation and
> Configuration):
>
>     C) Tuning Cocoon
>        1) Pool controlling attributes (min/max/etc)
>        2) Finding optimal Cache settings
>
> Could you write this chapter? ;)
>
> Vadim
>
> > -----Original Message-----
> > From: Morrison, John [mailto:John.Morrison@uk.experian.com]
> > Sent: Wednesday, August 22, 2001 10:12 AM
> > To: 'cocoon-dev@xml.apache.org'
> > Subject: RE: LoadTest
> >
> >
> > I think that there's a need in the documentation as to what
> caches can be
> > configured, how and how to work out 'reasonable' values before
> > 'tweaking'...?
> >
> > > -----Original Message-----
> > > From: Vadim Gritsenko [mailto:vgritsenko@hns.com]
> > > Sent: Wednesday, 22 August 2001 2:45 pm
> > > To: cocoon-dev@xml.apache.org
> > > Subject: RE: LoadTest
> > >
> > >
> > > > -----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
> > >
> >
> >
> > =======================================================================
> > Information in this email and any attachments are confidential, and may
> > not be copied or used by anyone other than the addressee, nor disclosed
> > to any third party without our permission.  There is no intention to
> > create any legally binding contract or other commitment through the use
> > of this email.
> >
> > Experian Limited (registration number 653331).
> > Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
> >
> > ---------------------------------------------------------------------
> > 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


Mime
View raw message