You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Fernando Padilla <fe...@alum.mit.edu> on 2009/01/16 00:26:38 UTC
profiling tapestry components
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..
any ideas?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: profiling tapestry components
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 activity and look for the hot spots. And
report them back here!
The abiding rule of performance is that after careful thought and
analysis to identify where your problems are, profiling always points
you to a completely different area that is your real problem.
On Fri, Jan 16, 2009 at 11:44 AM, Fernando Padilla <fe...@alum.mit.edu> wrote:
> 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
> profiling at method level might not give me a clear picture of where to
> focus on.. ( we'll see lots of setupRenders. lots of beginRenders, but no
> relationship between one component and how it depends on subcomponents, etc
> etc)
>
> Do you understand? So it's not profiling Tapestry code precisely, but
> profiling pages/components via the view of tapestry's component rendering
> tree..
>
> I don't know if it would be ultimately useful, but it sounds like an
> interesting idea..
>
>
> Howard Lewis Ship wrote:
>>
>> 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 before it can start to stream the output; that's a
>> lot of churn in the JVM's eden heap space.
>>
>> On Thu, Jan 15, 2009 at 8:17 PM, Thiago H. de Paula Figueiredo
>> <th...@gmail.com> wrote:
>>>
>>> Em Thu, 15 Jan 2009 23:19:56 -0300, Fernando Padilla <fe...@alum.mit.edu>
>>> 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 root cause might be the number of db requests required to render a
>>>> page, but the database it self is not the bottle neck. :) :)
>>>
>>> A real case I found as a consultant was the lack of attention to
>>> Hibernate
>>> mapping options, specially regarding lazy loading of collections. Instead
>>> of
>>> using one or two selects to load an entity object and one of its lists,
>>> it
>>> was using one for each element in the list. This absolutely kills
>>> performance.
>>>
>>> By the way, nice performance improvement hunting! :) Don't forget to
>>> share
>>> your experience with us. ;)
>>>
>>> --
>>> Thiago H. de Paula Figueiredo
>>> Independent Java consultant, developer, and instructor
>>> 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
>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: profiling tapestry components
Posted by Fernando Padilla <fe...@alum.mit.edu>.
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
profiling at method level might not give me a clear picture of where to
focus on.. ( we'll see lots of setupRenders. lots of beginRenders, but
no relationship between one component and how it depends on
subcomponents, etc etc)
Do you understand? So it's not profiling Tapestry code precisely, but
profiling pages/components via the view of tapestry's component
rendering tree..
I don't know if it would be ultimately useful, but it sounds like an
interesting idea..
Howard Lewis Ship wrote:
> 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 before it can start to stream the output; that's a
> lot of churn in the JVM's eden heap space.
>
> On Thu, Jan 15, 2009 at 8:17 PM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>> Em Thu, 15 Jan 2009 23:19:56 -0300, Fernando Padilla <fe...@alum.mit.edu>
>> 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 root cause might be the number of db requests required to render a
>>> page, but the database it self is not the bottle neck. :) :)
>> A real case I found as a consultant was the lack of attention to Hibernate
>> mapping options, specially regarding lazy loading of collections. Instead of
>> using one or two selects to load an entity object and one of its lists, it
>> was using one for each element in the list. This absolutely kills
>> performance.
>>
>> By the way, nice performance improvement hunting! :) Don't forget to share
>> your experience with us. ;)
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java consultant, developer, and instructor
>> 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
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: profiling tapestry components
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 before it can start to stream the output; that's a
lot of churn in the JVM's eden heap space.
On Thu, Jan 15, 2009 at 8:17 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Em Thu, 15 Jan 2009 23:19:56 -0300, Fernando Padilla <fe...@alum.mit.edu>
> 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 root cause might be the number of db requests required to render a
>> page, but the database it self is not the bottle neck. :) :)
>
> A real case I found as a consultant was the lack of attention to Hibernate
> mapping options, specially regarding lazy loading of collections. Instead of
> using one or two selects to load an entity object and one of its lists, it
> was using one for each element in the list. This absolutely kills
> performance.
>
> By the way, nice performance improvement hunting! :) Don't forget to share
> your experience with us. ;)
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> 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 Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: profiling tapestry components
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 15 Jan 2009 23:19:56 -0300, Fernando Padilla <fe...@alum.mit.edu>
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 root cause might be the number of db requests required to render a
> page, but the database it self is not the bottle neck. :) :)
A real case I found as a consultant was the lack of attention to Hibernate
mapping options, specially regarding lazy loading of collections. Instead
of using one or two selects to load an entity object and one of its lists,
it was using one for each element in the list. This absolutely kills
performance.
By the way, nice performance improvement hunting! :) Don't forget to share
your experience with us. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
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
Re: profiling tapestry components
Posted by Fernando Padilla <fe...@alum.mit.edu>.
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 2009 20:57:19 -0300, Fernando Padilla <fe...@alum.mit.edu>
> 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 of the time, the culprit is the database
> (or any other data storage implementation). I would start by logging the
> running time of the data access methods.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: profiling tapestry components
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 15 Jan 2009 20:57:19 -0300, Fernando Padilla <fe...@alum.mit.edu>
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 of the time, the culprit is the database (or
any other data storage implementation). I would start by logging the
running time of the data access methods.
--
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
Re: profiling tapestry components
Posted by Fernando Padilla <fe...@alum.mit.edu>.
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 code and work being done, instead of at
method response times.. because there is no one method for rendering a
component or page, etc..
so, just a thought.
I guess I can tweek ComponentPageElementImpl to add extra
RenderingEvents to do this.. interesting..
Howard Lewis Ship wrote:
> 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 per component; that
> time would be very short & hard to measure.
>
> Why are you interested in component render times?
>
> On Thu, Jan 15, 2009 at 4:35 PM, Thiago H. de Paula Figueiredo
> <th...@gmail.com> wrote:
>> Em Thu, 15 Jan 2009 20:26:38 -0300, Fernando Padilla <fe...@alum.mit.edu>
>> 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 :) answer: try to find the tapestry-core service that renders
>> components and decorate it using AspectDecorator . . .
>>
>> I hope it helps . . .
>>
>> By the way, AspectDecorator is absolutely awesome.
>>
>> --
>> Thiago H. de Paula Figueiredo
>> Independent Java consultant, developer, and instructor
>> 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
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: profiling tapestry components
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 per component; that
time would be very short & hard to measure.
Why are you interested in component render times?
On Thu, Jan 15, 2009 at 4:35 PM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> Em Thu, 15 Jan 2009 20:26:38 -0300, Fernando Padilla <fe...@alum.mit.edu>
> 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 :) answer: try to find the tapestry-core service that renders
> components and decorate it using AspectDecorator . . .
>
> I hope it helps . . .
>
> By the way, AspectDecorator is absolutely awesome.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> 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 Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: profiling tapestry components
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 15 Jan 2009 20:26:38 -0300, Fernando Padilla <fe...@alum.mit.edu>
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 :) answer: try to find the tapestry-core service that
renders components and decorate it using AspectDecorator . . .
I hope it helps . . .
By the way, AspectDecorator is absolutely awesome.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
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