Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4239E45C.8020407@quoininc.com>
Disposition-Notification-To: "Eric E. Meyer" <eric.meyer.cocoon@quoininc.com>
Date: Thu, 17 Mar 2005 15:11:08 -0500
From: "Eric E. Meyer" <eric.meyer.cocoon@quoininc.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Cocoon Performance Woes, Is it flow? I don't know!
References: <4239BED0.7090906@quoininc.com> <4239C735.7070909@apache.org>
In-Reply-To: <4239C735.7070909@apache.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Reinhard Poetz wrote:

> Eric E. Meyer wrote:
>
>> Cocoon Performance Woes, Is it flow? I don't know!
>
>
>> CForms, Javascript flow, mix of JX template generators, XInclude
>> transformer and custom generator transformers. Core application
>> components implemented in Java. Hibernate persistence.
>
>
> Do you use jxmacros in your cforms templates? I remember of some 
> performance tests a few months ago that revealed problems when 
> jxmacros are used. As I've never used jxmacros in production, I'm not 
> sure if this was a problem in my tests or if it is a real existing 
> problem.
>
No, we are not using jxmacros. The JX is really just to parameterize 
xincludes into our top-level page template.

Ralph Goers wrote:

> Also, that seems like a high number of users for such a little amount 
> of memory.  You may just be garbage collecting a lot. 

On Linux, with 1G physical, 512M mx,ms and verbose:gc, I did not see any 
excessively long garbage collection cycles. On Windows, with mx256M, I'm 
generally seeing short incremental GC cycles around 50ms, but I did see 
one 11 second full GC during my last run.  But the deployment machine is 
much beefier (and the VM memory allocation twice the size). I'll 
re-verify on the Linux server.

Also, for curiosity, I re-ran the tests with the embedded form in the 
search results page removed. That had a positive impact on performance:

With refine-search form:

users overall home  search1 search2 search3  detail  total
      avg ms  page                                   num reqs

10      486    208      637    588     644     355    500
20     1704    378     2684   1837    2875     745    500
30     3725    682     5987   4626    6270    1059    450
40    19461   1411    36021  23089   34726    2059    600
50    72942   3213   130482  90993  131666    8356    500

Without refine-search form:
10     645     518      646    725     711     627    500
20     800     266     1116    963    1024     629    500
30    2539     634     4451   3003    3908     698    450
40    4716    1430     6936   4829    8040    2347    600
50    7978    1328    13063   8669   14122    2710    500

Regards,
Eric Meyer