Using the session extensively is not scalable as the container must allocate additional resources, which translates to more heap. Response times also change with server load, so to have any accurate measure the performance for a framework you need to consider the memory footprint, graceful degradation, concurrency, and more... Someone has mentioned the performance curve as the number of concurrent users increases, you will need to correlate the containers load with response times for concurrent sessions. Its not an easy task.
Peter ----- Original Message ----- From: "Sergey Didenko" <sergey.dide...@gmail.com> To: "Tapestry users" <users@tapestry.apache.org> Sent: Wednesday, 13 May, 2009 18:34:42 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Benchmarking Tapestry Exactly. And "thousands of concurrent users" can be not just the number of users per minute, but the number of users per day! Because when a user session expires any dynamic wicket link shows "Your session is expired. Click here to return to the main page" message. To avoid this you would want to increase session life for a business day for example. On Wed, May 13, 2009 at 2:08 PM, JoelGrrrr <j...@su3analytics.com> wrote: > Thus - Wicket may or may not render a single page faster than T5 under > certain circumstances (according to the 5.0.18 benchmarks above) but it does > not mean that it will scale well under high load (for many thousands of > concurrent users) without resorting to complex session clustering or very > judicious application design which can end up "obfuscating" the code > considerably. This is a well known "gotcha" for Wicket newbies. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
