You mentioned this, which threw me off: >The key bottleneck is usually database access. So you tend to have to >cache/optimise queries.
So I assumed you were referring to data as purely 'data' from a database. Peter ----- Original Message ----- From: "Peter Stavrinides" <p.stavrini...@albourne.com> To: "Tapestry users" <users@tapestry.apache.org> 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 latency than > rendering in-memory. Apologies Ben, now I understand what you meant, you are inferring data to be = resource retrieval (all assets etc.) with page and DOM rendering... I don't dispute that. Kind regards, Peter 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. -- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. ----- Original Message ----- From: "Christian Edward Gruber" <christianedwardgru...@gmail.com> To: "Tapestry users" <users@tapestry.apache.org> 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 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" <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 > Christian Edward Gruber e-mail: christianedwardgru...@gmail.com weblog: http://www.geekinasuit.com/ --------------------------------------------------------------------- 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
