cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vgritse...@yahoo.com>
Subject RE: LoadTest
Date Wed, 22 Aug 2001 23:02:39 GMT
Marcus,
Do not use cocoon20b2 - this is really old beta release!
Switch to cocoon_20_branch - that's the RC Berin is talking about.

Vadim

> -----Original Message-----
> From: Marcus Crafter [mailto:crafterm@fztig938.bank.dresdner.net]
> Sent: Wednesday, August 22, 2001 6:58 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: LoadTest
> 
> 
> 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
> 

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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


Mime
View raw message