RE: Wicket 'hook' point for page render timing
I've added the RenderPerformanceListener but where is the output? Where can we retrieve the performance stats? -Original Message- From: robert.mcguinness [mailto:robert.mcguinness@gmail.com] Sent: Sunday, 12 February 2012 2:22 AM To: users@wicket.apache.org Subject: Re: Wicket 'hook' point for page render timing Chris, Have you looked into RenderPerformanceListener.java? added by getComponentInstantiationListeners().add(new RenderPerformanceListener()); -- View this message in context: http://apache- wicket.1842946.n4.nabble.com/Wicket-hook-point-for-page-render-timing- tp4378230p4379127.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket 'hook' point for page render timing
log level must be set to debug for org.apache.wicket.devutils.inspector.RenderPerformanceListener. ex. output: 19:14:10.563 DEBUG o.a.w.d.i.RenderPerformanceListener - rendered 'HomePage page' for 207ms i'm not sure if this is what you needed but maybe you can use as a guide. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-hook-point-for-page-render-timing-tp4378230p4382458.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wicket 'hook' point for page render timing
-Original Message- From: robmcguinness [mailto:robert.mcguinness@gmail.com] Sent: Monday, 13 February 2012 11:17 AM log level must be set to debug for org.apache.wicket.devutils.inspector.RenderPerformanceListener. ex. output: 19:14:10.563 DEBUG o.a.w.d.i.RenderPerformanceListener - rendered 'HomePage page' for 207ms That RenderPerformanceListener works really well! Awesome - it's exactly what I was looking for. I didn't know that existed in Wicket. I was thinking I was going to have to 'roll my own'. Within seconds I could tell that something I thought was a bottle neck isn't at all! Regards, Chris i'm not sure if this is what you needed but maybe you can use as a guide. -- View this message in context: http://apache- wicket.1842946.n4.nabble.com/Wicket-hook-point-for-page-render-timing- tp4378230p4382458.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 'hook' point for page render timing
FYI: I'd skip the part where you build something manually, and simply use new relic's RPM tool for a month to dig into your app's performance. They give you a breakdown of slow requests so you can see how much time is spent in database calls, and even which sql queries are run. Op 11-2-2012 6:26, schreef Chris Colman: The reason I wanted to hook it into Wicket was to take advantage of Wicket resolving the page class using its ability to resolve pages via it's mounting mechanism. If I do it in a separate servlet filter and therefore deal with raw URLs then I think (but could be wrong) I have to re-implement some portion of the 'URL to mounted page class' mechanism. Being lazy or having no spare time, yeah, let's go with no spare time :) I was trying to avoid writing/duplicating the page class resolution part. But your filter idea is a good one if my 're-use' idea doesn't fly. It's nice and pluggable/removable too. Regards, Chris -Original Message- From: Nick Heudecker [mailto:nheudec...@gmail.com] Sent: Saturday, 11 February 2012 2:11 PM To: users@wicket.apache.org Subject: Re: Wicket 'hook' point for page render timing I did this with a simple servlet filter, then profiled individual service calls within the slower pages. On Fri, Feb 10, 2012 at 7:03 PM, Chris Colman chr...@stepaheadsoftware.comwrote: ** ** I'm interested in measuring the time taken to render each individual page class and building up some stats to see if any are doing too much in the database and could benefit from data caching. ** ** Wicket seems to be customizable at many levels and so I was wondering if there is a hook point/plugin point for a listener style interface that gets called immediately after the mount path resolution has taken place (but before page class construction) and then again after the page rendering has completed. ** ** In the measurement I want to include: - the time it takes to construct the page class (with parameters) as not all of my constructors have been migrated to onInitialize() and so some constructors are performing database lookups. - the time it takes to perform the render after page class construction has completed. If I can hook into these points with a page create/render listener (or something like that) then I can write a simple timer that tracks how long each page takes to render. ** ** Yours sincerely, ** ** Chris Colman Pagebloom Team Leader, Step Ahead Software pagebloom - your business your website growing together ** ** **Sydney**: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 Email: chr...@stepahead.com.au//chr...@stepahead.com.au Website: http://www.pagebloom.com http://develop.stepaheadsoftware.com ** ** - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 'hook' point for page render timing
Chris, Have you looked into RenderPerformanceListener.java? added by getComponentInstantiationListeners().add(new RenderPerformanceListener()); -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-hook-point-for-page-render-timing-tp4378230p4379127.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 'hook' point for page render timing
I did this with a simple servlet filter, then profiled individual service calls within the slower pages. On Fri, Feb 10, 2012 at 7:03 PM, Chris Colman chr...@stepaheadsoftware.comwrote: ** ** I’m interested in measuring the time taken to render each individual page class and building up some stats to see if any are doing too much in the database and could benefit from data caching. ** ** Wicket seems to be customizable at many levels and so I was wondering if there is a hook point/plugin point for a listener style interface that gets called immediately after the mount path resolution has taken place (but before page class construction) and then again after the page rendering has completed. ** ** In the measurement I want to include: - the time it takes to construct the page class (with parameters) as not all of my constructors have been migrated to onInitialize() and so some constructors are performing database lookups. - the time it takes to perform the render after page class construction has completed. If I can hook into these points with a page create/render listener (or something like that) then I can write a simple timer that tracks how long each page takes to render. ** ** Yours sincerely, ** ** Chris Colman Pagebloom Team Leader, Step Ahead Software pagebloom - your business your website growing together ** ** **Sydney**: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 Email: chr...@stepahead.com.au //chr...@stepahead.com.au Website: http://www.pagebloom.com http://develop.stepaheadsoftware.com ** **
RE: Wicket 'hook' point for page render timing
The reason I wanted to hook it into Wicket was to take advantage of Wicket resolving the page class using its ability to resolve pages via it's mounting mechanism. If I do it in a separate servlet filter and therefore deal with raw URLs then I think (but could be wrong) I have to re-implement some portion of the 'URL to mounted page class' mechanism. Being lazy or having no spare time, yeah, let's go with no spare time :) I was trying to avoid writing/duplicating the page class resolution part. But your filter idea is a good one if my 're-use' idea doesn't fly. It's nice and pluggable/removable too. Regards, Chris -Original Message- From: Nick Heudecker [mailto:nheudec...@gmail.com] Sent: Saturday, 11 February 2012 2:11 PM To: users@wicket.apache.org Subject: Re: Wicket 'hook' point for page render timing I did this with a simple servlet filter, then profiled individual service calls within the slower pages. On Fri, Feb 10, 2012 at 7:03 PM, Chris Colman chr...@stepaheadsoftware.comwrote: ** ** I'm interested in measuring the time taken to render each individual page class and building up some stats to see if any are doing too much in the database and could benefit from data caching. ** ** Wicket seems to be customizable at many levels and so I was wondering if there is a hook point/plugin point for a listener style interface that gets called immediately after the mount path resolution has taken place (but before page class construction) and then again after the page rendering has completed. ** ** In the measurement I want to include: - the time it takes to construct the page class (with parameters) as not all of my constructors have been migrated to onInitialize() and so some constructors are performing database lookups. - the time it takes to perform the render after page class construction has completed. If I can hook into these points with a page create/render listener (or something like that) then I can write a simple timer that tracks how long each page takes to render. ** ** Yours sincerely, ** ** Chris Colman Pagebloom Team Leader, Step Ahead Software pagebloom - your business your website growing together ** ** **Sydney**: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 Email: chr...@stepahead.com.au //chr...@stepahead.com.au Website: http://www.pagebloom.com http://develop.stepaheadsoftware.com ** ** - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
