Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Date: Thu, 23 Aug 2001 00:58:06 +0200 (CEST)
From: Marcus Crafter <crafterm@fztig938.bank.dresdner.net>
To: cocoon-dev@xml.apache.org
Subject: Re: LoadTest
In-Reply-To: <3B834440.F134DEA@apache.org>
Message-Id: 
 <Pine.LNX.4.21.0108230011390.27688-100000@fztig938.bank.dresdner.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Berin,

	Hope all is well mate. Thanks again for your advice. Please, don't be
	afraid to give out more! :-)

On Wed, 22 Aug 2001, Berin Loritsch wrote:

> Marcus Crafter wrote:
> > 
> >         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.

	Sure will. :-)

> >         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).

	The load actually changed with today's source code. Thanks to all that
	checked in changes today. Yesterday the load was less on our system
	(averaging between 3 and 6, for 50 and 100 users).
	
	With the changes from today (which have helped dramatically)
	the load is much higher, around 7-14 with the same user counts.

	Performance in general is actually much better than before, even though
	the machine seems to be under more load.

> Probably should use the cocoon_2_0 branch (check the site for the proper
> name).
> That is what is being prepared for production readiness.

	Ok, we've switched over to the cocoon20b2 branch.

> 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.

	Ok. Excellent advice. :-)
	
	We pumped up our pool settings and saw an immediate improvement in
	general application performance, especially when testing directly with
	Tomcat (vs via a ajp13 connector).

	I've increased pooling settings on as much components as I can in our
	cocoon.xconf and sitemap.xmap files (min 32 to max 64 for 50
	simultaneous users).

	There are still several components which are regularly being
	decommissioned in the log files during our tests, that I cannot find
	locations where I can set pooling parameters for. These are:

	org.apache.cocoon.components.language.markup.xsp.XSPMarkupLanguage
	org.apache.avalon.excalibur.component.ExcaliburComponentSelector
	
	and all generated xsp classes, eg:

	org.apache.cocoon.www.client.common.mask.mask_xsp_xml
	(custom generated xsp class).

	Is it possible to set pooling sizes on these components too ?

> 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.

	Yep. Have done already, we're running with mx1526 ms1024m, although I
	missed the MRU settings. I've increased the MRUMemory sizes today from
	60m to 200m (for each event cache, stream cache, and the store).

> >         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.

	I agree. 

> >         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.

	Ouch. Ok, I'll try everything with Resin as well, and also with 
	Tomcat 4. BTW - Have you (or anyone else) experienced performance/load
	problems when using the apache connectors at all ?

> >         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

	Sure, we have 5 of them here :-)

	That's it so far. Thanks very much for your advice Berin, we'll
	continue to test here with the ideas you and others have laid out with
	the current codebase. As we do more testing I'll send in more
	information.

	Cheers,

	Marcus


-- 
        .....
     ,,$$$$$$$$$,      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