Reinhard Poetz wrote:
No, we are not using jxmacros. The JX is really just to parameterize xincludes into our top-level page template.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.
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 reqs10 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
