Re: Tracking performance issues on requests best practices
Well I've switched on to AspectJ load time weaving and was able to intercept calls on also the wicket Components methods. I've tested locally to see where are the missing numbers. Seemed not much time was spent in onInitialize() afterall, the cause by the fact that even if the Services layer was intercepted, I did not think of the OpenEntityManagerInViewFilter which caused DB hits that were not going through the Service layer and thus not counted. 2. I was counting also the first hit of the first page which meant getMarkup calls for the components. That markup is then cached on subsequent calls but when called it does take it's toll. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Tracking-performance-issues-on-requests-best-practices-tp4657676p4657706.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
Tracking performance issues on requests best practices
Hello guys, I'm trying to have a finer look at what is taking time on the serverside in our application. What I have so far is that I'm using Spring AOP to track down calls to all the methods and time to the Services layer. PS: I'm using JETM http://jetm.void.fm/ (it may be old, but is simple and give pretty much what you need). 2. I've collected the time for the whole request to process in a AbstractRequestCycleListener onBeginRequest, onEndRequest so as to see a sum of the total time spent on a particular usecase. What I've expected to find is that most of the resulting time would be spent in the services layer and pretty much summed up to be near the request time on the requestcyclelistener. Practical data shows however otherwise, with the sum of the service time not even close to the total of the request time. 3. So I've fine tuned the result to also show the rendering time for the components taking as example RenderPerformanceListener which measure the time between component onBeforeRender and onAfterRender. It's pretty nice to see in jetm hierarchycal component-services call, however it still not nearly close to the whole request time. I'm still looking and seeing that there is some logic also on some component's constructors and also onInitialize() methods that I see no easy way to measure them. IComponentInitializationListener seems to only trigger after initialization, I see no easy way to mark the start time of the onInitialize() and collect the time in the listener. So I'm asking if anyone got an idea, or I'm interested what you guys usually do to track down any performance issues in the app. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Tracking-performance-issues-on-requests-best-practices-tp4657676.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: Tracking performance issues on requests best practices
We use New Relic extensively, which allows us to (a) annotate key parts of the app we wish to monitor, and (b) allow profiling in production, if we ever need it. I'm not affiliated with New Relic, just a happy user of it. Please note that it's not a free tool, but given the ease of use (it's very easy to set up) I've never looked back. In case you want a free solution: run your app through a profiler to see where most time per request is spent. Met vriendelijke groet, Kind regards, Bas Gooren Op 1-4-2013 21:45, schreef Serban.Balamaci: Hello guys, I'm trying to have a finer look at what is taking time on the serverside in our application. What I have so far is that I'm using Spring AOP to track down calls to all the methods and time to the Services layer. PS: I'm using JETM http://jetm.void.fm/ (it may be old, but is simple and give pretty much what you need). 2. I've collected the time for the whole request to process in a AbstractRequestCycleListener onBeginRequest, onEndRequest so as to see a sum of the total time spent on a particular usecase. What I've expected to find is that most of the resulting time would be spent in the services layer and pretty much summed up to be near the request time on the requestcyclelistener. Practical data shows however otherwise, with the sum of the service time not even close to the total of the request time. 3. So I've fine tuned the result to also show the rendering time for the components taking as example RenderPerformanceListener which measure the time between component onBeforeRender and onAfterRender. It's pretty nice to see in jetm hierarchycal component-services call, however it still not nearly close to the whole request time. I'm still looking and seeing that there is some logic also on some component's constructors and also onInitialize() methods that I see no easy way to measure them. IComponentInitializationListener seems to only trigger after initialization, I see no easy way to mark the start time of the onInitialize() and collect the time in the listener. So I'm asking if anyone got an idea, or I'm interested what you guys usually do to track down any performance issues in the app. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Tracking-performance-issues-on-requests-best-practices-tp4657676.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: Tracking performance issues on requests best practices
We use JProfiler, but Ive also used Yourkit (both very good profilers). N On Mon, Apr 1, 2013 at 3:45 PM, Serban.Balamaci thespamtr...@gmail.comwrote: Hello guys, I'm trying to have a finer look at what is taking time on the serverside in our application. What I have so far is that I'm using Spring AOP to track down calls to all the methods and time to the Services layer. PS: I'm using JETM http://jetm.void.fm/ (it may be old, but is simple and give pretty much what you need). 2. I've collected the time for the whole request to process in a AbstractRequestCycleListener onBeginRequest, onEndRequest so as to see a sum of the total time spent on a particular usecase. What I've expected to find is that most of the resulting time would be spent in the services layer and pretty much summed up to be near the request time on the requestcyclelistener. Practical data shows however otherwise, with the sum of the service time not even close to the total of the request time. 3. So I've fine tuned the result to also show the rendering time for the components taking as example RenderPerformanceListener which measure the time between component onBeforeRender and onAfterRender. It's pretty nice to see in jetm hierarchycal component-services call, however it still not nearly close to the whole request time. I'm still looking and seeing that there is some logic also on some component's constructors and also onInitialize() methods that I see no easy way to measure them. IComponentInitializationListener seems to only trigger after initialization, I see no easy way to mark the start time of the onInitialize() and collect the time in the listener. So I'm asking if anyone got an idea, or I'm interested what you guys usually do to track down any performance issues in the app. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Tracking-performance-issues-on-requests-best-practices-tp4657676.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
