4 Apr
2011
4 Apr
'11
2:51 p.m.
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/XWikiPerformanceEvaluati…
. 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs