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:[EMAIL PROTECTED]]
> Sent: Wednesday, 22 August 2001 2:45 pm
> To: [EMAIL PROTECTED]
> Subject: RE: LoadTest
>
>
> > -----Original Message-----
> > From: Matthew Langham [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, August 22, 2001 6:09 AM
> > To: [EMAIL PROTECTED]
> > 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 [[EMAIL PROTECTED] - 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: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
=======================================================================
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
