You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Neil Curzon <ne...@gmail.com> on 2009/05/11 19:26:16 UTC
Benchmarking Tapestry
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 comment on my
methodology.
I have 5 simple pages that use the same simple layout, whose middle body
component has a dynamic bit (the current time), to prevent any kind of low
level caching. In tapestry, this looked like this:
Layout.tml:
<html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd">
<h1>Here's the Layout Beginning</h1>
<t:body/>
<h2>Here's the layout End</h2>
</html>
Page1.tml
<div t:type="layout" xmlns:t="
http://tapestry.apache.org/schema/tapestry_5_0_0.xsd">
Page 1 Dynamic content: ${currentTime}
</div>
In Wicket:
Layout.html:
<html>
<wicket:border>
<h1>Here's the Layout Beginning</h1>
<wicket:body/>
<h2>Here's the layout End</h2>
</wicket:border>
</html>
Page1.html:
<span wicket:id = "layout">
Page 1 Dynamic content: <span wicket:id="dynamic"/>
</span>
Tapestry and Wicket were both configured to run in production mode before
the benchmarking. Each request went to 1 of 5 different Pages randomly (each
page was similar to above). I used 20 Threads in parallel, each performing
10,000 such requests. The client was a raw socket Java program writing the
HTTP GET and reading the entire response. The results are as follows:
Tapestry 5.0.18:
Requests per second: 776
Average resp time (ms): 25.41075
Wicket 1.3.5:
Requests per second: 2574
Average resp time (ms): 7.72404
Wicket was the only framework that outperformed (slightly) the JSP/Servlet
solution. I found these results surprising, as it was my perception that
Tapestry would scale more easily than Wicket. Instead, I found Tapestry to
perform about on par with Stripes.
Is my methodology flawed somehow? How could I improve it? Any input would be
greatly appreciated.
Thanks
Neil
Re: Benchmarking Tapestry
Posted by Ben Gidley <be...@gidley.co.uk>.
I have been doing a series of benchmarks - the latest one is at Tapestry
Load Testing - Struts Vs Tapestry Round
2<http://blog.gidley.co.uk/2009/05/tapestry-load-testing-struts-vs.html>.
My results show something that may be relevant here.
When I started this I had a really simple application (like yours) and
struts was beating tapestry (but not by as much as you are seeing), however
as I have increased the complexity tapestry has overtaken the struts app.
Benchmarking is hard (as was stated earlier), and benchmarking a framework
is even harder. The main issue is in a really application 90% of the time
will be spent in your code (e.g. accessing the db) and not in the framework.
A couple of things you probably want to check
- Did you have tapestry in production mode - it makes a huge difference
:)
- You need your page pools as Howard set to have the soft wait time as
big as the number of concurrent threads
- Are you measuring the page + objects or just the page. Again if you are
including objects you will mainly be measuring the containers speed.
I think your numbers do look high - but it does depend on what you ran this
on. In my test Tapestry 5 Load Testing - Struts vs Tapestry - Round
1<http://blog.gidley.co.uk/2009/05/tapestry-5-load-testing-struts-vs.html>
had
a similar application and was getting responses in 15ms under a very similar
load. I was using a dual core virtual machine in our companies cloud.
One thing I will say is I wouldn't pick your framework on performance. It
needs to perform 'enough' and not stink (e.g. have substantial bottlenecks)
- tests which I think tapestry passes easily - but you really should focus
on usability and ease of coding.
Ben Gidley
www.gidley.co.uk
ben@gidley.co.uk
On Mon, May 11, 2009 at 7:03 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> 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 the
> page pool cache to match the number of request processing threads;
> it's quite possible that the T5 application was spending a lot of its
> time waiting for active pages to return to the pool (the soft limit,
> and soft wait). Expanding the hard and soft limits to match the
> available threads will remove a lot of that.
>
> Again, adding even a tiny amount of DB access might compress the
> difference between Wicket and Tapestry to a non-issue.
>
> On Mon, May 11, 2009 at 10:39 AM, Christian Edward Gruber
> <ch...@gmail.com> wrote:
> > 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.
> > What is the curve of performance degredation on a single machine, a
> > multi-core single machine, multiple machines, etc., with geometric
> traffic
> > growth.
> >
> > The reason this is interesting is that sometimes one thing will perform
> very
> > quickly at one tier, but poorly at another, and something slower will
> scale
> > more gracefully.
> >
> > The other methodology problem is that the simplest page merely shows
> > overhead, but there may be efficiencies in the handling of complex pages,
> > first-load, subsequent load, etc., that will be different for the
> different
> > frameworks. So actually having the simple case, then a moderate, then
> heavy
> > application which have similar fundamental architectures (say, hibernate
> +
> > database using the same persistence strategy - heck, possibly even
> reusing
> > the same DAOs, if possible). This would give a sense whether the
> > differences you're seeing of 25/7 turn 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-May-09, at 13:26 , Neil Curzon wrote:
> >
> >> 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 comment on my
> >> methodology.
> >>
> >> I have 5 simple pages that use the same simple layout, whose middle body
> >> component has a dynamic bit (the current time), to prevent any kind of
> low
> >> level caching. In tapestry, this looked like this:
> >>
> >> Layout.tml:
> >> <html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd">
> >> <h1>Here's the Layout Beginning</h1>
> >> <t:body/>
> >> <h2>Here's the layout End</h2>
> >> </html>
> >>
> >> Page1.tml
> >> <div t:type="layout" xmlns:t="
> >> http://tapestry.apache.org/schema/tapestry_5_0_0.xsd">
> >> Page 1 Dynamic content: ${currentTime}
> >> </div>
> >>
> >> In Wicket:
> >> Layout.html:
> >> <html>
> >> <wicket:border>
> >> <h1>Here's the Layout Beginning</h1>
> >> <wicket:body/>
> >> <h2>Here's the layout End</h2>
> >> </wicket:border>
> >> </html>
> >>
> >> Page1.html:
> >> <span wicket:id = "layout">
> >> Page 1 Dynamic content: <span wicket:id="dynamic"/>
> >> </span>
> >>
> >> Tapestry and Wicket were both configured to run in production mode
> before
> >> the benchmarking. Each request went to 1 of 5 different Pages randomly
> >> (each
> >> page was similar to above). I used 20 Threads in parallel, each
> performing
> >> 10,000 such requests. The client was a raw socket Java program writing
> the
> >> HTTP GET and reading the entire response. The results are as follows:
> >>
> >> Tapestry 5.0.18:
> >> Requests per second: 776
> >> Average resp time (ms): 25.41075
> >>
> >> Wicket 1.3.5:
> >> Requests per second: 2574
> >> Average resp time (ms): 7.72404
> >>
> >> Wicket was the only framework that outperformed (slightly) the
> JSP/Servlet
> >> solution. I found these results surprising, as it was my perception that
> >> Tapestry would scale more easily than Wicket. Instead, I found Tapestry
> to
> >> perform about on par with Stripes.
> >>
> >> Is my methodology flawed somehow? How could I improve it? Any input
> would
> >> be
> >> greatly appreciated.
> >>
> >> Thanks
> >> Neil
> >
> > Christian Edward Gruber
> > e-mail: christianedwardgruber@gmail.com
> > weblog: http://www.geekinasuit.com/
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
> Director of Open Source Technology at Formos
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Benchmarking Tapestry
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 the
page pool cache to match the number of request processing threads;
it's quite possible that the T5 application was spending a lot of its
time waiting for active pages to return to the pool (the soft limit,
and soft wait). Expanding the hard and soft limits to match the
available threads will remove a lot of that.
Again, adding even a tiny amount of DB access might compress the
difference between Wicket and Tapestry to a non-issue.
On Mon, May 11, 2009 at 10:39 AM, Christian Edward Gruber
<ch...@gmail.com> wrote:
> 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.
> What is the curve of performance degredation on a single machine, a
> multi-core single machine, multiple machines, etc., with geometric traffic
> growth.
>
> The reason this is interesting is that sometimes one thing will perform very
> quickly at one tier, but poorly at another, and something slower will scale
> more gracefully.
>
> The other methodology problem is that the simplest page merely shows
> overhead, but there may be efficiencies in the handling of complex pages,
> first-load, subsequent load, etc., that will be different for the different
> frameworks. So actually having the simple case, then a moderate, then heavy
> application which have similar fundamental architectures (say, hibernate +
> database using the same persistence strategy - heck, possibly even reusing
> the same DAOs, if possible). This would give a sense whether the
> differences you're seeing of 25/7 turn 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-May-09, at 13:26 , Neil Curzon wrote:
>
>> 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 comment on my
>> methodology.
>>
>> I have 5 simple pages that use the same simple layout, whose middle body
>> component has a dynamic bit (the current time), to prevent any kind of low
>> level caching. In tapestry, this looked like this:
>>
>> Layout.tml:
>> <html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd">
>> <h1>Here's the Layout Beginning</h1>
>> <t:body/>
>> <h2>Here's the layout End</h2>
>> </html>
>>
>> Page1.tml
>> <div t:type="layout" xmlns:t="
>> http://tapestry.apache.org/schema/tapestry_5_0_0.xsd">
>> Page 1 Dynamic content: ${currentTime}
>> </div>
>>
>> In Wicket:
>> Layout.html:
>> <html>
>> <wicket:border>
>> <h1>Here's the Layout Beginning</h1>
>> <wicket:body/>
>> <h2>Here's the layout End</h2>
>> </wicket:border>
>> </html>
>>
>> Page1.html:
>> <span wicket:id = "layout">
>> Page 1 Dynamic content: <span wicket:id="dynamic"/>
>> </span>
>>
>> Tapestry and Wicket were both configured to run in production mode before
>> the benchmarking. Each request went to 1 of 5 different Pages randomly
>> (each
>> page was similar to above). I used 20 Threads in parallel, each performing
>> 10,000 such requests. The client was a raw socket Java program writing the
>> HTTP GET and reading the entire response. The results are as follows:
>>
>> Tapestry 5.0.18:
>> Requests per second: 776
>> Average resp time (ms): 25.41075
>>
>> Wicket 1.3.5:
>> Requests per second: 2574
>> Average resp time (ms): 7.72404
>>
>> Wicket was the only framework that outperformed (slightly) the JSP/Servlet
>> solution. I found these results surprising, as it was my perception that
>> Tapestry would scale more easily than Wicket. Instead, I found Tapestry to
>> perform about on par with Stripes.
>>
>> Is my methodology flawed somehow? How could I improve it? Any input would
>> be
>> greatly appreciated.
>>
>> Thanks
>> Neil
>
> Christian Edward Gruber
> e-mail: christianedwardgruber@gmail.com
> weblog: http://www.geekinasuit.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by Christian Edward Gruber <ch...@gmail.com>.
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. What is the curve of performance
degredation on a single machine, a multi-core single machine, multiple
machines, etc., with geometric traffic growth.
The reason this is interesting is that sometimes one thing will
perform very quickly at one tier, but poorly at another, and something
slower will scale more gracefully.
The other methodology problem is that the simplest page merely shows
overhead, but there may be efficiencies in the handling of complex
pages, first-load, subsequent load, etc., that will be different for
the different frameworks. So actually having the simple case, then a
moderate, then heavy application which have similar fundamental
architectures (say, hibernate + database using the same persistence
strategy - heck, possibly even reusing the same DAOs, if possible).
This would give a sense whether the differences you're seeing of 25/7
turn 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.
Benchmarking is hard. ;)
cheers,
Christian.
On 11-May-09, at 13:26 , Neil Curzon wrote:
> 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 comment on my
> methodology.
>
> I have 5 simple pages that use the same simple layout, whose middle
> body
> component has a dynamic bit (the current time), to prevent any kind
> of low
> level caching. In tapestry, this looked like this:
>
> Layout.tml:
> <html xmlns:t="http://tapestry.apache.org/schema/tapestry_5_0_0.xsd">
> <h1>Here's the Layout Beginning</h1>
> <t:body/>
> <h2>Here's the layout End</h2>
> </html>
>
> Page1.tml
> <div t:type="layout" xmlns:t="
> http://tapestry.apache.org/schema/tapestry_5_0_0.xsd">
> Page 1 Dynamic content: ${currentTime}
> </div>
>
> In Wicket:
> Layout.html:
> <html>
> <wicket:border>
> <h1>Here's the Layout Beginning</h1>
> <wicket:body/>
> <h2>Here's the layout End</h2>
> </wicket:border>
> </html>
>
> Page1.html:
> <span wicket:id = "layout">
> Page 1 Dynamic content: <span wicket:id="dynamic"/>
> </span>
>
> Tapestry and Wicket were both configured to run in production mode
> before
> the benchmarking. Each request went to 1 of 5 different Pages
> randomly (each
> page was similar to above). I used 20 Threads in parallel, each
> performing
> 10,000 such requests. The client was a raw socket Java program
> writing the
> HTTP GET and reading the entire response. The results are as follows:
>
> Tapestry 5.0.18:
> Requests per second: 776
> Average resp time (ms): 25.41075
>
> Wicket 1.3.5:
> Requests per second: 2574
> Average resp time (ms): 7.72404
>
> Wicket was the only framework that outperformed (slightly) the JSP/
> Servlet
> solution. I found these results surprising, as it was my perception
> that
> Tapestry would scale more easily than Wicket. Instead, I found
> Tapestry to
> perform about on par with Stripes.
>
> Is my methodology flawed somehow? How could I improve it? Any input
> would be
> greatly appreciated.
>
> Thanks
> Neil
Christian Edward Gruber
e-mail: christianedwardgruber@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by Peter Stavrinides <P....@albourne.com>.
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" <se...@gmail.com>
To: "Tapestry users" <us...@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 <jo...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by Sergey Didenko <se...@gmail.com>.
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 <jo...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by JoelGrrrr <jo...@su3analytics.com>.
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 the
session - in memory. This can very quickly spin out of control unless you
are very careful about how you design your Wicket application. (this
"PageMap" was originally intended to make applications feel more "desktop"
like to facilitate back buttons, different versions of each page, and
different views of model data across each version of a page)
T5, on the other hand, only stores a users "working data" (e.g. user name,
products ids etc) - not an in memory copy of every page (and version of that
page and referenced pages etc...) that they have loaded with the associated
components to represent everything on the page (labels, forms... the lot) -
which is what Wicket does.
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.
(BTW: I don't mean to denigrate Wicket in any way, it is a great framework,
and just to be clear you can still build high load sites using Wicket - but
was never a feature of the framework by design from day 1, in the way that
page pooling was for T5)
Howard Lewis Ship wrote:
>
> On Tue, May 12, 2009 at 1:00 PM, Neil Curzon <ne...@gmail.com>
> 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 with the design of your application (big if?), the load
>> on
>> the other tiers should be constant. I think that the relative cost of
>> simply
>> throwing some plain HTML together, if it is indeed adding 13+ms to every
>> request, is relevant.
>>
>> But yeah, a more advanced web framework may give you the power to
>> implement
>> a more efficient solution with less development effort. There is a lot of
>> grumbling about Tapestry documentation, but Tapestry has Wicket soundly
>> beaten there.
>
> Thanks! There's lots of room for meta-programming in T5 that isn't
> present in Wicket.
>
>>
>> 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 that there are many details
>> that
>> need to be taken into account.
>>
>
> I don't follow you here; I don't see a reason why adding a HttpSession
> to the mix would affect either framework more than the other ... until
> you hit a cluster, then T5 should (in theory) have an advantage.
>
>> The problem is that I can't actually compare a real application in
>> Tapestry
>> vs Wicket without first implementing that application. And,
>> unfortunately, I
>> can only choose one framework, and must choose one first.
>>
>
> A common problem.
>
>> Neil
>>
>> On Tue, May 12, 2009 at 3:23 PM, Christian Edward Gruber <
>> christianedwardgruber@gmail.com> wrote:
>>
>>>
>>> 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, a
>>> front end can behave differently with minimal back-end activity vs. a
>>> high
>>> degree of back-end activity, simply because it may be able to work or
>>> cache
>>> work product in one scenario that isn't possible in the other, or where
>>> the
>>> margins are so tight that such effort is a higher percentage of the
>>> total
>>> work done. Real end-to-end performance on a request is subject to a lot
>>> of
>>> architectural constraints, when it comes to measuring, and you can't do
>>> a
>>> straight-line computation from a no-op case.
>>>
>>> For example, the design of T5 may be such that a page constructed with a
>>> lot of javascript from different components is handled better than with
>>> taglibs, since T5 can bundle it up, call it a versioned asset, send it
>>> as
>>> one single compressed stream, and cache it on the client. If the other
>>> framework handles the JS file-by-file, without compression, and has to
>>> re-fresh more frequently, then it's possible that T5 can vastly
>>> outperform
>>> the other in a complex application, by design.
>>>
>>> cheers,
>>> Christian Edward Gruber
>>> christianedwardgruber@gmail.com
>>> http://www.geekinasuit.com/
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
> Director of Open Source Technology at Formos
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Benchmarking-Tapestry-tp23487852p23519734.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 always ... Form's will store a bunch of
mutable client validation data in the session.
On Tue, May 12, 2009 at 1:19 PM, Neil Curzon <ne...@gmail.com> wrote:
>>
>>
>> >
>> > 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 that there are many details
>> that
>> > need to be taken into account.
>> >
>>
>> I don't follow you here; I don't see a reason why adding a HttpSession
>> to the mix would affect either framework more than the other ... until
>> you hit a cluster, then T5 should (in theory) have an advantage.
>
>
>
> I extrapolated that from this, from the front tapestry 5 page:
>
> ---
>
> Tapestry does not need to store page instances inside the HttpSession. At
> most, it stores a smattering of *persistent field values* from the page, but
> not the entire page instance. This lean use of the HttpSession is key to
> Tapestry's very high scalability, especially in a clustered configuration.
>
> In some Tapestry-like frameworks, such as Faces and Wicket, the page
> structure is more dynamic, at the cost of storing much, much more data in
> the HttpSession.
> ---
>
> I'd imagine that would have at least a slight space/time tradeoff? (no need
> to grab anything from a page pool at the cost of expensive replication).
> Maybe negligible, though..? Now that I think of in, in Wicket there's a lot
> of direct use of "new", so I probably had the wrong idea.
>
> Neil
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by Neil Curzon <ne...@gmail.com>.
>
>
> >
> > 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 that there are many details
> that
> > need to be taken into account.
> >
>
> I don't follow you here; I don't see a reason why adding a HttpSession
> to the mix would affect either framework more than the other ... until
> you hit a cluster, then T5 should (in theory) have an advantage.
I extrapolated that from this, from the front tapestry 5 page:
---
Tapestry does not need to store page instances inside the HttpSession. At
most, it stores a smattering of *persistent field values* from the page, but
not the entire page instance. This lean use of the HttpSession is key to
Tapestry's very high scalability, especially in a clustered configuration.
In some Tapestry-like frameworks, such as Faces and Wicket, the page
structure is more dynamic, at the cost of storing much, much more data in
the HttpSession.
---
I'd imagine that would have at least a slight space/time tradeoff? (no need
to grab anything from a page pool at the cost of expensive replication).
Maybe negligible, though..? Now that I think of in, in Wicket there's a lot
of direct use of "new", so I probably had the wrong idea.
Neil
Re: Benchmarking Tapestry
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Tue, May 12, 2009 at 1:00 PM, Neil Curzon <ne...@gmail.com> 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 with the design of your application (big if?), the load on
> the other tiers should be constant. I think that the relative cost of simply
> throwing some plain HTML together, if it is indeed adding 13+ms to every
> request, is relevant.
>
> But yeah, a more advanced web framework may give you the power to implement
> a more efficient solution with less development effort. There is a lot of
> grumbling about Tapestry documentation, but Tapestry has Wicket soundly
> beaten there.
Thanks! There's lots of room for meta-programming in T5 that isn't
present in Wicket.
>
> 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 that there are many details that
> need to be taken into account.
>
I don't follow you here; I don't see a reason why adding a HttpSession
to the mix would affect either framework more than the other ... until
you hit a cluster, then T5 should (in theory) have an advantage.
> The problem is that I can't actually compare a real application in Tapestry
> vs Wicket without first implementing that application. And, unfortunately, I
> can only choose one framework, and must choose one first.
>
A common problem.
> Neil
>
> On Tue, May 12, 2009 at 3:23 PM, Christian Edward Gruber <
> christianedwardgruber@gmail.com> wrote:
>
>>
>> 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, a
>> front end can behave differently with minimal back-end activity vs. a high
>> degree of back-end activity, simply because it may be able to work or cache
>> work product in one scenario that isn't possible in the other, or where the
>> margins are so tight that such effort is a higher percentage of the total
>> work done. Real end-to-end performance on a request is subject to a lot of
>> architectural constraints, when it comes to measuring, and you can't do a
>> straight-line computation from a no-op case.
>>
>> For example, the design of T5 may be such that a page constructed with a
>> lot of javascript from different components is handled better than with
>> taglibs, since T5 can bundle it up, call it a versioned asset, send it as
>> one single compressed stream, and cache it on the client. If the other
>> framework handles the JS file-by-file, without compression, and has to
>> re-fresh more frequently, then it's possible that T5 can vastly outperform
>> the other in a complex application, by design.
>>
>> cheers,
>> Christian Edward Gruber
>> christianedwardgruber@gmail.com
>> http://www.geekinasuit.com/
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by Neil Curzon <ne...@gmail.com>.
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
the other tiers should be constant. I think that the relative cost of simply
throwing some plain HTML together, if it is indeed adding 13+ms to every
request, is relevant.
But yeah, a more advanced web framework may give you the power to implement
a more efficient solution with less development effort. There is a lot of
grumbling about Tapestry documentation, but Tapestry has Wicket soundly
beaten there.
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 that there are many details that
need to be taken into account.
The problem is that I can't actually compare a real application in Tapestry
vs Wicket without first implementing that application. And, unfortunately, I
can only choose one framework, and must choose one first.
Neil
On Tue, May 12, 2009 at 3:23 PM, Christian Edward Gruber <
christianedwardgruber@gmail.com> wrote:
>
> 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, a
> front end can behave differently with minimal back-end activity vs. a high
> degree of back-end activity, simply because it may be able to work or cache
> work product in one scenario that isn't possible in the other, or where the
> margins are so tight that such effort is a higher percentage of the total
> work done. Real end-to-end performance on a request is subject to a lot of
> architectural constraints, when it comes to measuring, and you can't do a
> straight-line computation from a no-op case.
>
> For example, the design of T5 may be such that a page constructed with a
> lot of javascript from different components is handled better than with
> taglibs, since T5 can bundle it up, call it a versioned asset, send it as
> one single compressed stream, and cache it on the client. If the other
> framework handles the JS file-by-file, without compression, and has to
> re-fresh more frequently, then it's possible that T5 can vastly outperform
> the other in a complex application, by design.
>
> cheers,
> Christian Edward Gruber
> christianedwardgruber@gmail.com
> http://www.geekinasuit.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Benchmarking Tapestry
Posted by Christian Edward Gruber <ch...@gmail.com>.
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, a front end can behave differently with minimal back-
end activity vs. a high degree of back-end activity, simply because it
may be able to work or cache work product in one scenario that isn't
possible in the other, or where the margins are so tight that such
effort is a higher percentage of the total work done. Real end-to-end
performance on a request is subject to a lot of architectural
constraints, when it comes to measuring, and you can't do a straight-
line computation from a no-op case.
For example, the design of T5 may be such that a page constructed with
a lot of javascript from different components is handled better than
with taglibs, since T5 can bundle it up, call it a versioned asset,
send it as one single compressed stream, and cache it on the client.
If the other framework handles the JS file-by-file, without
compression, and has to re-fresh more frequently, then it's possible
that T5 can vastly outperform the other in a complex application, by
design.
cheers,
Christian Edward Gruber
christianedwardgruber@gmail.com
http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by Ben Gidley <be...@gidley.co.uk>.
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
ben@gidley.co.uk
On Tue, May 12, 2009 at 7:47 PM, Neil Curzon <ne...@gmail.com> wrote:
> 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 same business logic /
> persistence
> layer we'll be connecting.
>
> So I tried out Tapestry 5.1.0.5, and I'm noticing some really weird
> behavior
> that's also present in 5.0.18.
>
> I start out by benchmarking serial requests: only one thread making 100
> random requests. Tapestry is really quick here:
>
> Requests per second: 392.15686274509807
> Average resp time (ms): 2.15
>
> I can run this many times in a row, with the same approximate result. Then,
> I switch to benchmarking 10 threads each making 100 random requests:
>
> Requests per second: 456.62100456621005
> Average resp time (ms): 19.161
>
> But now, it gets weird. When I go back to one thread making 100 requests:
>
> Requests per second: 48.4027105517909
> Average resp time (ms): 19.74
>
> The numbers are very similar in 5.1 and 5.0, and the behavior is the same,
> with a spike in parallel traffic permanently damaging the single threaded
> response time. Only a server restart seemed to get back to the 2ms response
> time. When I use the same environment to try the same serial, parallel,
> serial test in wicket, there is no such problem, so I think Tapestry is the
> cause here.
>
> Setting the hard and soft limits to 40 and 50 respectively did not change
> this behavior. Google showed this be the way:
> configuration.add("tapestry.page-pool.soft-limit", "40");
> configuration.add("tapestry.page-pool.hard-limit", "50");
> .. is that correct?
>
> I'm benchmarking in jetty, and I'm not sure what the default thread pool
> size is, but on the client side, it's not more than 10, so I thought that
> 40/50 would be enough..?
>
> Neil
>
Re: Benchmarking Tapestry
Posted by Neil Curzon <ne...@gmail.com>.
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 same business logic / persistence
layer we'll be connecting.
So I tried out Tapestry 5.1.0.5, and I'm noticing some really weird behavior
that's also present in 5.0.18.
I start out by benchmarking serial requests: only one thread making 100
random requests. Tapestry is really quick here:
Requests per second: 392.15686274509807
Average resp time (ms): 2.15
I can run this many times in a row, with the same approximate result. Then,
I switch to benchmarking 10 threads each making 100 random requests:
Requests per second: 456.62100456621005
Average resp time (ms): 19.161
But now, it gets weird. When I go back to one thread making 100 requests:
Requests per second: 48.4027105517909
Average resp time (ms): 19.74
The numbers are very similar in 5.1 and 5.0, and the behavior is the same,
with a spike in parallel traffic permanently damaging the single threaded
response time. Only a server restart seemed to get back to the 2ms response
time. When I use the same environment to try the same serial, parallel,
serial test in wicket, there is no such problem, so I think Tapestry is the
cause here.
Setting the hard and soft limits to 40 and 50 respectively did not change
this behavior. Google showed this be the way:
configuration.add("tapestry.page-pool.soft-limit", "40");
configuration.add("tapestry.page-pool.hard-limit", "50");
.. is that correct?
I'm benchmarking in jetty, and I'm not sure what the default thread pool
size is, but on the client side, it's not more than 10, so I thought that
40/50 would be enough..?
Neil
Re: Benchmarking Tapestry
Posted by Sebastian Hennebrueder <us...@laliluna.de>.
There is no point in agreeing or disagreeing it basically depends on
your use case. I know applications staying 200 ms in the database layer,
in that case rendering is normally a non issue.
But if your database layer is using a cache and the data is available in
2 ms, then of course rendering plays a role.
When evaluating the frameworks in my articles, I try to setup a kind of
realistic page for a Get and Post request with and without templates and
a realistic application.
I measure both performance with a single thread and scalability with
increasing number of threads and monitor the garbage collection to
finally proper evaluate the performance.
A main problem is that the servers are pretty fast and you have to make
sure that the client nore the network is saturated. I setup the server
in a virtual machine and create load from a separated machine, both
connected with a quality GigaBit switch - no home hardware.
Getting reasonable numbers is far from simple.
I have not yet finished by Tapestry evaluation, but hopefully this
month, I will complete it.
--
Best Regards / Viele Gruesse
Sebastian Hennebrueder
---
Training for Java Persistence and Hibernate - http://www.laliluna.de
Ben Gidley schrieb:
> I do disagree :)
> For example my tests are showing tapestry work taking (even on worst cases)
> <20ms - however I can easily on production web apps get page renders in
> 300-500 ms. When you look what is happening it is all the data
> loading/preparation done outside of the web framework.
>
> My point was therefore in the real world I focus on getting that
> code efficient - as I get more bang for my buck! The key bottleneck is
> usually database access. So you tend to have to cache/optimise queries.
>
> I also tend to spend a lot of time on the YSlow (
> http://developer.yahoo.com/performance/rules.html) recommendations as these
> can make a huge difference to perceived render time. Now tapestry has
> auto-assembled javascripts that should make a substantial increase in
> percieved render time.
>
> Ben Gidley
>
> www.gidley.co.uk
> ben@gidley.co.uk
>
>
> On Tue, May 12, 2009 at 8:53 AM, Peter Stavrinides <
> P.Stavrinides@albourne.com> wrote:
>
>>> 90% of the time will be spent in your code (e.g. accessing the db) and
>> not in the framework.
>> Simply not true, Data retrieval is very fast, unless your are doing some
>> serious number crunching, more time is spent rendering (especially the DOM
>> which is notoriously slow).
>>
>> Peter
>>
>> ----- Original Message -----
>> From: "Howard Lewis Ship" <hl...@gmail.com>
>> To: "Tapestry users" <us...@tapestry.apache.org>
>> 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
>> <th...@gmail.com> wrote:
>>> Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon <ne...@gmail.com>
>>> 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
>> release, would perform better.
>>
>>>> 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 being the client and the server
>>> and the number of concurrent threads. The best scenario is having one
>>> machine as the server and N others as the clients, because you don't have
>>> threads in the same machine trying to use the same shared resource (the
>>> network stack and adapter).
>>>
>>> By the way, I have a little of benchmarking experience and all the hints
>>> given by Christian are absolutely correct.
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>> Consultor, desenvolvedor e instrutor em Java
>>> http://www.arsmachina.com.br/thiago
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>> Director of Open Source Technology at Formos
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by Massimo Lusetti <ml...@gmail.com>.
On Tue, May 12, 2009 at 10:02 AM, Ben Gidley <be...@gidley.co.uk> 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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by Ben Gidley <be...@gidley.co.uk>.
I do disagree :)
For example my tests are showing tapestry work taking (even on worst cases)
<20ms - however I can easily on production web apps get page renders in
300-500 ms. When you look what is happening it is all the data
loading/preparation done outside of the web framework.
My point was therefore in the real world I focus on getting that
code efficient - as I get more bang for my buck! The key bottleneck is
usually database access. So you tend to have to cache/optimise queries.
I also tend to spend a lot of time on the YSlow (
http://developer.yahoo.com/performance/rules.html) recommendations as these
can make a huge difference to perceived render time. Now tapestry has
auto-assembled javascripts that should make a substantial increase in
percieved render time.
Ben Gidley
www.gidley.co.uk
ben@gidley.co.uk
On Tue, May 12, 2009 at 8:53 AM, Peter Stavrinides <
P.Stavrinides@albourne.com> wrote:
> > 90% of the time will be spent in your code (e.g. accessing the db) and
> not in the framework.
> Simply not true, Data retrieval is very fast, unless your are doing some
> serious number crunching, more time is spent rendering (especially the DOM
> which is notoriously slow).
>
> Peter
>
> ----- Original Message -----
> From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Tapestry users" <us...@tapestry.apache.org>
> 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
> <th...@gmail.com> wrote:
> > Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon <ne...@gmail.com>
> > 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
> release, would perform better.
>
> >> 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 being the client and the server
> > and the number of concurrent threads. The best scenario is having one
> > machine as the server and N others as the clients, because you don't have
> > threads in the same machine trying to use the same shared resource (the
> > network stack and adapter).
> >
> > By the way, I have a little of benchmarking experience and all the hints
> > given by Christian are absolutely correct.
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Consultor, desenvolvedor e instrutor em Java
> > http://www.arsmachina.com.br/thiago
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
> Director of Open Source Technology at Formos
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Benchmarking Tapestry
Posted by Christian Edward Gruber <ch...@gmail.com>.
Um, data retrieval is usually made across a network connection, even
to the localhost, it's still likely to add up more latency than
rendering in-memory. Maybe not 99/1, but I think Howard was being a
bit hyperbolic, but in my experience, at least 2/1, and usually more
like 5/1. Otherwise, we wouldn't put so much effort into caching
strategies against persistence layers, etc.
cheers,
Christian.
On 12-May-09, at 03:53 , Peter Stavrinides wrote:
>> 90% of the time will be spent in your code (e.g. accessing the db)
>> and not in the framework.
> Simply not true, Data retrieval is very fast, unless your are doing
> some serious number crunching, more time is spent rendering
> (especially the DOM which is notoriously slow).
>
> Peter
>
> ----- Original Message -----
> From: "Howard Lewis Ship" <hl...@gmail.com>
> To: "Tapestry users" <us...@tapestry.apache.org>
> 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
> <th...@gmail.com> wrote:
>> Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon <neil.curzon@gmail.com
>> >
>> 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
> release, would perform better.
>
>>> 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 being the client and the
>> server
>> and the number of concurrent threads. The best scenario is having one
>> machine as the server and N others as the clients, because you
>> don't have
>> threads in the same machine trying to use the same shared resource
>> (the
>> network stack and adapter).
>>
>> By the way, I have a little of benchmarking experience and all the
>> hints
>> given by Christian are absolutely correct.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Consultor, desenvolvedor e instrutor em Java
>> http://www.arsmachina.com.br/thiago
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
> Director of Open Source Technology at Formos
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
Christian Edward Gruber
e-mail: christianedwardgruber@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by Peter Stavrinides <P....@albourne.com>.
> 90% of the time will be spent in your code (e.g. accessing the db) and not in the framework.
Simply not true, Data retrieval is very fast, unless your are doing some serious number crunching, more time is spent rendering (especially the DOM which is notoriously slow).
Peter
----- Original Message -----
From: "Howard Lewis Ship" <hl...@gmail.com>
To: "Tapestry users" <us...@tapestry.apache.org>
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
<th...@gmail.com> wrote:
> Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon <ne...@gmail.com>
> 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
release, would perform better.
>> 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 being the client and the server
> and the number of concurrent threads. The best scenario is having one
> machine as the server and N others as the clients, because you don't have
> threads in the same machine trying to use the same shared resource (the
> network stack and adapter).
>
> By the way, I have a little of benchmarking experience and all the hints
> given by Christian are absolutely correct.
>
> --
> Thiago H. de Paula Figueiredo
> Consultor, desenvolvedor e instrutor em Java
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Mon, May 11, 2009 at 12:10 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon <ne...@gmail.com>
> 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
release, would perform better.
>> 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 being the client and the server
> and the number of concurrent threads. The best scenario is having one
> machine as the server and N others as the clients, because you don't have
> threads in the same machine trying to use the same shared resource (the
> network stack and adapter).
>
> By the way, I have a little of benchmarking experience and all the hints
> given by Christian are absolutely correct.
>
> --
> Thiago H. de Paula Figueiredo
> Consultor, desenvolvedor e instrutor em Java
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Benchmarking Tapestry
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon <ne...@gmail.com>
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 being the client and the server
and the number of concurrent threads. The best scenario is having one
machine as the server and N others as the clients, because you don't have
threads in the same machine trying to use the same shared resource (the
network stack and adapter).
By the way, I have a little of benchmarking experience and all the hints
given by Christian are absolutely correct.
--
Thiago H. de Paula Figueiredo
Consultor, desenvolvedor e instrutor em Java
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org