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
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
t;
>>> cheers,
>>> Christian Edward Gruber
>>> christianedwardgru...@gmail.com
>>> http://www.geekinasuit.com/
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail:
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
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
>
>
> >
> > 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
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
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
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
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
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
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
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
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
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
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
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
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
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
75/332
> > under a heavy application, or whether the proportion scales. It could
> even
> > invert, depending on the subtleties of the application.
> >
>
> What he said :-)
>
> > Benchmarking is hard. ;)
>
> What he said :-)
>
> >
> > cheers,
> &
n into more like 225/207, or 375/332
> under a heavy application, or whether the proportion scales. It could even
> invert, depending on the subtleties of the application.
>
What he said :-)
> Benchmarking is hard. ;)
What he said :-)
>
> cheers,
> Christian.
>
> On 11-M
y taken up benchmarking Tapestry 5.0.18 against Wicket
1.3.5 and
Stripes 1.5.1. For fun, I also threw in an implementation in Model 2
Servlet/JSP. The first were a little surprising to me (Tapestry did
not come
close to winning), and I'm wondering if anybody could comment on my
methodo
Hi all,
I've recently taken up benchmarking Tapestry 5.0.18 against Wicket 1.3.5 and
Stripes 1.5.1. For fun, I also threw in an implementation in Model 2
Servlet/JSP. The first were a little surprising to me (Tapestry did not come
close to winning), and I'm wondering if anybody could
23 matches
Mail list logo
