TL;DR
SmartCache in a nutshell:
- cache the final render array (at the html template level) just before #post_render_cache callbacks are applied.
- return that immediately after routing has taken place, hence avoiding the controller service (and its dependencies) being initialized, along with everything else for building the page.
The resulting performance improvement as user 1 on the frontpage (APCu off, OpCache on, PHP 5.5, XDebug off, XHProf on):
| Run #noapcu-HEAD-front | Run #noapcu-betterPOC-front | Diff | Diff% | |
|---|---|---|---|---|
| Number of Function Calls | 74,623 | 29,687 | -44,936 | -60.2% |
| Incl. Wall Time (microsec) | 183,692 | 76,266 | -107,426 | -58.5% |
| Incl. MemUse (bytes) | 24,710,168 | 13,065,392 | -11,644,776 | -47.1% |
| Incl. PeakMemUse (bytes) | 25,184,944 | 13,246,776 | -11,938,168 | -47.4% |
Problem/Motivation
Drupal 8 is still too slow.
We're render caching bits and pieces (blocks & entities), but we're still running expensive controllers to build the main content array. And we're initializing dozens and dozens of services that we barely use. It's getting more difficult to see what to optimize next.
Drupal has historically always generated the majority of the response dynamically for every request.
But we've been doing massive amounts of work to make things more cacheable. Could we make use that work to break the trend, and make Drupal 8 the first release to generate a minority of the response dynamically for every request?
Proposed resolution
Please read the issue summary at #2429287: [meta] Finalize the cache contexts API & DX/usage, enable a leap forward in performance first!
Given what you've just read in #2429287, you may now realize that once:
- Cache contexts are defined by everything, as they should be (i.e. once that meta is completed)
- Cache context bubbling is implemented (child of the meta: #2429257: Bubble cache contexts)
- Forms are cacheable (#2351015: Link CSRF tokens can be hijacked when cached with insufficient contexts)
- All uncacheable things use
#post_render_cacheplaceholders (just like: node links, comment links, the comment form on entities, and more)
… then we can start to put all of that cache metadata to the originally intended powerful use: cache the entire (#type => html-level) render array, varied by the contexts associated with that route!
And once we have that, we can go even further! We could make it configurable which cache contexts (high-frequency ones, e.g. "per user") we don't actually want to vary by, which we could then automatically replace with #post_render_cache placeholders. We could then run replace those placeholders either when rendering a response (like today), replace them using something like Facebook's BigPipe, or replace them using ESI. It would be configurable.
Algorithm, proofs & next steps — comments wanted!
This issue corresponds to step 1 in the Google Doc: https://docs.google.com/document/d/1Gw7ohBOUKu38t4kMbN9zj6cX-4-_2ZNXGotv...
(We will move this onto Drupal.org once it's 100% fleshed out.)
Remaining tasks
Land the many blockers:
- #2429287: [meta] Finalize the cache contexts API & DX/usage, enable a leap forward in performance, which has many child issues
- #2351015: Link CSRF tokens can be hijacked when cached with insufficient contexts
- When this is unblocked:
- Let smartcache use
CacheContexts::optimizeTokens()
- Let smartcache use
When this gets committed, it must be committed in tandem with #2429257: Bubble cache contexts.
When this gets committed, please also credit Fabianx.
User interface changes
None.
API changes
None.
Credit
HUGE HUGE HUGE thanks to Fabianx, who's helped me enormously in verifying that this actually works! Without him, this issue would be much vaguer. Plus, once this is in, he has amazing ideas for further improvements, he even sees a way to make it work without executing a request at all — resulting in 10–20 ms response times! See the aforementioned Google Doc, steps 2 & 3, for details.