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 13:45:17 GMT
> -----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


Mime
View raw message