Slow updating of composer dependencies, despite --prefer-dist flag

Question

Why does it take up to two minutes for my composer dependencies to update, even when there have been no changes?

A popular suggestion is to append the --prefer-dist flag:

php composer.phar update --prefer-dist

But this makes no difference in my case. Below is my composer.json file – am I missing something obvious?

{
    "name": "my-namespace/symfony",
    "type": "project",
    "description": "",
    "require": {
        "php": ">=5.3.3",
        "symfony/symfony": "2.3.*",
        "doctrine/orm": ">=2.2.3,<2.4-dev",
        "doctrine/doctrine-bundle": "1.2.*",
        "twig/extensions": "1.0.*",
        "symfony/assetic-bundle": "2.3.*",
        "symfony/monolog-bundle": "2.3.*",
        "sensio/framework-extra-bundle": "2.3.*",
        "sensio/generator-bundle": "2.3.*",
        "sensio/distribution-bundle": "2.2.*",
        "my-namespace/my-bundle": "1.0.*"
    },
   "repositories": [
        {
            "type": "vcs",
            "url": "http://username:password@git.com/my-bundle.git"
        }
    ],    
    "scripts": {
        "post-install-cmd": [
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
        ],
        "post-update-cmd": [
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile"
        ]
    },
    "config": {
        "bin-dir": "bin"
    },
    "minimum-stability": "dev",
    "extra": {
        "symfony-app-dir": "app",
        "symfony-web-dir": "web",
        "branch-alias": {
            "dev-master": "2.3-dev"
        }
    }
}

did you try running the command with `-vvv --profile` as suggested in my answer? What operations are taking so long? Did you have xdebug enabled in php-cli? — Nicolai Fröhlich, Oct 11 '13 at 11:54

score 122 · Accepted Answer · edited May 24 '19 at 17:30

122

This problem is often related to xdebug being loaded in your CLI environment. (It doesn't matter if xdebug is enabled or not.)

You can check whether xdebug is enabled using one of the followinc commands.

// Unix
php -m | grep xdebug
// Windows
php -m | findstr xdebug

Further information on what operations take so long can be gained by enabling maximum verbosity and profiling information. (Replace install with update if you are updating the packages.)

composer install --prefer-dist -vvv --profile

edited May 24 '19 at 17:30

apaderno

28,547
16
75
90

answered Oct 11 '13 at 11:17

Nicolai Fröhlich

51,330
11
126
130

41

I don't have xdebug installed with my PHP and composer run very slowly. – Gustavo Straube May 14 '14 at 21:23
2

with PHP 5.3.10, a fast connection, 6 cores, ssd drive, plenty memory and 4 extra "require" inside a composer.json from symfony.. `composer update` went from 58 to 46 seconds. :/ – bksunday Aug 05 '14 at 05:05
This isn't an issue with bower (backed by twitter) or npm (backed by joyent) so I'm suspecting this is a composer server load issue. – Michael J. Calkins Oct 04 '14 at 20:26
When I run `php -m | grep xdebug` I get red text saying: "xdebug". What does this mean? Enabled, or disabled? – FooBar Apr 02 '15 at 14:46
@Mattias - the red "xdebug" means that the string xdebug was found in the output of `php -m` by grep|findstr ... which is the list of all php-modules currently **loaded**. XDebug **is** loaded in your CLI environment which is - very likely - not necessary ... Wether a profiling or debugging session is automatically started depends on additional ini-settings but the simple fact that the extension is loaded is enough to slow down PHP's execution already. My advice is to remove the `zend_extension=(..)xdebug.(so|dll)` line that's loading the extension from your PHP CLI's `php.ini` configuration. – Nicolai Fröhlich Apr 07 '15 at 07:25
Xdebug also affects phpmd, behat and a ton of other things. ;) – DanielM Apr 28 '15 at 16:49
1

XDebug on the command line is needed for creating code coverage statistics with PHPUnit. – Sven May 26 '15 at 16:28
2

What is `--prefer-dist` doing exactly? – crmpicco Mar 16 '17 at 07:47

alcohol · Answer 2 · 2017-06-21T13:18:47.100

Factors that can slow down Composer:

As pointed out, xdebug can affect the performance of Composer. Running composer diagnose will also warn you about this.
Running update instead of install. People too often just run update constantly. This makes Composer go through the entire dependency resolving process, regardless of whether or not anything has changed. When you run install, Composer takes the requirements directly from your .lock file, skipping the dependency resolving process. You should only run update during the development lifecycle of your application. And even then, it's not something you have to run daily usually.
If you have a specific dependency that you update frequently yourself, you could try simplifying the process by running composer update vendor/package --with-dependencies instead.
Setting minimum-stability to dev. This greatly expands the amount of possibilities that the dependency resolver has to consider. You should almost never lower the minimum-stability to dev unless you absolutely have no other choice. Look into alternatives, such as temporarily using a inline @dev flag.

your suggestion to use `install` resolved my problem. Thanks ! — realtebo, Jun 05 '17 at 09:39

