cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew Langham" <mlang...@sundn.de>
Subject AW: LoadTest
Date Wed, 22 Aug 2001 10:09:25 GMT
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)?

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


Mime
View raw message