Re: Benchmarking Tapestry

denko" To: "Tapestry users" 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

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

Re: Benchmarking Tapestry

The reason the session impacts the scalability of Wicket applications under high load (large numbers of concurrent users) is that Wicket, by default and by design will store the entire component model for a Page (and all pages referenced by that page - and multiple versions of those pages!!) - in

Re: Benchmarking Tapestry

Neil, Your behavior could be GC related. If you connect JConsle have any of the memory pools filled up? If that is the case you may be seeing the GC using a disproportionate amount of CPU. Ben Gidley www.gidley.co.uk b...@gidley.co.uk On Tue, May 12, 2009 at 7:47 PM, Neil Curzon wrote: > Th

Re: Benchmarking Tapestry

Session or no, T5 still uses pooled pages; there's just an incremental cost for each additional persisted field; since few pages have more than a couple, this is rarely a problem. And it means that generally, the values stored in the HttpSession are small immutables, such as Integer or String. Not

Re: Benchmarking Tapestry

> > > > > > All of my page views were done without a session, and it seems that > Wicket's > > raw performance advantage will only increase when the session comes into > > play. I understand that will come at the cost of scalability via > clustering > > and memory consumption, though. I do agree th

Re: Benchmarking Tapestry

On Tue, May 12, 2009 at 1:00 PM, Neil Curzon wrote: > Well, whether a page view is executed in one framework or another, the same > calls into the service layer should be made, and the same persistence > queries should be executed. As long as the frameworks' component lifecycles > are co-operative

Re: Benchmarking Tapestry

Well, whether a page view is executed in one framework or another, the same calls into the service layer should be made, and the same persistence queries should be executed. As long as the frameworks' component lifecycles are co-operative with the design of your application (big if?), the load on t

Re: Benchmarking Tapestry

On May 12, 2009, at 2:47 PM, Neil Curzon wrote: I think it should be possible to reason about the web framework independently from the back end. However it just ain't so. If the front-ends had equivalent architectural impact, then sure. Or if everything were serial, then sure. However

Re: Benchmarking Tapestry

Thanks for your input everyone. I don't exactly expect the web framework to be the bottleneck at 700+ requests per second, but I'm keeping these things in mind too. I think it should be possible to reason about the web framework independently from the back end. In our case it will be the exact sam

Re: Benchmarking Tapestry

specially the DOM which is notoriously slow). Peter - Original Message - From: "Howard Lewis Ship" To: "Tapestry users" Sent: Tuesday, 12 May, 2009 02:00:50 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Benchmarking Tapestry On Mon, May 11, 2009 at

Re: Benchmarking Tapestry

quot; To: "Tapestry users" Sent: Tuesday, 12 May, 2009 13:43:21 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Benchmarking Tapestry > Um, data retrieval is usually made across a network connection, even > to the localhost, it's still likely to add up more latenc

Re: Benchmarking Tapestry

relating to this e-mail. - Original Message - From: "Christian Edward Gruber" To: "Tapestry users" Sent: Tuesday, 12 May, 2009 11:07:21 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Benchmarking Tapestry Um, data retrieval is usually made across a network con

Re: Benchmarking Tapestry

On Tue, May 12, 2009 at 10:02 AM, Ben Gidley wrote: > I do disagree :) Very nice and very interesting work Ben! Thanks a lot for sharing. Regards -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: users-unsubscr

Re: Benchmarking Tapestry

0:50 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Benchmarking Tapestry On Mon, May 11, 2009 at 12:10 PM, Thiago H. de Paula Figueiredo wrote: Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon > escreveu: Tapestry 5.0.18: I missed this earlier; yes, 5.0.18 had not yet been optimiz

Re: Benchmarking Tapestry

M > which is notoriously slow). > > Peter > > - Original Message - > From: "Howard Lewis Ship" > To: "Tapestry users" > Sent: Tuesday, 12 May, 2009 02:00:50 GMT +02:00 Athens, Beirut, Bucharest, > Istanbul > Subject: Re: Benchmarking Ta

Re: Benchmarking Tapestry

Peter - Original Message - From: "Howard Lewis Ship" To: "Tapestry users" Sent: Tuesday, 12 May, 2009 02:00:50 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Benchmarking Tapestry On Mon, May 11, 2009 at 12:10 PM, Thiago H. de Paula Figueiredo wrote: > Em Mo

Re: Benchmarking Tapestry

On Mon, May 11, 2009 at 12:10 PM, Thiago H. de Paula Figueiredo wrote: > Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon > escreveu: > >> Tapestry 5.0.18: I missed this earlier; yes, 5.0.18 had not yet been optimized for memory or speed. Anything in the 5.1, preferable 5.1.0.5 the stable releas

Re: Benchmarking Tapestry

Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon escreveu: Tapestry 5.0.18: Requests per second:776 Average resp time (ms): 25.41075 Have you tried Tapestry 5.1.0.5? There were some improvements in the rendering process starting at 5.1.0.1. Another issue is to have the same machine b

Re: Benchmarking Tapestry

I have been doing a series of benchmarks - the latest one is at Tapestry Load Testing - Struts Vs Tapestry Round 2. My results show something that may be relevant here. When I started this I had a really simple application (like

Re: Benchmarking Tapestry

My take is that T5's model of rendering to the DOM will always impact performance. I am surprised the numbers are skewed as much as they are. Still, at all levels (not just rendering) T5 is doing way more than the other frameworks. There's also a lot of room for tuning; you might want to increase

Re: Benchmarking Tapestry

One interesting methodology question is whether taking an instantaneous value (even an instantaneous average) is really helpful. What would probably be more interesting (to me) is to see what different levels of simultaneous simulated requests per second caused, 1/s, 10/s, 100/s, 1000/s.