[xwiki-devs] Investigation: Page Load Time

Ludovic Dubost ludovic at xwiki.com
Sat Mar 5 23:37:41 UTC 2011


Interesting I did some simple instrumentation of #template and for the 
page Sandbox.WebHome we get:

(results here 
http://dev.xwiki.org/xwiki/bin/view/Design/PageLoadTimeReport30SnapShot1)

Time frequentlyUsedDocs.vm: 3
Time deprecatedVars.vm: 1
Time xwikivars.vm: 11
Time layoutExtraVars.vm: 1
Time layoutvars.vm: 7
Time colorThemeInit.vm: 2
Time stylesheets.vm: 5
Time analytics.vm: 0
Time javascript.vm: 9
Time htmlheader.vm: 36
Time menuview.vm: 19
Time global.vm: 3
Time header.vm: 4
Time startpage.vm: 78
Time contentmenu.vm: 6
Time frequentlyUsedDocs.vm: 1
Time deprecatedVars.vm: 1
Time xwikivars.vm: 7
Time hierarchy.vm: 25
Time titlevars.vm: 2
Time shortcuts.vm: 2
Time contentview.vm: 37
Time frequentlyUsedDocs.vm: 1
Time deprecatedVars.vm: 1
Time xwikivars.vm: 7
Time documentTags.vm: 12
Time frequentlyUsedDocs.vm: 1
Time deprecatedVars.vm: 1
Time xwikivars.vm: 9
Time commentsinline.vm: 12
Time docextra.vm: 15
Time leftpanels.vm: 1
Time rightpanels.vm: 50
Time footer.vm: 2
Time htmlfooter.vm: 0
Time endpage.vm: 54
Time view.vm: 216

in Firebug the page loads in 10ms more than view.vm
As we can see:

- the panels (quick links and recent changes) cost 50ms -> 25%
- startpage cost 78ms -> 30%
- breadcrumb cost 25ms -> 12%
- some templates are repeated (on repeat is dur to AJAX, the other not)
- we have 37 templates called

If we implement caching in panels, breadcrumb and part of the start page 
we could win 33% of the general time of the skin.
If we win 1ms per template run, we can win 15% of the general time of 
the skin.

The results on the home page (2 to 3 seconds), show that we ought to 
look at dynamic code of course as the main slow-down. A panel with a 
list of changes or of categories is way more costly than the whole skin. 
The dashboard page is even more costly.
A long Syntax 2.0 page is also quite costly.

So implementing caches on all this is a good way to keep performance good.

Ludovic





Le 05/03/11 23:56, Ludovic Dubost a écrit :
>
> Good points Paul,
>
> While I was working on a first report ( 
> http://dev.xwiki.org/xwiki/bin/view/Design/PageLoadTimeReport30SnapShot1 
> ), I also realized that I did not mention velocity enough here.
> I do have caches in mind to improve performance (we have the cache 
> macro in the 3.0 trunk and in the 2.7 branch), but it's true I did not 
> mention it.
>
> One reason is that a lot of the velocity time is not in the page 
> itself but in the main templates, and it does not seem so easy to 
> cache that part, since almost all templates have context specific 
> results (based on the user).
> However maybe we ought to look into that more and maybe reorganize the 
> templates between those that are always giving a stable results and 
> those that don't. I was thinking that some templates could report that 
> they can be cached. It's probably true for pages too which could be 
> reported by their editors as fully cachable.
>
> In any case, what's sure is that we do need a good analysis of the 
> time spent in velocity and in the templates and the load it generates 
> on the server. In the end we do suffer from rerunning the same 
> velocity over and over again, even though it will always give the same 
> result.
>
> It's true also that it would make sense to provide tools to measure 
> the performance of the application that is built with XWiki, not only 
> the base product.
>
> I'll wait for more feedback and we'll improve the plan.
>
> Ludovic
>
>
> Le 05/03/11 22:02, Paul Libbrecht a écrit :
>> Ludovic,
>>
>> First, one of the central performance gainers on the web is the usage 
>> of Caches.
>> I see nothing of that mentioned there and it should definitely be 
>> mentioned I feel.
>>
>> Providing a system where velocity macros and pages can return that 
>> they have not been modified since the given time (that the browser 
>> indicates) would make probably more than 50% of the xwiki-loaded 
>> pages be instantaneously displayed.
>>
>> This sure should be measured. It'd be a comparison between what would 
>> happen if such a clean if-modified-since treatment would exist and 
>> what is actually done.
>>
>> Secondly, another area where I think page-delivery time is too often 
>> eaten in xwiki is at the lack of streaming. Thus far I can only 
>> stream by outputting more velocity. I can't stream from a groovy page 
>> that is called and, I fear, quite often velocity still calls toString 
>> methods instead of streaming, say, a property value.
>>
>> Again, it would be interesting to analyze this statistically. My 
>> claim here, would be that this would lower the memory allocation 
>> considerably hence the time taken to process.
>>
>> Thirdly, removing unused JS and CSS is, to me, only one step and it 
>> is highly desirable to have (integrated) tools that measure the 
>> overlap of various CSS sources. The complexity of the CSS is one of 
>> the places where Curriki is probably at its biggest difficulty.
>>
>>
>> Finally, the measures you indicate in this page (and also those that 
>> I recommend) seem to be strongly application specific. It would be 
>> rather nice to have re-runnable tests so that one can draw possibly 
>> different test conclusions as part of an admin toolkit.
>> As a result, the objective of dividing by 2 seems quite artificial to 
>> me, though certainly enjoyable; it should be there for each 
>> application to apply.
>>
>> paul
>>
>>
>> Le 5 mars 2011 à 10:14, Ludovic Dubost a écrit :
>>
>>> 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
>>>
>>> Ludovic
>>>
>>> -- 
>>> Ludovic Dubost
>>> Blog: http://blog.ludovic.org/
>>> XWiki: http://www.xwiki.com
>>> Skype: ldubost GTalk: ldubost
>>>
>>> <ludovic.vcf>_______________________________________________
>>> devs mailing list
>>> devs at xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>> _______________________________________________
>> devs mailing list
>> devs at xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> _______________________________________________
> devs mailing list
> devs at xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs


-- 
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ludovic.vcf
Type: text/x-vcard
Size: 304 bytes
Desc: not available
URL: <http://lists.xwiki.org/pipermail/devs/attachments/20110306/20eb9f5e/attachment-0002.vcf>


More information about the devs mailing list