Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Currently, drush features-revert-all
is very slow on a site with many feature modules. A quick look in the command callback function reveals that drush_invoke_process() is called for each feature, which means that Drupal is bootstrapped once for every feature module on the site. This is should be an easy win, but there might be other performance gains to be had.
Comment | File | Size | Author |
---|---|---|---|
#9 | features-2071859-improve-drush-performance-d6-9.patch | 7.87 KB | q0rban |
#1 | features-2071859-improve-drush-performance-1.patch | 7.96 KB | q0rban |
Comments
Comment #1
q0rban CreditAttribution: q0rban commentedIn doing this, I realized there were other commands using drush_invoke_process() instead of drush_invoke(), so I am expanding this issue to include those as well. In general, these commands are just not optimized for sites with lots of features, so I'm going to be adding some other tweaks to improve that.
Tested this out with
drush features-revert-all -y
on a site with just 14 features.Timer before patch:
Timer after patch:
Here's the same test run with
--force
, increasing the number of feature modules to 16, but more importantly, increasing the number of components that are reverted. I didn't bother counting. :)Timer before patch:
Timer after patch:
This patch includes the following changes:
-y
is passed tofeatures-revert-all
, the confirmation message is silenced to avoid extraneous output from the command.-y
is passed tofeatures-update-all
, the confirmation message is again silenced.features-revert-all
now lists the feature name and component name. Before, just the component name was listed, so you weren't sure what feature it related to.drush fr
as arguments, instead of looping over them and doing individual calls todrush fr
. This should lower the memory footprint of the command.else if
toelseif
.drush_log()
instead ofdrush_print()
to print out the warning that a module already exists infeatures-update-all
.Comment #2
mpotter CreditAttribution: mpotter commentedNeed to use the "needs review" status if you want the tester bot to run tests against this.
Comment #3
hefox CreditAttribution: hefox commentedI've thought about this before and reason haven't persuade it is worry about timeouts, but as there's also a patch to change memory limit for features_revert/rebuild, that doesn't seem an issue. Looks good from a brief lookover, but haven't tested
Comment #4
q0rban CreditAttribution: q0rban commentedWhoops, sorry about that @mpotter. :)
Comment #5
markdorisonq0rban++
Comment #6
davidburnsI've been developing sites with this patch for almost 2 weeks without any issues, only performance improvements.
I think this is RTBC.
Comment #7
mpotter CreditAttribution: mpotter commentedCommitted to 7d56c4f.
Comment #8
q0rban CreditAttribution: q0rban commentedYay! I need this for some d6 sites as well. Should be fairly trivial to backport.
Comment #9
q0rban CreditAttribution: q0rban commentedComment #10
djdevinLooks good, running this on our stage deployments with about 20 features.
Comment #11
apotek CreditAttribution: apotek commentedA useful, tested, RTBC patch that constitutes a real improvement on both D6 and D7 and.... *crickets*
Comment #12
Matt V. CreditAttribution: Matt V. commented@apotek
The D7 version of the patch has already been applied.
The D6 version is still marked "Needs review." If you're interested in moving the issue along, you might consider reviewing/testing the D6 version of the patch in Comment #9 above.
Comment #13
apotek CreditAttribution: apotek commented@Matt V
Thank you for the reply. Since the patch in comment 9 is written against the -dev version of features (appropriately), we won't really be able to test the patch with our current production codebase, so it wouldn't be a like-for-like test.
I'm going to see if I can write a modified version of the patch against the 6.x-1.2 release so we can at least test the concept.
Comment #15
kenorb CreditAttribution: kenorb commentedMarking as fixed, as 6.x is no longer supported.
Comment #16
kenorb CreditAttribution: kenorb commentedBtw. This change by changing drush_invoke_process into drush_invoke caused disadvantage that now the feature command can't be altered.
This is trouble for me, because I wanted to add extra logic before running the feature revert, and I can't do that for fra, because not all arguments are available.
It's maybe quicker, but made things less flexible. So I'll have to write my own wrapper anyway to use drush_invoke_process instead.
Or patch the Features to use drush_invoke_process again, e.g.
drush_invoke_process("@self", "features-revert", drupal_map_assoc($features_to_revert));
See: How to alter command being run by drush_invoke?
Comment #17
mpotter CreditAttribution: mpotter at Phase2 commentedPlease open a new issue for that and suggest a patch. Although rather than changing the drush commands I'd probably recommend implementing one of the many hooks that get called before or after various features operations, such as revert, rebuild, etc.
Also, you'll need to show some performance numbers indicating that changing back to drush_invoke_process() doesn't re-introduce the performance issue that was fixed here.