Page MenuHomePhabricator

MediaWiki should support partial page caching (edge side includes)
Closed, DeclinedPublic

Description

Both Squid and Varnish support edge side includes, but support needs to be added to MediaWiki in order for us to take advantage of this. If implemented, MediaWiki could send out sections of a page like so:

<esi:include src="http://en.wikipedia.org/wiki/Special:CentralNotice?action=gimmestuff" onerror="continue"/>

...and they would be cached separately from the rest of the page.

This would open up a lot of new feature and optimization possibilities for us.

Request for Comment page can be found at http://www.mediawiki.org/wiki/Requests_for_comment/Partial_page_caching


Version: unspecified
Severity: enhancement

Details

Reference
bz32618

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:58 PM
bzimport set Reference to bz32618.
bzimport added a subscriber: Unknown Object (MLST).

Weird, I thought there was already a bug for this open

It would be good to abstract the fragment caching / retrieval mechanism so that the decision whether to handle fragments in PHP, the edge or the client is independent of the fragment definition. The less detail knowledge about the (complex) cache infrastructure is needed to use it, the better.

It's unlikely that MediaWiki will support ESI as implemented in Squid and Varnish. E.g. where one or more (cacheable) resources are fetched from a plain url and included as-is.

Any realistic or futuristic MediaWiki skin (even after T111588) will vary too many ways in too many places to be handle-able through something primitive as include-by-url.

For example:

  • Sidebar varies by page.
  • Personal bar varies by user.
  • Content actions varies by both user and page (permissions of the page, user rights, and block status).

Now, that doesn't mean we can't make a performant MediaWiki skin. It just requires that we refactor the skin system to be cacheable as its own entity separate from the page.

That way page views (from anons and logged-in users alike, even with just FileCache and no Varnish) will benefit a cache-hit for the Skin template and Page html. As such, backend hits would be significantly more expensive and would still be allowed to vary in small ways (e.g. to include different banners) since those things can happen at run-time for each page view.

For Wikimedia specifically the overhead of even just the Apache/PHP/MediaWiki WebStart is too much, which is why we'll probably move that run-time layer into a separate service in front of Varnish.

I'm closing this task in favour of: