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
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs



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

<<attachment: ludovic.vcf>>

_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to