cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
Subject AW: LoadTest
Date Wed, 22 Aug 2001 23:36:08 GMT
Morning Vadim,
I have just tested cocoon with your patch (by the way, can
you explain me how to diff between 2 files?).
It's a little bit late, and I don't know if I did every-
thing right:
I shoot only 5 threads against /cocoon/hello.html to test
your changes. The load is still high, but it seems to be a
other reason now: java.io.Win32FileSystem.getLastModifiedTime()
now eats 50% CPU time.
org.apache.cocoon.components.source.URLSource.getInfos()
org.apache.cocoon.components.source.URLSource.getLastModified()
org.apache.cocoon.sitemap.Handler.hasChanged()
org.apache.cocoon.sitemap.Manager.getHandler()
org.apache.cocoon.sitemap.Manager.invoke()
org.apache.cocoon.Cocoon.process()
are invokers of this method.

I attached the trace file to this mail. I will test it
again tomorrow. I have a 14 days trail software, that
should be sufficient :).
Will catch some sleep now...

Cheers
Gerhard
>-----Ursprungliche Nachricht-----
>Von: Vadim Gritsenko [mailto:vgritsenko@yahoo.com]
>Gesendet: Thursday, August 23, 2001 1:03 AM
>An: cocoon-dev@xml.apache.org
>Betreff: RE: LoadTest
>
>
>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