Marius, I like the plan you sketch below but I feel it is very important that the performance profiling procedure you are following is applicable beyond the simple XWiki default distribution.
It sounds possible but, I think, it requires a thorough documentation and probably be based solely on open-source tools, or at least widely available ones. I thought HPjprof has already an amount of (static) profiling available as opposed to yourkit. Also it requires configurable "input", e.g. a typical list of steps as could be recorded... paul Le 4 avr. 2011 à 14:28, Marius Dumitru Florea a écrit : > Hi Ludovic, > > On 03/05/2011 11:14 AM, Ludovic Dubost wrote: >> >> Hi, >> >> He is a first draft of the investigation for "page load time" with a >> proposed action plan: >> >> http://dev.xwiki.org/xwiki/bin/view/Design/PageLoadTime >> >> My next step will be to run a "manual" test and take some measures and >> propose "obvious" improvements we could make if there are any. >> >> Comments welcome. Questions are: >> >> - are the goals ok >> - are the measures the right ones >> - can we run automated measures >> - what is missing in this document > > Are we targeting only the page loading time? IMO we should have a wider > plan that includes network throughput and resource usage. We don't have > to handle all of them in the 3.1 time frame but we should have them in > mind for later. Also, the current plan doesn't make a clear distinction > between the client and server side performance issues. I felt the need > to organize things a bit and I wrote > http://incubator.myxwiki.org/xwiki/bin/view/Drafts/XWikiPerformanceEvaluation > . Now I'm not sure how to integrate it with the current plan. As stated > there IMO is very important to start with writing automated performance > tests. Like with any other tests it's best to have them before we fix > the performance issues. I'd like to follow this steps: > > (1) Spend 6-7 days to implement automated tests for server response time > using JMeter. > > (2) Spend a few days to implement automated tests for browser render > time (I haven't found a tool yet. Suggestions are welcome). > > (3) Spend a week to profile the server side code using YourKit. The goal > is to find the hot spots both at the Velocity level and at the Java > level. At the end of these days I'll send a mail with a list of > improvements to the server response time. > > (4) Spend a couple of days to investigate the browser render time. This > includes: > * analyze reports made by browser addons like PageSpeed or YSlow and > reports made by online tools > * profile the JavaScript code using Firebug. > > At the end of this stage we should discuss the road map for the response > time improvements. As for the network throughput and resource usage we > first need to assess their importance. Server response size and > memory/CPU usage can be measured using JMeter too, so I could write > tests for them while writing tests for server response time. Asserting > the number of requests made by the browser and the amount of CPU/memory > needed on the client is a bit harder though. > > WDYT? > > Thanks, > Marius > >> >> Ludovic >> >> >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
