I've been working on a Docker tool for local environments and one of the tools is setting up the ability to easily generate flamegraphs. I figure the best test run would be to dive into some basic info on the performance of a front page load for a typical Drupal Commerce site. There's no magic solution presented here, just some knowledge on what the build process looks depending on caches.

Page load with a cold cache

Here is a first load of a Drupal Commerce site installed from Commerce Deploy with one product display on the homepage. Commerce Deploy is a barebones installation with basic configuration and generally most modules enabled you'd need in a typical site - including Features. The first flamegraph is from a cold cache page load. As you can see a lot of time is spent building the Rules cache, and Rules is integral to the operation of Drupal Commerce. Then you have general hook invocations and everything being collected and cached - Views data, the theme registry, miscellaneous APIs. 

Note: you can click any of the SVGs and navigate the function calls.

One thing I hope you'll notice is the fact cron ran at the end of the menu execution. That's because this is the default settings of "run cron every three hours." That runs when a user visits your site. Here's the same process but with cron set to "never" under the expectation we'll set a crontab to run cron via Drush or wget hourly or so. As you can see, there is a dramatic difference on that first load with a cold cache. One thing to remember, if you're using Features, is that Features will rebuild on cron.

Page load with a warmed cached

Here's the same site once the cache has been warmed. Nifty right? Let's trying adding in Entitycache and Commerce Entitycache see how much that changes the page load.

The performance of a cold cache page load is about the same. But there is quite a difference with entity caching enabled - I actually feel the overall process is cut in half. I have had some developers say Entitycache is pointless unless you're storing it in an in-memory cache like Redis or Memcache. I don't think this is true - however you would most benefit by putting the entity cache in memory and saving your MySQL server from a lot of liftings.

What if I do have a slow Drupal site?

Like I said, there isn't a huge takeaway from this article. But, hopefully, you can grasp an idea of where you might be experiencing bottlenecks and begin resolving the issues. Don't just take Entitycache and toss it on to make a band-aid. Try to discover the issues and prevent them from happening. For what it's worth, using my tool it only took 10 minutes to generate these flamegraphs. If you'd like to learn more about the process, I recommend this blog article on Platform.sh by Christian Sieber about making flamegraphs. In fact, my Platform Docker tool implements the exact workflow of that blog post, but with two commands.