I've a project in the late end phase and we started load testing last week.
We
also realized strange behaviour in cocoon:
Lars Rottmann wrote:
>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.
When testing with one client I also noticed that cocoon is slowing down the
longer the application is running. And I cut logging down to ERROR level. My
log files stay empty at all.
Carsten Ziegeler wrote:
>Cocoon currently uses commons-collections-2.1, did you try the latest
>version
>from CVS. There were some bug fixes to the StaticBucketMap (which is now in
>the map subpackage). I don't know if the bug fixes are fixing threading
>problems, but perhaps it's worth a try.
After I read the mail from Carsten I included the newest source for the
StaticBucketMap and things got a little better. Look the numbers downpage.
- o -
Configuration
.
My configurations are:
LINUX) IBM NetVista Pentium 4, Linux 8.2, Java 1.4.1_02-b06, tomcat 4.1.18,
memory limited to 64M
WINDOWS) IBM R40 (Laptop) Pentium 4M, W2k, Java Java 1.3.1_09,
tomcat 4.1.27, memory limited to 64M
For testing I use anteater 0.9.16. The test of the application consists
of a call to 3 pages:
P1. One page where the user has to login
P2. A page where the user choses his profile
P3. A page where some search results are displayed
P3. is repeated 4000 times.
P1. and P2. are simple pages, but P3. is a rather complex thing with heavy
syndicated content. It is reached over 4 sitemaps. And also the generator
an XSP page uses the SourceResolver to get another source for further
processing.
Cocoon is configured to do no caching.
We use OptimizeIT for profiling and we found 2 strange things.
1) StaticBucketMaps are generated with each request and stay in the heap
2) for each call to P3. one byte[] stays in the heap
- o -
Sitemapdesigns
.
Our sitemap structure looks like:
1) sitemap.xmap - here the main matches are declared that mount to other
sitemaps
<match pattern="applications">
<map:mount uri-prefix="applications" .../>
</match>
<match pattern="datasources">
<map:mount uri-prefix="applications" .../>
</match>
<match pattern="main">
<map:mount uri-prefix="applications" .../>
</match>
2) main.xmap - this is the sitemap where all resources that can be reached
by http://... are declared.
<match pattern="**.html">
...
<map:aggregate element="page" label="debug1">
<map:part src="cocoon://applications/top"/>
<map:part src="cocoon://applications/info/{1}/{2}"/>
<map:part src="cocoon://applications/content/{1}/{2}"/>
<map:part src="cocoon://applications/navigation"/>
<!--<map:part src="cocoon://applications/footer"/>-->
</map:aggregate>
...
</match>
3) application.xmap - here all fragments for content syndication are
declared
<map:match pattern="content/search/*">
...
<map:aggregate element="page" label="debug1">
<map:part src="cocoon://datasources/search/search.xsp"/>
<map:part src="cocoon://datasources/search/filter-list-filters.xsp"/>
</map:aggregate>
...
</map:match>
4) datasources.xmap - here all datasources (rough XML) is declared
<map:match pattern="**.xsp">
<map:generate src="resources/controller/{1}.xsp" type="serverpages"/>
<map:serialize type="xml"/>
</map:match>
All pipelines are heavily using selectors and input modules.
When P3 is served from within Cocoon (I omitted the map praefix) the
pipeline
call graph looks like
<match pattern="**">
<mount src="main.xmap">
<match pattern="**.html">
<part src="cocoon://applications/content/search/search"/>
<match pattern="content/search/*">
<part src="cocoon://datasources/search/search.xsp"/>
<match pattern="**.xsp">
<generate src="resources/controller/search/search.xsp" .../>
in search.xsp the XSPUtil is used to resolve another xsp page from the
datasources.xmap. This uses the protocol 'cocoon:/'.
- o -
Tests
.
The intersting thing now is, when I use the protocol 'cocoon:/' the tests
break. I added a matrix with the different configurations and after how
many iterations they break:
+-----------------------------+--------+----------+
| | LINUX) | WINDOWS) |
+-----------------------------+--------+----------+
| commons-collections-2.1.jar | 136 | 143 |
+-----------------------------+--------+----------+
| commons-collections-3.0.jar | 147 | 145 |
+-----------------------------+--------+----------+
After playing around I tried the same testcase with the 'http://' protocol,
and - tadaam! - the application did 4000 iterations! BTW does anyone know
how
ant can do loops?
Ok. So far so god. We made memory snapshots after P1, P2 and 8 iterations
of P3. At this point the heap contains (11 biggest)
+ -------+------------------------------------------------------+---------+
| # inst.| class | size KB |
+--------+------------------------------------------------------+---------+
| 163000 | o.a.commons.collections.StaticBucketMap$Lock | 2550 |
| 40714 | Object[] | 3208 |
| 38141 | java.lang.String | 893 |
| 37623 | char[] | 4301 |
| 20992 | int[] | 1919 |
| 14036 | java.util.ArrayList | 328 |
| 23844 | EDU.oswego.cs.dl.util.concurren.LinkNode | 200 |
| 12844 | o.a.commons.collections.StaticBucketMap$ValueIterator| 401 |
| 12843 | o.a.commons.collections.StaticBucketMap$Values | 200 |
| 9138 | java.util.HashMap$Entry | 214 |
| 7991 | byte[] | 10008 |
+........+......................................................+.........+
After that we made another snapshot with P1, P2 and 8 iterations of P3. And
when we looked to the heap again the obvious thing was that 8 new byte[] of
about 256 KB each where now on the heap. This correlated to our measures
that
the heap grew 2M for 8 iterations.
I also followed the thread
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106499263427833&w=2 where
Sylvains answer made me curious about the
o.a.c.components.source.impl.SitemapSource at all.
I have to admit that I've never been that deep in Cocoon and it's late
today.
Tomorrow i'll get into this topic. My only question for today is, is this
a memory leak? Lars could you reduce your memory to a minimun and check out
what happens then?
Regards
Michael
--
+++ GMX - die erste Adresse f�r Mail, Message, More +++
Neu: Preissenkung f�r MMS und FreeMMS! http://www.gmx.net
