https://bugzilla.wikimedia.org/show_bug.cgi?id=14404
--- Comment #29 from Roan Kattouw <roan.katt...@gmail.com> 2010-07-19 19:40:53
UTC ---
(In reply to comment #28)
> (In reply to comment #23)
> > It's not about caching, it works already pretty well (at least if exclude
> > cache
> > fragmentation), but it's about the link tables in the database which should
> > not
> > change depending on the user language.
>
> Yes but I addressed this already in the last paragraph of comment #23
> (speaking
> about "backlinks").
>
> And forcing all pages that use magic time-based keywords to use only a 1-hour
> lifetime is not the best option, when ONLY the day (or week, month, year)
> precision is used.
>
> In addition, you still don't consider when a function or template parameter
> that depends on time (or server statistics like number of pages in categories
> or namespaces) will be actually be used to generate the result.
>
> Reread what I wrote about the parameters of #if/#ifexpr/#ifeq/#switch, where
> only the first parameters and the effective conditional result is important
> for
> the cacheability of the result which could be made much longer if a
> conditional
> output parameter is not used. And this may be applied as well within the
> evaluation of #expr/#ifexpr expressions containing the "a ? b : c" ternary
> operator (only the lifetime of "a", and of EITHER "b" OR "c" should restrict
> the cache lifetime of the result):
>
> It is best to effectively track the lifetime of builtin functions and
> templates
> in order to get consistant results, but still a maximal cachability of pages
> because it can save lots of ressourcs on the servers (one hour is not enough
> in
> most cases when it could be even a full year or month, for heavily visited
> pages that are NOT modified, such as project and portal pages).
>
I'm not exactly sure how smart the mechanisms we currently have are, that is,
whether they recognize a {{CURRENTMONTH}} in a branch that isn't taken.
> - some projects will still want to accept 1-second lifetime for a few very
> active pages such as a few pages of discussions (or within very specific
> namespaces with restricted modification policies such as "mediawiki:",
> indirectly referenced by "{{int:}}" and that may also include server-wide
> notices), or pages giving status information about the server,
>
> - and some projects will even consider that some pages should **never** be
> cached and rendered gain each time it is requested, when it contains
> time-dependant or statistics-dependant information (the "mediawiki:" namespace
> is such a candidate namespace whose cachability should be tracked as precisely
> as possible, but there are a few other "special:" pages that may benefit of a
> more precise cachability).
While some projects may indeed want uncacheable or 1-second lifetime (there's
hardly a difference between these two) pages, I'm pretty sure the servers
wouldn't like that very much. At Wikimedia, we err on the side of caching over
correctness in quite a few situations.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
