Vadim Gritsenko wrote:
>
> > -----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.
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 [[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
