ELMSLN performance tuning

August 22, 2014

Update 2: Apache tuning / Costs

There’s another posting thats dedicated to the cost and scale metrics of ELMSLN vs D6 legacy systems we were using. This is an example performance pack of conf settings that should work to do sane tuning on ANY apache system let alone drupal.

Update 1:  CIS / MOOC stats

See bottom of article for an update from the original post after additional tuning!

These are some metrics based on the extensive performance tuning that I’ve had to do as part of the ELMS Learning Network project.  Trying to do a ton of systems on limited resources can be challenging but fortunately there are tons of experts in and outside the drupal community to help make this hapen.  If you haven’t checked it out yet, I highly recommend reading through @mcarper ‘s DIY Drupal 7 Performance presentation. It’s an excellent resource and helped me take things a little further then they already were.

Environment

These are the results I’ve been able to achieve. For understanding of system, these are running on a VM running on VMWare, it’s running:

  • RHEL 6, 64bit
  • 4 gigs of ram, 2 cores
  • Apache, PHP 5.3.x, Mysql 5.x, APC (duh)
  • Drupal 7 loaded in Galaxy packaging format (the way ELMSLN is structured)

CIS

Hitting a rather complex page with multiple views, as user 1 with 155 modules, my final result from devel was:

Executed 75 queries in 8.31 ms. Page execution time was 218.45 ms. Memory used at: devel_boot()=1.78 MB, devel_shutdown()=30.9 MB, PHP peak=31.25 MB.
You can review the process of applying each patch / technique listed at https://gist. github.com/btopro/19a8a4653a41223b6c98
Memory usage is still too high for a single user (obviously) but its cause I”m forcing loadtimes through the floor.

MOOC

Hitting a very simple page (a node) with a few blocks as user 1 with 159 modules enabled, my final result from devel was:

Executed 60 queries in 11.2 ms. Page execution time was 166.02 ms. Memory used at: devel_boot()=1.34 MB, devel_shutdown()=14.64 MB, PHP peak=15 MB.

You can review the process of applying each patch / technique listed at https://gist. github.com/btopro/d424c961273ff5adc968

15 Megs for an authenticated user isn’t terrible though I’d obviously still like to drive it lower. Some of the patches and approaches push queries into RAM which means they might show up as more RAM usage but it’ll prevent the DB from locking (I have almost exclusively authenticated traffic).

The tuning

The part you care about. This is a combination of the DIY article and my own past testing of how to optimize drupal cache bins. They are scary when you first talk about it but it’s actually really easy to optimize drupal’s cache bins without getting extensively into backend / other projects. We use a combination of Filecache, APC, entitycache, Display cache, blockcache alter, HTTPRL, and advagg. I’ve attached a quick drush recipe that will grab and enable all these modules on a site (I’m lazy and hope you are too).

You can copy and paste these at the end of your associated files down the stack if you have permission to do so:

To manage these cache bins, you’ll want to apply something like this shared settings example from ELMSLN example configuration. You’ll need to uncomment the APC and filecache sections if you plan on using them but I’ve optimized for each. If you choose to use APC you’ll want to do some kind of nightly apache restart to avoid memory fragmentation. I’ve also selected cache bins with this in mind. More pervasive cached data gets pushed into APC. Things that are large and may change more frequently get pushed into filecache.

Between the two of them you can get to higher scale for authenticated and non-authenticated traffic on just about any Drupal site. Are there other techniques? Obviously, but these are pretty easy to apply without getting into Varnish land.  Varnish isn’t terribly difficult to get up and going, it’s just another thing to manage, configure and only works for anonymous traffic.

The techniques above help all traffic, regardless of authenticated or not. Hope this helps you scale even simple sites.

Update CIS / MOOC stats

After additional module disabling / clean out. I’ve been able to get CIS down to:

Executed 61 queries in 6.97 ms. Page execution time was 151.61 ms. Memory used at: devel_boot()=1.78 MB, devel_shutdown()=18.27 MB, PHP peak=18.5 MB.

That’s 14 less queries, 67ms less per request and a whopping 12.75MB less per page load! The biggest bloat on these requests was a side block that allows for masquerading from any page. I think in the future we’ll want to take people to a dashboard page that provides the masquerade block for this reason. Also, the DHTML Menu module was enabled and was displaying an admin list on every page, which would invoke menu_tree_load for all items in the list (30ish items). Now with that out it’s dropped dramatically for the home page (as user 1).

Here’s MOOC after doing some permission / optional functionality decoupling

Executed 37 queries in 5.42 ms. Page execution time was 124.36 ms. Memory used at: devel_boot()=1.34 MB, devel_shutdown()=12.55 MB, PHP peak=13 MB.

That’s 2MB lower, 23 less queries, and 40ms less per page load, per user. This is not marginal stuff and proves the old addag in drupal that you need to make sure you’ve only got the modules enabled that you really need to function.

Tags: drupal performance Drupal Planet