Given all the buzz about the performance hit in Drupal 7, I figured I may as well propose this. A week ago, I finished adding an "external" caching mode to Pressflow that sends cache-friendly HTTP headers without the overhead of maintaining the internal page cache.

Here's the commit that added it:
http://bazaar.launchpad.net/%7Epressflow/pressflow/6/revision/63

Here's the release announcement (quoted below):
https://launchpad.net/pressflow/+announcement/4249

[...] There is a new "external" caching mode. Like the existing aggressive cache, it allows downstream proxies to cache content for anonymous users. The new external caching mode allows a downstream proxy to cache the content on the first page load instead of waiting for a hit in the internal Pressflow page cache. More importantly, it disables and skips the internal page cache altogether, saving CPU time on web servers, cache space in memory, and providing the first solid approach for sites with complex caching requirements (like single sign-on and ad-tracking cookies).

This would be relatively trivial to port to Drupal 7, and the code would only affect users enabling the external cache. If there's interest and a chance of it getting in, I'd be happy to roll a patch.

Comments

catch’s picture

OK so if I understand this correctly, at the moment you can either:

# use a reverse proxy with the page cache, and have duplicated data
# use a reverse proxy without the page cache and send the wrong cache headers

To me this sounds like a missing bit of the reverse proxy support we added to Drupal 7, and not an API change, so don't see a particular reason why it wouldn't be accepted.

Just a general note, while I've not tested recently, core's page cache holds up pretty well between D7 and D6, it's logged-in performance (especially in PHP) which is suffering. But that doesn't stop this being a good change in itself.

catch’s picture

Title: Port Pressflow's external cache to Drupal » Document using a null cache for page caching with reverse proxies

Damien in an e-mail thread pointed out that we can use a NULL cache implementation for the page cache to get the same thing. That needs to be documented somewhere - not really sure if it's a core thing, possibly just in the handbook somewhere, but changing focus.

david strauss’s picture

Assigned: david strauss » Unassigned

Unassigning myself because I'm probably not the right person to document this.

Status: Active » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.