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
b...@gidley.co.uk
On Tue, May 12, 2009 at 8:53 AM, Peter Stavrinides <
p.stavrini...@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" <hls...@gmail.com>
To: "Tapestry users" <users@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
<thiag...@gmail.com> wrote:
Em Mon, 11 May 2009 14:26:16 -0300, Neil Curzon <neil.cur...@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
Director of Open Source Technology at Formos
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
