Drupal speed tuning: analyzing and further optimizing Pressflow
TL;DR: I've created a fork of Pressflow for the purposes of conversation and analysis -- https://github.com/btopro/Presser-Flow-FORK
History lesson
Pressflow is a very popular Drupal 6 fork of Drupal that lead to many improvements in Drupal 7 from a scale and speed standpoint. It required some tuning but you could start to make it fly and be viable at high scale. Pressflow in Drupal 7, while maintained, really only has a handful of improvements; the most notable I've found to be turning to APC to read in copies of js/css files instead of expecting only the file system. This minor change can really improve speed (5% or so) for sites with lots of JS/CSS files (uhh, any drupal site).
The other improvements are more so in hook flexibility where it allows developers to tap in and do crazier stuff. This makes sense then that many Panthon engineers are involved in its development / maintenance given the crazy scale of their infrastructure / deployments.
Forking Pressflow
If you've read my past posts on here, you'll probably find a trend: I'm obsessed with performance tuning. Any time you can get more responsiveness without more hardware, I'm very, very happy. I've been running a modified drupal core for ELMSLN for some time now and decided instead of keeping these changes / tuning to myself, I'd try and document them / test them and see if any changes make sense for pressflow.
In https://github.com/btopro/Presser-Flow-FORK you can see 3 folders:
- _PATCHES - all the patches (from drupal.org) utilized in the metrics
- _RECIPES - a drush recipe that auto optimizes to the level used in testing, there are also recipes for each of the sites in the test so you can see exactly what was used for testing.
- _METRICS - XLS file with detailed metrics of how testing was performed, where, and what combinations
The full metrics are included in the file, this is just part of the summary. All values in Green mean that they were improvements over the baseline (stock version of core for that site). Red means it regressed. Bold means it was the best value seen in that category.
The fork is called Presserflow (fork) in the image above and you can see it performs pretty well vs Pressflow (it should it's built on top of it). It performs relatively similar with exceptions coming in the form of noteworthy performance improvements on systems dd1 and dd2 around front page load. The other values are pretty similar, Pressflow being slightly better on some and Presser on others; suggesting that it's probably statistically insignificant
Then to make things funny for the "you can't scale that bloated CMS" crowd I ran it against similar settings that I run in production on all of our ELMSLN instances (Kitchen sink). As you can see, kitchen sink and an APC / memory based cache bin system absolutely slaughter Drupal, Pressflow and Presser stock instances. In all categories except memory usage (at times) it destroys the competition.
If you can use APC / memcache or any other advanced caching system I highly recommend it. We use APCu bins to make drupal insanely fast even on only acceptable resource allocations.
Past posts in the ELMSLN performance series: