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 > >
