Filed under: Performance Monitoring
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?
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.