Sergiu, I remember in one of my recent spring/hibernate projects we multithreaded the execution with a Taskexecutor. As a result total execution time was a little bit more than the longest thread. Don't know if this is an option here as the gain depends on various factors.
Andreas Am 06.03.2011 04:18, schrieb Sergiu Dumitriu: > On 03/06/2011 12:37 AM, Ludovic Dubost wrote: >> 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. > I think this is not the right approach. Caching always introduces > surprises. Image we cache the "recently viewed" panel. The user views > some documents, but that panel doesn't show them, but insists on > displaying things from 5 minutes ago. Buggy feature... > > Imagine we cache the homepage, and I go and create a new "product", and > go to the homepage and don't see it there. What do I do? Panic? Say it's > a bug and call the IT guy only to look like a fool later when I try to > show it? Report a bug to those developers only to have it closed as > "won't fix, duplicate of the other 30 issues reported this month"? > > Personally, I think that most of the costs come from three main points: > - checkAccess is too slow > - getXWikiPreference is too slow > - there's no way to just get some document metadata like the title > without loading the full document from the database > > We should focus on these three for a start. > > But I might be wrong as well; the best way to work on performance is to > start a profiler, find the hot spots, and tinker them until they stop > being a problem. > > Caches work well for mostly static pages, not for highly dynamic > scripts, and these scripts are the ones that cost the most. Caching > plain wiki documents will save too little. > >> 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
