https://bugzilla.wikimedia.org/show_bug.cgi?id=14404
--- Comment #28 from Philippe Verdy <[email protected]> 2010-07-19 17:03:58 UTC --- (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). The choice of one hour seems quite arbitrary (even if it's good only as a PROJECT-SPECIFIC policy for the minimum lifetime to consider for the final rendered page). - 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). -- 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
