cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vgritse...@hns.com>
Subject RE: LoadTest
Date Wed, 22 Aug 2001 14:56:39 GMT
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


Mime
View raw message