cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: Cocoon Performance Woes, Is it flow? I don't know!
Date Thu, 17 Mar 2005 17:52:09 GMT
Also, that seems like a high number of users for such a little amount of 
memory.  You may just be garbage collecting a lot.

Eric E. Meyer wrote:

>
> Observations
>
> Windows XP
> Pentium 4 1.8Ghz
> JDK 1.4.2_06
> Tomcat 5.0.28
> Cocoon 2.1.5.1
> 512MB physical RAM
> JVM -server -Xms256M -Xmx256M
>
> Load test with num users threads each making 5 successive request in a
> loop with approximately 3 second think time between requests. No derived
> resources – only the main page.
>
> 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
>
> home page: /
> search1: /luxury_hotels/europe__france__paris/index.html
> search2: /luxury_hotels/bahamas_%26_the_caribbean/beach_resort/index.html
> search3:
> /luxury_hotels/europe__france__paris/city_centre_location/index.html
> detail: /luxury_hotel/new_york,_ny/the_carlyle
>
> Platform:
>
> Development
> Windows XP
> JDK 1.4.2_06
> Tomcat 5.0.28
> Cocoon 2.1.5.1
>
> Deployment
> Linux 2.6.x
>
> We see similar degradation on Linux as on Windows.
>
> The home page has no flowscript or cforms, but does have jxtemplate
> generation, xinclude, xslt, and a custom generator.
>
> The search and detail pages include a cform, and are therefore driven
> with flowscript at the top-level matching (and create continuations in
> the process of displaying their forms). These pages use jxtemplate
> generation, xinclude, xslt, custom generation, custom transformation,
> and internal-only sub pipelines. When looking at the pipeline times with
> a profiling pipeline, the total times (while under load) are much higher
> that the displayed times for the setup and generation steps -- so where
> is the time going?
>
> Regards,
> Eric Meyer
>
>
>
>


Mime
View raw message