At least 20 people helped push one or more issues forward in Montpellier, at the Drupal Dev Days Performance Sprint!

Here’s an overview of what we set out to do, what we did, and what the next steps are.

The plan for DDD Montpellier

• Priority one: uncover the “unknown unknowns”, i.e. finding more performance issues.
• Priority two: Drupal 8’s internal page cache was enabled by default shortly before DDD Montpellier, so we should try to find edge cases where it breaks (where stale content is served from the internal page cache).
• Priority three: fix known performance problems, as well as those uncovered by the work done for priorities one & two.

The sprint board, midweek. Yellow stickies are performance stickies. Middle of the board is “in progress”. Bottom right is “fixed”.

1. Finding more performance issues

We already know that certain things are slow, and we know how to fix them. But significant portions of slowness do not yet have explanations for, let alone precise or even rough plans on how to reduce the slowness.
The parts of Drupal 8 that are slow that we do not have a strong grasp on yet are the bootstrap phase in general, but also routing, container services and route access checking.

Berdir, amateescu, dawehner, yched, znerol, pwolanin and I did a lot of profiling, testing hypotheses about why certain things took a given amount of time, comparing to Drupal 7 where possible, figuring out where the differences lied, and so on.
Bits and pieces of that profiling work1 are in https://www.drupal.org/node/2470679, including patches that help profile the routing system.

In the weeks since DDD Montpellier, effulgentsia and catch have continued discussions there, posted further analyses and filed many more issues about fixing individual issues.

2. Try to break Drupal 8’s internal page cache & fix it

So, Drupal 8 had the internal page cache enabled by default shortly before DDD Montpellier, with only a few known problems. Having many people to try to break it, using scenarios they use daily in their day jobs, that’s the ideal way to find any remaining cache invalidation problems.

Many tried, and most did not succeed in breaking it (yay! :)), but about half a dozen problems were discovered. See https://www.drupal.org/node/2467071.

What we got done

We fixed so incredibly many issues, and we had more than twenty people helping out! Notably, fgm was all over class loading-related issues, borisson_ and swentel got many of the page cache issues fixed, pwolanin pushed routing/REST/menu links issues forward significantly, and we overall simply made progress on many fronts simultaneously.

We made Drupal 8’s authenticated user page loads several percent faster in the course of that week!

Most of the page cache problems that were discovered (see above) were fixed right at the sprint! There are 4 known issues left, of which one is critical on its own, one is blocked, and the two others are very hard.

(If you want more details, we have day-by-day updates on what got done.)

The sprint board, end result. Focused on the bottom right corner: look at all those yellow stickies!

Next steps

We currently have 11 remaining criticals with the “Performance” tag. Getting that to zero is our top priority. But many in that list are difficult.

If you specifically care about performance for authenticated users: less difficult issues can be found in the child issues of the Cache contexts meta issue. And for some least difficult issues, see the child issues of the SmartCache issue.

Generally speaking, all major issues tagged with either “Performance” or “D8 cacheability” can use a hand.

Hopefully see you in the queues! :)

1. It was impossible to capture all things we considered in an issue, that’d have slowed us down at least tenfold. ↩

• Acquia
• Drupal
• performance