Rai · Answer 3 · 2016-09-14T19:22:13.097

4

Seems like the problem was resolved, but this might help someone.

Whenever I ran composer install or update, it took more than 10 seconds just to fetch the https://packagist.org/packages.json file. Eventually I found out that the problem was related to IPv6, since fetching files from IPv4 sites took less than a second.
The problem is that my ISP doesn't support IPv6, but I had it enabled in my ethernet properties. After I unticked Internet Protocol Version 6 (TCP/IPv6) in my network settings, install/update speeds drastically improved (dropped from 200+ seconds to like 10)

edited Sep 14 '16 at 19:22

answered Jan 04 '16 at 15:54

Rai

656
1
6
14

2

The best answer I have found for this problem is to alias the php command and set the socket timeout to something ridiculous. `alias php="php -d default_socket_timeout=1 -d xdebug.remote_enable=0"` – Alex Barker Sep 21 '16 at 01:31
@AlexBarker thanks for suggesting, however just noting, did not seem to help in my case, -ddefault_socket_timeout=10 result, 308 seconds, -ddefault_socket_timeout=100 result 309 seconds , nor the IP v6 and v4 protocol – FantomX1 May 31 '20 at 16:22

score 3 · Answer 4 · answered Oct 11 '13 at 17:53

You are using a private repository. This will not allow to download zipped version of the version you include, but must clone the repository. Additionally, it might be that the whole repository must be scanned to find the required version.

You should check whether using Satis is an option. That way you could prepare ZIPs of your own software and download it just like the things hosted on Github (which has an API for this that is used by Composer to allow downloading ZIPs even if they are not explicitly prepared).

score 3 · Answer 5 · answered Feb 01 '14 at 01:21

3

I was having this issue while running Symfony2 on a VM that had low memory. I increased the machine's memory and it improved drastically. You may check the memory on your system and see if it can be upgraded.

answered Feb 01 '14 at 01:21

John Sampson

544
4
11

This, was using the default Vagrant's Memory of 384mb, increasing this to 1gb was enough, turns out composer was peaking at 456mb – Aren Sep 10 '15 at 23:03

score 3 · Answer 6 · answered Mar 14 '18 at 18:06

3

I had same issue with composer update, I updated composer itself to the latest version using composer selfupdate and now it's speed acceptable.

answered Mar 14 '18 at 18:06

ako

2,000
2
28
34

ivn · Answer 7 · 2020-07-20T12:19:24.020

MY SOLUTION WINDOWS 10 x 64 bits WAMP user with Laravel, after weeks of slow composer update and composer require

you use need a thing called cacert.pem

https://curl.haxx.se/docs/caextract.html

then paste that file in your wamp main directory C:\wamp64\cacert.pem

then in the search tab search for php.ini open all the files with that name on sublime or any text editor

find a line called curl.cainfo and openssl.cafile

PUT YOUR PATH TO THIS FILE - see the example on my case:

curl.cainfo="C:\wamp64\cacert.pem"

and

openssl.cafile="C:\wamp64\cacert.pem"

do this on all the php.ini files you search before, in all the files!

OKAY RESTART SERVER that work for me, hope for you I wish someone before would make this comment! so I would not spend 2 weeks fixing it

also call

composer config --global repo.packagist composer https://packagist.org

this make the connection on https run this too

composer install --prefer-dist -vvv --profile

score 0 · Answer 8 · answered Nov 11 '15 at 18:32

Indeed, xdebug is certainly going to slow things down. Uninstalling xdebug is not ideal though. A good option is to use HHVM and put it on composer duty.

Installing HHVM is pretty painless, and HHVM itself is much more rapid than PHP5. It's a double-win -- YMMV, but I got near-5x speed increase (on the eyeball dyno admittedly) in the composer usage I'd get even if xdebug weren't in the picture.

If you are on OS X, then this link might help (blog article I wrote on the matter):

http://circlical.com/blog/2015/11/11/slow-composer-on-os-x

Stian S · Answer 9 · 2018-07-06T11:04:19.263

0

Check if zip and unzip are installed. If they are missing, Composer will clone the repo instead of downloading a zipped release.

edited Jul 06 '18 at 11:04

answered Jul 06 '18 at 10:53

Stian S

537
6
12

Thanks, it seems logical, as the composer also complained with `As there is no 'unzip' command installed zip files are being unpacked using the PHP zip extension.` however, running it with zip library installed, the same process and conditions - it was 750 seconds, without libraries 650 seconds, just one simulation. Moreover other than that my installation had php-zip preinstalled undependanty of it, that Linux zip, unzip packages were not installed, yet composer still complained it not being there until were install as Linux libraries. – FantomX1 May 31 '20 at 17:21

score 0 · Answer 10 · answered Jul 27 '20 at 12:43

I had a problem due to having IPv6 enabled. Running the following fixed this problem:

sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"

You can find more information here: https://getcomposer.org/doc/articles/troubleshooting.md#operation-timed-out-ipv6-issues-

Slow updating of composer dependencies, despite --prefer-dist flag

10 Answers10

Linked