[META] Things to figure out in order to use Composer 2 to perform automatic updates

To help answer the question about how much PHP memory Composer 2 needs, here is a method to benchmark it:

https://github.com/composer/composer/pull/8850#issuecomment-660145941

It would be interesting if people ran this on various projects to determine the memory usage and shared the results.

Do we need to support OAuth tokens for reasons other than rate limiting? E.g., access to a private repository, or is that out of scope?

Wouldn't that be something which Composer itself would take care of (assuming it does)? My assumption is that Drupal would just call the Composer APIs and Composer would handle the authentication to get the packages it needs to do any updates/installs.

https://github.com/zaporylie/composer-drupal-optimizations/pull/17 has some info on memory/cpu needs for Drupal.

Also, some other notes around composer v2 versus v1: https://github.com/composer/composer/issues/8726

https://www.drupaleasy.com/blogs/ultimike/2020/07/composer-20-alpha2-per... has some good details about performance.

I ran some numbers on an 8.9 site and composer v2. It has 72 required modules and composer dependencies, including things like group, masquerade, admin_toolbar, calendar, core-recommended, etc and 3 require-dev. One of the require-dev is drupal/core-dev. I flushed composer cache and tried the commands a few times. My internet speed isn't all that great.

composer update drupal/entity --profile
Memory usage: 19.93MiB (peak: 22.41MiB), time: 7.66s
Memory usage: 19.75MiB (peak: 22.22MiB), time: 1.73s
Memory usage: 19.75MiB (peak: 22.22MiB), time: 1.77s

This site also was running 8.9.1 and needed to be updated to 8.9.2 (the latest at the time). Much of the time on the first run was spent downloading dependencies.
composer update drupal/core-recommended --with-all-dependencies --profile
Memory usage: 96.47MiB (peak: 544.39MiB), time: 64.59s
Memory usage: 94.56MiB (peak: 544.25MiB), time: 24.29s
Memory usage: 51.1MiB (peak: 514.76MiB), time: 23.91s

So obviously something like drupal core is going to have a lot bigger hit on memory (and duration). But this is a lot better then what we saw with v1.

For comparison, the same commands using composer v1:
composer update drupal/entity --profile
Memory usage: 496.29MiB (peak: 2006.01MiB), time: 240.28s
Memory usage: 496.35MiB (peak: 2006.14MiB), time: 35.92s
Memory usage: 496.29MiB (peak: 2006.02MiB), time: 49.2s

composer update drupal/core-recommended --with-all-dependencies --profile
Memory usage: 496.3MiB (peak: 2006.14MiB), time: 223.58s
Memory usage: 496.29MiB (peak: 2005.96MiB), time: 45.05s
Memory usage: 496.29MiB (peak: 2005.96MiB), time: 32.99s

The test I link to in comment #2 uses a method where network is not an issue.

Thanks @ressa. That will help with the memory and baseline for time. Still useful (I think) to include some network numbers for those of us who have poorly connected internet. It gives us a starting point to see how bad it could really get if internet is slow and there's no cache of any dependencies. Also note, the computer running these is a fairly speedy laptop and all tests were run inside of DDEV on Ubuntu 20.04. On slower shared hosting, the time might be longer. I wouldn't expect the memory to be significantly higher, but who knows.

As pre-steps:
composer self-update --snapshot or composer self-update --preview
composer update --dry-run
composer remove cweagans/composer-patches drupal/console zaporylie/composer-drupal-zaporylie/composer-drupal-optimizations

The later are needed to get rid of some packages that are typically added to a lot of sites, but which don't have composer v2 support at the moment.

Here's the stats for Composer 2.0.0-alpha2:
COMPOSER_DISABLE_NETWORK=1 composer update drupal/entity -v --dry-run --profile
Memory usage: 20.5MiB (peak: 23.04MiB), time: 0.53s

COMPOSER_DISABLE_NETWORK=1 composer update drupal/core-recommended --with-all-dependencies -v --dry-run --profile
Memory usage: 45.68MiB (peak: 509.75MiB), time: 7.34s

And with 1.10.9:
COMPOSER_DISABLE_NETWORK=1 composer update drupal/entity -v --dry-run --profile
Memory usage: 495.67MiB (peak: 2006.35MiB), time: 33.24s

COMPOSER_DISABLE_NETWORK=1 composer update drupal/core-recommended --with-all-dependencies -v --dry-run --profile
Memory usage: 495.67MiB (peak: 2006.34MiB), time: 38.95s

It might be good to get others to run these same commands and report back their memory utilization. Updating entity module and updating drupal core are both good baselines.

Great @heddn, and I agree that it is also useful to get a feeling for how long it might take with slower connections. 240 seconds is a long time, though :-)

Here are the numbers for a Drupal 8.8 installation with 37 contrib modules, some pinned, some with Tilde (~) and Caret Version Range (^). It looks like we both get around 5.5 times faster results with Composer 2:

$ COMPOSER_DISABLE_NETWORK=1 composer update -v --dry-run --profile
Package operations: 116 installs, 0 updates, 0 removals

Composer 1.10.9
[476.0MiB/29.90s] Memory usage: 475.97MiB (peak: 1801.4MiB), time: 29.9s

Composer 2 snapshot
[43.7MiB/5.27s] Memory usage: 43.72MiB (peak: 573.23MiB), time: 5.27s

re #9: doing the update on a per project basis is more helpful then for everything. As we probably won't be updating everything, all the time, when we update with this initiative.

Really interesting results here.

re #9: doing the update on a per project basis is more helpful then for everything. As we probably won't be updating everything, all the time, when we update with this initiative.

That could also be a good option for Drupal running updates unattended or from the UI, batch everything, only do one module/theme/core update at a time, but find a way to cache things when multiple updates are needed at the same time.

... doing the update on a per project basis is more helpful

That makes sense. I couldn't get drupal/core-recommended to work (drupal/core-composer-scaffold is locked to version 8.8.1 and an update of this package was not requested.) as can be read in the issue below, Composer fun:
https://www.drupal.org/forum/support/upgrading-drupal/2020-07-15/problem...

So I had to resort to update drupal/core-*:
COMPOSER_DISABLE_NETWORK=1 composer update drupal/core-* --with-all-dependencies -v --dry-run --profile

Composer 1.10.9
[474.2MiB/20.79s] Memory usage: 474.2MiB (peak: 1867.01MiB), time: 20.79s

Composer 2.0.0-alpha2 (preview)
[45.7MiB/5.08s] Memory usage: 45.69MiB (peak: 513.04MiB), time: 5.08s

re

Do we need to support OAuth tokens for reasons other than rate limiting? E.g., access to a private repository, or is that out of scope?

I would think this would be out of scope. We are first targeting just security releases. These would all be from
https://packages.drupal.org/8" repository correct? Even when we add regular updates for core and contrib this would always be against this repository.