Sylvain Wallez wrote:
Eric E. Meyer wrote:
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
The difference is impressive. Do I read well that it's 10 times faster with 50 users without forms? How are the parallel users defined?
Using JMeter, 50 threads each requesting the five pages in sequence - with an approximately 3 second wait time between page requests. Looking with Ethereal, I can seen that the client is not using cookies, and that each thread appears to have it's own keep-alive connection.
Note that flow is used even in the case when I removed the refine-search form, as the top-level configuration of the search based upon the URL is done by some flowscript that ultimately calls cocoon.sendPage() to serve the results page. That second pipeline normally has top-level flow to create and bind the refine search form, and that's what I removed.
Execution of a flowscript is synchronized on the global variable scope, which is bound to the session. Although this shouldn't be a problem in real world as a single user is not very likely to send parallel requests, you should verify that your load testing engine uses different sessions (or no session at all) for the simulated concurrent users. That may explain these numbers.
Sylvain
Regards, Eric
