cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Crafter <craft...@fztig938.bank.dresdner.net>
Subject Re: LoadTest
Date Wed, 22 Aug 2001 10:44:56 GMT
Hi Berin,

	Thanks very much for your feedback and suggestions - *much* appreciated.
	I will try your suggestions today and send in an email later on
	tonight with the results.

	Cheers,

	Marcus

On Wed, 22 Aug 2001, Berin Loritsch wrote:

> Marcus Crafter wrote:
> > 
> > Hi All,
> > 
> >         We've also been experiencing such problems for the last 2 weeks or so,
> >         mainly a decrease in performance/response over time under reasonable
> >         load.
> > 
> >         We had a range of errors:
> > 
> >         o components not found: fixed recently in avalon's DefaultPool
> >           (also seems to have improved what was before a memory leak)
> 
> I'm glad to see this is no longer a problem.  Let me know if it rears
> its ugly
> head again.
> 
> >         o decreased performance over time (100 users lasts about 20 minutes,
> >           50 users lasts about 40 minutes with our application, before
> >           performance drops)
> 
> What is the load (beyond number of users: time between responses, type
> of resource).
> 
> >         We've been using an up-to-date version of Cocoon2 from trunk CVS and
> >         have been following the discussions on the mailing list very closely.
> 
> Probably should use the cocoon_2_0 branch (check the site for the proper
> name).
> That is what is being prepared for production readiness.  The main trunk
> (Cocoon 2.1)
> has some new/experimental components that may contribute to stability
> issues and
> memory leaks.
> 
> >         In our situation, we've noticed that under load the application's
> >         performance and response time decreases dramatically, however the
> >         machine does recover after load has dropped. Once load drops, the
> >         application starts to settle down and returns to a normal state
> >         operating state.
> 
> The fact that Cocoon recovers gracefully is a testament to its design. 
> This is
> part of the scalability picture.  It is understandable that the response
> time
> will decrease under load, but check below for more information:
> 
> >         During times of poor performance/response time however, our
> >         application server is *not* out of resources. We've been able to
> >         ascertain that both memory and CPU resources are available.
> > 
> >         What could cause such a phenomenon ?
> 
> Ok.  There are two things that can help you: increasing the amount of
> memmory
> your JVM will use (the java -X options), and manipulating the pool sizes
> for
> 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
> 
> 

-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   Open Software Associates GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'     Email : Marcus.Crafter@osa.de
          &&&&.        Business Hours : +49 69 9757 200
    &&&&&&&:


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message