#purespeed

Brad Fisher (@bradallenfisher) started a #purespeed channel in our slack channel a few months back. Since then, we’ve both been doing a lot of work to tune every aspect of drupal page delivery. What will follow is a series of blog posts about tuning every part of the stack. We’ll cover:

• The D7 patched, performance optimized core ELMSLN runs off (this post)
• Installing Pound, Varnish and hooking them up to Apache (on the same server)
• Utilizing different cache backends via APCu
• Tuning Apache for better asset delivery and scale
• Drupal contrib via advagg, apdqc, authcache, apc, entitycache, httprl
• Mysql optimizations (and upgrade to 5.5/5.6)
• PHP zend opcache optimization (upgrade to 5.5/5.6)
• Nginx based drupal setups, as well as arguments against not really needing it

In this first post, we’ll look at the patched core that ELMS Learning Network runs as part of its drupal setup.

The core can be found here: ELMSLN Drupal 7 Core.

The patches can all be found here but we’ll walk through each one below:

D7-2263365-17a-module_implements.patch

Second loop in module_implements() being repeated for no reason

This essentially corrects a logical mistake in a big part of core, module_implements that prevents multiple calls to module_implements having to process all the projects involved. module_implements is used a ton of parts of Drupal core and contrib. Optimizing this is a decent gain as can be seen in this comment.

D7_improve_theme_registry-2339447-65.patch

Improve theme registry build performance by 85%

This is pretty insane, infact I couldn’t believe it til I applied it and did some analysis which you can see in the thread. This one patch cut page load times on theme rebuild and clear all caches down about 400ms!

UPDATE: Quicksketch has suggested an alternative patch to this function that goes even further then the one referenced here!

drupal-1443308-37-module_load_include-static-cache.patch

Add static cache to module_load_include()

This is another decent gain by just utilizing static cache correctly and gives significant gains on how long it takes to do full cache clears. This is important because as everyone knows, rebuilding drupal is painful from a performance perspective and this can help make things happier for the unfortunate souls that kick these off or get the first hit after your site has no caches populated. As my findings and others suggest, this took 1.7 seconds off of CC all!!!

drupal-2222635-26-rename-truncate.patch

Waiting for table metadata lock on cache_field table

Captain of amazing performance optimization, Mike Carper realized that cache tables were locking transactions when there were calls to truncate it. By renaming the table, then truncating and renaming it back, he was able to reduce deadlocks. I don’t understand this one to be totally honest but it works :)