[xwiki-devs] Investigation: Page Load Time
paul at hoplahup.net
Sun Mar 6 21:08:54 UTC 2011
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 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.
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).
More information about the devs