Drupal 8: Front to Back
by September 12, 2013

Filed under: Performance Monitoring

AppNeta no longer blogs on DevOps topics like this one.

Feel free to enjoy it, and check out what we can do for monitoring end user experience of the apps you use to drive your business at www.appneta.com.

Over the past few months I’ve covered some of the many ways in which Drupal 8 is a large departure from its predecessors. While I’ve mainly written about the new backend architecture, Drupal’s frontend is also experiencing plenty of exciting changes. Its visual identity may still be the soft blue and white that we’ve come to love, but a lot of work has been done under the hood thanks to efforts like Acquia-sponsored Spark. But any time capabilities are enhanced, one question should spring to mind: what kind of performance costs are they associated with?

We often think of ‘frontend performance’ as the perceived speed of a site in providing functionality to users. Depending on how that site is constructed, this value might have little to do with how long it actually takes to complete requests or render a page. Increasing frontend performance is a great way to increase conversion rates and user satisfaction, and because so directly tied to a business concern, it’s often a responsibility for a group outside the main development organizations. Sometimes, it’s put into the control of a user experience team, but smaller organizations might even make it a concern of the marketing department.

Despite this, developers still need to be involved with the frontend because decisions made there can indeed impact application scaling. AJAX-based interfaces can result in a high request volume hitting your backend servers, while WebSocket connections require their own scaling considerations. On very large sites, even a mistake as simple as serving an asset directly from your application server can bring down your entire site.

Apart from complex or pathological cases, backend scaling for anonymous users has been a ‘solved problem’ since Pressflow hit the scene. Avoiding session creation (or more generally, any kind of backend personalization) greatly increases the effectiveness of page caching in Varnish. This caching tier takes most of the load off of the Drupal environment, but the largest sites can even place a CDN in front of that cache. Even some authenticated content can be cached with these strategies, thanks to technologies like AJAX-based personalization and Edge Side Includes. Drupal 8 doesn’t change this paradigm, and an anonymous user will only have to download a handful of assets. In an environment with tiered caching, the application server won’t even be aware of their visit.

But what’s the Drupal 8 experience like for an authenticated user?

From a purely frontend perspective, the number of required assets increases thanks to modules like Overlay. On a stock Drupal 7 site, serving to an uncached but already logged in administrator account required 204 KB of transfer over 68 requests. In Drupal 8, a similar configuration required 291 KB of transfer over 97 requests. The increase is size is real, but it’s negligible when put in absolute terms, especially because some of the ‘offenders’ included new frontend JavaScript libraries like Backbone.js and Underscore.js. Drupal’s stock settings leave CSS and JS aggregation disabled, and changing that setting would have significantly decreased both the size of the page and the size of the gap between versions.

Tools like Firebug can determine whether a request was cached by Varnish, but uncached requests made by AppNeta's AppView Web include links back to the corresponding server trace on the Drupal environment.

Tools like Firebug can determine whether a request was cached by Varnish, but uncached requests made by AppNeta’s AppView Web include links back to the corresponding server trace on the Drupal environment.

But what about the huge increase in the number of requests? Drupal 8 loaded twenty more JavaScript files, but these would have aggregated very well in any kind of realistic production deployment. On the other hand, 22 out of those 97 requests were XMLHTTPRequests! This is a huge difference from Drupal 7 where most larger sites are using a variant of one of a few VCL files like Lullabot’s that treat the presence of a session cookie as indicating possible customization based on user data. Unlike CSS and JS files, these additional requests can’t be easily classified by file type as ‘static even when served to a logged in user’. This will make caching them for logged in users much harder; in fact, more than half of those XHRs were totally uncacheable POST requests to /edit/attachments.

An XMLHTTPRequest into /edit/attachments visualized by the TraceView Drupal module. The initial request to Drupal\Core\Controller\AjaxController.content was routed (via a sub-request) into Drupal\edit\EditController.attachments.

An XMLHTTPRequest into /edit/attachments visualized by the TraceView Drupal module. The initial request to Drupal\Core\Controller\AjaxController.content was routed (via a sub-request) into Drupal\edit\EditController.attachments.

The upshot of all this is that authenticated users will cause even more load on Drupal application servers than they today. While individually fast, each of those XHRs bypassing Varnish increases resource utilization on the underlying application server. It’s possible that enhanced VCLs for Varnish could be produced that respect Drupal 8’s frontend paradigm, but such solutions probably won’t be forthcoming until it nears release. Until then, developers experimenting with scalable Drupal 8 should be aware of how the exciting new frontend capability could take a toll on the backend.