Tapestry so aggressively intermixes framework code and user code that
it's going to be hard to pick it out. Futher, Tapestry's queue based
(rather than tail recursive) approach makes it much harder to see
what's going on. I would still advise you to use YourKit to measure
across a long period of
I'm using 5.1.0.0.
But I'm sorry to confuse you all. I'm not trying to profile Tapestry
lowlevel code, I'm trying to profile my own component code :)
I want to know collectively how long any one of my component takes to
render. The reason I think this view of things would be useful, is that
Are you using Tapestry 5.0.18 or 5.1.0.0-SNAPSHOT? I've added some
considerable performance improvements to 5.1.
I would get a copy of YourKit and start profiling to see where the
actual problems are.
Tapestry takes a hit because it renders the entire document to a kind
of light-weight DOM befor
Em Thu, 15 Jan 2009 23:19:56 -0300, Fernando Padilla
escreveu:
The database was just upgraded and io/cpu is really really low. So that
won't be the case.
I would still check this out . . . Don't forget about one transaction
waiting for others to release locks in table rows . . .
The r
I know that. :)
The database was just upgraded and io/cpu is really really low. So that
won't be the case. The root cause might be the number of db requests
required to render a page, but the database it self is not the bottle
neck. :) :)
Thiago H. de Paula Figueiredo wrote:
Em Thu, 15 Jan
Em Thu, 15 Jan 2009 20:57:19 -0300, Fernando Padilla
escreveu:
Well, we have a large app that is not performing very well.. and now I
have to figure out how to make it more performant..
In my humble opinion, you're starting to performance bottleneck from the
wrong side of the stack. Most
Well, we have a large app that is not performing very well.. and now I
have to figure out how to make it more performant..
And I was just wondering if dumping component level response times,
could maybe give me some sort of clue as to what to focus on.. It's a
slightly different view of the c
Acutally, check the logging documentation; there's already a service
that times how long the render takes and how many render operations
were involved. Much of the performance improvements in 5.1 was reduce
the number of operations per component.
There isn't a good way to get output about time pe
Em Thu, 15 Jan 2009 20:26:38 -0300, Fernando Padilla
escreveu:
I was wondering if I could create some sort of profiler, that would
print out the render time for each component..
that way I can use that information to try to pinpoint components that
need to be optimized..
Quick and lazy :
