Re: [xwiki-devs] Investigation: Page Load Time

Le 06/03/11 04:18, Sergiu Dumitriu a écrit : Of course caching needs to be use with intelligence and should be used only on content that you can invalidate the cache for. But the numbers shown higher up, show that a significant portion of the load time is actually in certain scripts (panels or home page) that are costly by nature and quite almost the same from one run to another. It's not something that is problematic by essence but this is something an administrator needs to be aware of. It's known that an entry point should be fast. For instance Google does not use a dynamic page for it's search box. Having a cost of 2 seconds to display the boxes from our home page is a killer. Another thing that it shows is that indeed there is a lot of time in many little things. 37 templates, thousands of calls to the prefs and to the message API (you forgot that one). That's not always true. I've run profilers on XWiki and profilers are good to look at contentions and specific code that is called a lot under load. It does not tell you if your code is necessary or not. A good instrumentation of the "logic" of your page is interesting too. In my view all performance information is interesting as it allows to gain information about our application. What is really important is to separate the use case. There is no point in profiling the home page of XWiki since it's load time is probably not XWiki core apis time, but it's the logic that is used in the home page itself. So it's important to know exactly what you profile. Either: 1/ You profile a scenario to find out which pages should be improved   version A: no load   version B: with load 2/ You profile your skin alone 3/ You try to profile the core with and without load (but that last one is complicated because there are many ways to use the core). In my view, "load testing" is not even what we are looking at now. It's something different to look at load, CPU and memory consumption than looking at raw speed of pages. On this aspect I noticed during load testing that XWikiDocument cloning is called too much (on getObject() and therefore by livetables) and has increased in cost with component reference injection in BaseProperty. We can probably measure that an XWikiPreference cloning is quite expensive. Now I agree that checkAccess is interesting (in my tests I'm Admin so we bypass most of the code there). getXWikiPreference is probably not that slow, but is called too much. I would look at the message api too, and the skin finding code. In general I would think about all the stuff that is actually NOT changing once you got out of development mode. XWiki is very powerfull and everything is very dynamic. However once you have put your wiki in production, you don't necessarly need this dynamicity and you are paying the code of it. Maybe we could have an option which says "production mode" in the admin which activates long term caches for everything that is configurable in the Wiki: - skin - prefs - translations What I mean by long term caches, is not even looking at if this data has changed. Doing this won't reduce a page load from 4 seconds to 0.5 seconds because when you are at 4 seconds it usually means there is logic that needs to work with more data, but it will more reduce the currently incompressible part from something like 200ms to 100ms or even 50ms, and therefore would have a lot of effect on the footprint of the web server. It won't fix the time of loading of JS and CSS which is quite significant too. Now the big question is what to focus on in priority. That's one the objectives of the investigation process. See what makes more sense to focus on. I'll try to list all the areas that can be looked at. Clearly the current document puts a bit to core part aside. Ludovic _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs