Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: 
 <95388DA5BD94D411B1E50002A528A91E02788F2F@pisces-exch.de.eu.corp.vizzavi.net>
From: "Rottmann, Lars" <Lars.Rottmann@vodafone.com>
To: "'dev@cocoon.apache.org'" <dev@cocoon.apache.org>
Subject: AW: AW: Cocoon 2.1.3 breakdown when load testing
Date: Wed, 7 Jan 2004 18:25:29 +0100 
MIME-Version: 1.0
Content-Type: text/plain


Hello again,

my tests over the last night were partly successful. I managed to make a run
of about 7000000 requests and the server was still alive this morning. 

This showed to me that my guess was obviously right. The log messages I
posted earlier raised the suspicion in me that maybe the StaticBucketMap
used by the excalibur-component package isn't really threadsafe. So I
patched the ExcaliburComponentManager and ExcaliburComponentSelector and
replaced all references to it with a java.util.Hashtable. Okay, I know this
is not the fastest solution, but it worked. The "ComponentLocator exception
from parent CM during lookup" appeared no longer in the logs. So I fear I've
found a serious bug there.

The tests were only partly sucessful as I said because I noticed a
considerable loss of performance over the time (over 75% in 14 hours). What
I really wonder about is that the transaction rate per second dropped from
one point the other from 170 to 60. At that time a file rotation of Cocoon's
logs took place. The transaction rate did not recover again. I will test
again this night without log rotation turned on to see if this has any
impact on the overall performance.

Does anyone of you know if the following log message from the
cocoon-sitemap.log is of major importance? Might there be a link to the loss
of performance I noticed, maybe because of a declining number of available
pooled components? 

WARN    (2004-01-06) 17:19.49:453   [sitemap] (/vsky/index.preg)
wap-4/ExcaliburComponentSelector: Attempted to release a org.apache.coc
oon.components.pipeline.impl.CachingProcessingPipeline but its handler could
not be located.


I love posting the results of my performance tests and it's parameters once
I know that everythings works fine and stable over the time.

Lars


>>we are currently migrating from a rather old development version of 
>>Cocoon (december 2002) to the latest stable release 2.1.3. The 
>>increase in performance is awesome, but unfortunately we are facing 
>>reproducable faulty behaviour when load testing the actual version. 
>>After delivering roughly
>>20000+ pages without an error, the server starts sending back error 
>>with status code 500.
>>
>>This is the configuration we use for testing: Sun Fire V480 (OS 5.8) 
>>with 2x 900 MHz, 4 GB RAM, Cocoon 2.1.3 (with Xalan as XSLT 
>>processor), Jetty 4.2.12, Sun Java 1.4.2_02-b03. We do the load 
>>testing with the tool "Siege" (version 2.56) with 40 concurrent users 
>>requesting 2000 pages each.
>[...]
>
>
>I now have an educated guess. Probably tomorrow I can give more details. I
still have to cross-check something and do another long-term >test over the
night. 


Vodafone Global Content Services Limited 
Registered Office:  Vodafone House, The Connection, Newbury, Berkshire  RG14 2FN

Registered in England No. 4064873 

This e-mail is for the addressee(s) only.  If you are not an addressee, you
must not distribute, disclose, copy, use or rely on this e-mail or its
contents, and you must immediately notify the sender and delete this e-mail
and all copies from your system.  Any unauthorised use may be unlawful.  The
information contained in this e-mail is confidential and may also be legally
privileged.