Last modified: 2014-11-17 10:36:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T13685, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 11685 - Automate cache expiration for pages using DynamicPageList
Automate cache expiration for pages using DynamicPageList
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
DynamicPageList (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 32336 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-16 17:18 UTC by Brion Vibber
Modified: 2014-11-17 10:36 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brion Vibber 2007-10-16 17:18:43 UTC
In theory it should be possible to have pages using the DynamicPageList expire from cache after some predetermined age, which would reduce the need for manual purges (eg, as noted at bug 11617) while still letting pages be cached fairly sanely against heavy load.

A couple parts should be 'easy':

1) Cache-Control headers -- the s-maxage could be reduced, allowing the page to expire from Squids.

2) ParserCache entry could have an expiration time added to it, letting the system re-render.

I'm not entirely sure though how best to handle If-Modified-Since checks (from user agents or proxy caches). The page_touched timestamp wouldn't have changed, so the system as currently set up would come back with a 304 response from the page metadata long before reaching the parser cache.

It might be necessary to add a page_expiry field or something... or some kind of equivalent check hacked in as a hook.


Note that other extensions could use a similar mechanism.
Comment 1 Siebrand Mazeland 2010-02-15 10:15:17 UTC
Assign open DynamicPageList issues to new component maintainer.
Comment 2 Bawolff (Brian Wolff) 2011-11-10 17:34:05 UTC
*** Bug 32336 has been marked as a duplicate of this bug. ***
Comment 3 Dario Taraborelli 2011-11-10 18:23:45 UTC
Any solution that will save me from doing a manual ?action=purge on every single
page where DPL is used would be really useful. The third-party DPL seems to
have a specific config entry for the parser cache, I am not sure if this is of any use:
http://www.mediawiki.org/wiki/Extension:DynamicPageList_(third-
Comment 4 Bawolff (Brian Wolff) 2011-11-10 18:39:15 UTC
>The third-party DPL seems to
>have a specific config entry for the parser cache, I am not sure if this is of
>any use:
>http://www.mediawiki.org/wiki/Extension:DynamicPageList_(third-

The third party dpl basically disables cache totally, which is not an option... (And then tries to re-invent its own cache, which is isn't that great an idea)

However, we could shorten the parser cache length with a call to $parser->getOutput()->updateCacheExpiry( foo );. I'm not sure what an appropriate value of foo would be (72 hours maybe?) [this was recently suggested by Aaron I'm told]


In long term, we could possibly record which page has dpls involving which categories in a table somewhere, and then invalidate pages when someone adds/removes things from that category.
Comment 5 Bawolff (Brian Wolff) 2011-11-16 21:03:56 UTC
Added default 24 hour cache expire time (configurable via $wgDLPMaxCacheTime) in r103382.

Leaving bug open, as I think in longer term we could do better then just early expiring the cache.
Comment 6 Dario Taraborelli 2011-11-16 21:37:37 UTC
Awesome, thanks. Do I need to file a separate bug to request a config change on Meta or can this be handled as part of this ticket?
Comment 7 Bawolff (Brian Wolff) 2011-11-17 00:24:41 UTC
(In reply to comment #6)
> Awesome, thanks. Do I need to file a separate bug to request a config change on
> Meta or can this be handled as part of this ticket?

I'll tag the revision as 1.18wmf1 which will cause it to be deployed a whole lot sooner. (As a work around, putting something like {{CURRENTHOUR}} on a wiki page will cause cache to expire much faster for that page).
Comment 8 Andre Klapper 2013-04-15 10:56:48 UTC
Lowering priority as per comment 5 (had been "high" for ~18months)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links