cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: AW: IT'S TIME TO REDO YOUR TESTS, GENTLEMEN!
Date Thu, 23 Aug 2001 13:09:20 GMT
Gerhard Froehlich wrote:
> 
> Hi,
> According to my tracing tool (OptimizeIT) most of the cpu time was consumed
> by the method java.util.ZipFile.open(). As I traced down the thread
> the first "core" method from cocoon I hit in this tree of method invocations
> was the process() method of the CachingPipline. Ok that's plausibly of
> course.
> But the load is caused through the ClassLoaders, which I suspect unzip the
> jar files of the libaries, which are used from the different serializer,
> transformers,... Is this inevitabile? Or can some caching of already loaded
> classes help on this problem, if it is possible? Or is this a general java
> problem?
> 
> Attached are the report file of my load test and the tracing of
> java.util.ZipFile.open().
> I don't want to blame anybody, I just want to participate somehow.


I have created and Active Monitor class that would help us minimize the number
of accesses to the webapp resources.  Using the FileResource, we can register
and class (i.e. the cache, etc.) with a PropertyChangeListener.  That listener
will recieve messages who's name is the same as the resource being monitored.
This effectively eliminates our need to call ${file}.lastModified() directly from
our code.  Each resource in the collection of resources is tested on a frequency
you specify (i.e. 1/minute, 1/half-hour, etc.).  That way during extreme load
conditions the number of times we call the "lastModified" method doesn't change.
Instead of 1/request (with 200 simultaneous users requesting 4 pages a second
that comes to 800 calls a second) it is once per period of time.  Even at one
second, you have called "lastModified" 1/800th of the time using the afforementioned
example.  It defaults to once per minute which is 1/24000th of the time (that
is 2400000% decrease in calls.

The Monitor class is in Excalibur's scratchpad section--awaiting the soon inclusion
in the main excalibur jar.

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


Mime
View raw message