[xwiki-devs] Investigation: Page Load Time

Ludovic Dubost ludovic at xwiki.com
Mon Mar 7 08:53:29 UTC 2011

Le 06/03/11 22:08, Paul Libbrecht a écrit :
> Sergiu,
> Sure, caching can be dangerous and can and should be invalidatable.
> That's the reason the browsers generally do not rely only on their cache but rely on "validating their cache" doing a call with the addition of "If-Modified-Since". What allows them to keep their cached result is the response "Not Modified". A very good explanation is that of Mark Nottingham http://www.mnot.net/cache_docs/
> Where this is a major performance gainer is that it's not only the html (or js, jpeg, or png) stream that is cached but all the analysis based on that (for example the computation of styles, the js compilation, or the jpeg profile adjustments, provided they also don't change).
> I disagree with Ludovic that says that it almost always changes: for a given browser it does mostly not when you do back for example.
I think what I'm saying is that we cannot do "cross-user" caching as the 
result of each template is almost always personalized.
Of course we could have a per-user cache but I'm not sure it would be 
very memory efficient.
> I agree with Sergiu that application developers should not have cache hold their updates and probably should only enable a cache when they are aware of it but currently, they can only invalidate the xwiki cache by saving again the given page. That sure is too limited!
> Ludovic, your "usage statistics of macros" is a tool lots of people would put to good use. If you could publish that, it could be put to good use.

This was just a simple hack:

#macro(template $tname)
#set($time1 = $xwiki.date.time)
#set($time2 = $xwiki.date.time)
#set($dtime1 = $time2 - $time1)
Time $tname: $dtime1

Now it will only work with 3.0 because it needs velocity 1.7 which has a 
stack for variables.
With older versions I think the variables will overwrite themselves on 
recursive calls.

We could put this in the core in parseTemplate with an option.
We also have the old monitor plugin which implements a strategy for that 
type of stuff.
Since it's a plugin we could expose it in velocity:


At the time I used this plugin a lot to verify that storage was behaving 
as I wanted.


> paul
> Le 6 mars 2011 à 10:41, Ludovic Dubost a écrit :
>>>> 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"?
>> 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).
> _______________________________________________
> 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/20110307/09e0f687/attachment-0002.vcf>

More information about the devs mailing list