Problem/Motivation

Follow-up for #2429617: Make D8 2x as fast: Dynamic Page Cache: context-dependent page caching (for *all* users!).

See #219 & #276.4 + replies.

Proposed resolution

  1. Don't vary by route, but by url, this allows us to avoid routing altogether.
  2. Somehow make sure we don't need to run the authentication subscriber anymore, so that we don't need to boot Drupal in order to know the values for the user.* cache contexts. (See #7 for a potential idea.)

Remaining tasks

TBD.

User interface changes

None.

API changes

None.

Data model changes

None.

Comments

Fabianx’s picture

I am all for making things work with url instead of [route] and rely on the cacheable metadata added during access handling on the request object and we can cache the user related cache contexts per 'user session'.

That would then be the same strategy as my ESI v2 battleplan takes, just inside of core instead of in Varnish.

One caveat to all of that is:

- I had problems rendering placeholders without http kernel having run first, because something broke.

So likely this pre-routing middleware is only useful if there are no placeholders that are not cached / cacheable.

Wim Leers’s picture

Status: Postponed » Active
almaudoh’s picture

Title: Investigate moving SmartCache into a middleware at the cost of doing authentication manually if needed » Investigate moving Dynamic Page Cache into a middleware at the cost of doing authentication manually if needed
effulgentsia’s picture

Priority: Normal » Major
Issue tags: +Performance

Raising priority because I suspect the Performance gain from this will be quite large.

effulgentsia’s picture

Version: 8.0.x-dev » 8.1.x-dev

Moving to 8.1 though.

I had problems rendering placeholders without http kernel having run first, because something broke.

If this is still the case, then perhaps this issue could be done in two steps? First step to move it to a much higher priority REQUEST listener to at least factor out dependencies on routing and route-based authentication. Then a second step to move it to a middleware to factor out dependencies on http kernel.

Fabianx’s picture

Yes, agree with #5 to do this in two steps.

Wim Leers’s picture

Issue summary: View changes

Also, as noted in http://wimleers.com/article/drupal-8-dynamic-page-cache#authcache — Authcache uses an interesting trick to sidestep the vast majority of the cost. I'm not sure how safe it is nor if it works with every authentication mechanism. I'm certain we can't use it for Dynamic Page Cache directly, because it relies on every response of the site varying by the same cache contexts (which is grossly inefficient).

But I think we should consider learning from it.

  • The first request from a certain session causes us to bootstrap as far as we do today in HEAD. We store the values for all user.* cache contexts in a cache entry: roles, permissions hash, UID, etc.
  • On subsequent cache requests, we then no longer need to boot very far anymore to do authentication.

(IS updated.)

Fabianx’s picture

#7: Yes, that is the same authentication step per session cookie that I am doing in ESI.

In essence caching the cache contexts.

Wim Leers’s picture

In essence caching the cache contexts.

Yep, and important to note that we cache that per session.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.