At DrupalCon Dublin I caught Fabianx’s presentation on streaming and other awesome performance techniques. His presentation explained how BigPipe worked to me, finally. It also made me aware of the fact that, in Drupal, we have mechanisms to do expensive procedures after output has been flushed to the browser. That means the end user sees all their markup but PHP can chug along doing some work without the page slowing down.
The process of debugging can be a difficult one, and the process of troubleshooting performance even more so. Luckily there are some great tools out there to help with improving the performance of web applications. Previously I wrote about generating flamegraphs from XHProf to visual stacktraces and identify bottlenecks. Flamegraphs are very helpful, but still require you to setup XHProf, download the tools for making the flamegraph SVG, and appropriately change your code to save the XHProf data.
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.
I use my personal server as a guinnea pig to push my server administrative skills to the edge and help bleed as much performance out of Drupal. So not even an hour and a half ago I signed up for New Relic and installed their monitoring daemon on my server. And I'm in love. The installation was ridiculously easy that even a novice who is scared of the terminal could pull it off.