Re: profiling tapestry components
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 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 >> wrote: >>> >>> 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 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-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 > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: profiling tapestry components
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 wrote: 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 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-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
Re: profiling tapestry components
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 wrote: > 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 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-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: profiling tapestry components
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 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: profiling tapestry components
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 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: profiling tapestry components
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 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: profiling tapestry components
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 wrote: 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 :) 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-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
Re: profiling tapestry components
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 wrote: > 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 :) 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-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: profiling tapestry components
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 :) 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org