Why is PHP Composer so slow?

Question

Why is PHP Composer so slow when all I do is init a project with zero dependencies? Here are the commands I run:

composer init

composer install

Wait 3 minutes (not an exaggeration).

All composer has to do is pull in an autoloader and create /vendor, so why does it take so long? For that matter, why doesn't that step happen on composer init?

Is there a configuration option I can use to pull in a cached autloader and vendor upon init?

More seriously: have you updated your composer in the last 30 days? There was a major performance improvement to the code just last month — Mark Baker, Feb 10 '15 at 16:10
I started `compose install` more than 5 minutes ago and it didn't complete yet. `Composer version 1.0-dev (07c644ac229a21df80180598d8bb9aaba232eecb) 2015-02-03 12:51:10`. Maybe it's not the most recent version but still newer than your IBM mainframe ;-) — axiac, Feb 10 '15 at 16:13
I struggled with composer update and composer self-update being incredibly slow. Taking more than 15 minutes and then throwing exceptions. I changed my router DNS servers (from Google's to my ISP's own) and composer worked like a charm. — Gordon Hickley, Jun 25 '15 at 03:47
I was using my ISPs DNS servers, but based on the above comment, I put packagist.org in my /etc/hosts file and things started working. Note you shouldn't consider this canonical as packagist.org's IP is subject to change at any moment. However, it got me through an initial installation. — levans, Oct 09 '18 at 18:23
now, on my machine even `composer --version` is slow (otherwise a fast machine - Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz, 16GB DDR3, SSD) — Constantin Galbenu, Nov 23 '18 at 09:30

score 390 · Answer 1 · edited Oct 25 '19 at 14:32

390

Because Composer is implemented by file_get_contents(). That has no TCP optimizations, no Keep-Alive, no multiplexing, etc.

I created a Composer plugin to download packages in parallel: https://packagist.org/packages/hirak/prestissimo

$ composer global require hirak/prestissimo

Please try it. In my environment, composer install becomes 10 times faster.

edited Oct 25 '19 at 14:32

Peter Mortensen

30,738
21
105
131

answered Jun 29 '16 at 14:11

hiraku

4,217
2
12
7

14

Good news: This was apparently merged into Composer 2 in January 2019: https://github.com/composer/composer/pull/7904 – Chuck Le Butt Jul 09 '19 at 20:00
@ChuckLeButt but release still out of sight :( – hejdav Feb 19 '20 at 22:33

score 65 · Answer 2 · edited Oct 25 '19 at 14:35

65

Make sure you have the latest version of Composer.
Install in verbose mode by adding -vvv, for example composer global require "squizlabs/php_codesniffer=*" -vvv
If you are able to find out where Composer is facing slowness, for example mine was getting stuck for 5 minutes when downloading packages. It took >5 minutes to download a 20 kB file on a 50 Mbit/s connection. This was because it was downloading the packages from packagist using HTTP and not HTTPS. Making these changes to the configuration has resolved my issue: composer config --global repo.packagist composer https://packagist.org

edited Oct 25 '19 at 14:35

Peter Mortensen

30,738
21
105
131

answered May 25 '17 at 07:36

sgr12

1,047
11
13

3

I'm new to composer and try to fix this for 2 days, after read your comment and add -vvv, it's finally worked. 1000 upvotes – Huy Trịnh Jul 18 '17 at 14:40
#3 solved it for me. You are my hero right now. Was worried for quite some time now why it is so slow and only worked on some internet connections. Thx! – Andreas Schantl Feb 04 '20 at 02:16
`composer config --global repo.packagist composer https://packagist.org ` what was that! Awesome! – Rishi Kulshreshtha Feb 20 '20 at 13:57

score 48 · Accepted Answer · edited Oct 25 '19 at 14:29

48

Also, disable Xdebug. Xdebug can cause Composer to take minutes even when running a command as simple as composer --version.

edited Oct 25 '19 at 14:29

Peter Mortensen

30,738
21
105
131

answered Jan 07 '17 at 19:58

adjco

604
6
4

1

This actually turned out to be my issue. Xdebug makes composer run ultra slow. – AgmLauncher May 25 '17 at 13:59
3

In the time of writing, I had the same performance with or without debug, since in 2020/2019 composer automatically disabled xdebug when running, in spite of that installing yii2-starter-kit took about 200 seconds with all libraries be it w/wo xdebug, so this reply is becoming outdated – FantomX1 May 25 '20 at 16:10
Saw this, pulled up my debugger. Found that even though xdebug is configured for FPM only, the CLI had initiated it and my IDE was sitting there at a break point waiting for me. Hit continue and composer kicked right back in. – ppostma1 Jun 25 '20 at 04:01

score 13 · Answer 4 · edited Oct 25 '19 at 14:31

13

The same here. Get more details with "composer install --profile -vvv". In my case it takes a long time to download a few JSON files. They get cached on my server, but they are still downloaded with every Composer update/install call.

... 30 minutes later ...

It looks like some performance problem @packagist.org. Now the Composer install runs within 2 seconds! And downloaded JSON files are properly cached.

edited Oct 25 '19 at 14:31

Peter Mortensen

30,738
21
105
131

answered Feb 10 '15 at 16:31

ppan

131
4

1

"They get cached on my server but are still downloaded with every composer update/install call" THIS !! Have you found a solution for this problem ? I have a slow connection and it's terrible to see that. – lud May 28 '18 at 17:10

score 10 · Answer 5 · edited Oct 25 '19 at 14:38

10

I was running into this issue, and it was throwing me for a curve since I don't have Xdebug installed anywhere on my machine. It turns out that it was IPv6 addressing mode failures. So to test I ran

curl --ipv4 'https://packagist.org/packages.json'
curl --ipv6 'https://packagist.org/packages.json'

IPv4 went through, but IPv6 failed. In the end, you should look to find out why you're networking stack doesn't support it, but in my case, I decided to just give preference to IPv4 traffic until I can resolve that. On CentOS I created/modified the file /etc/gai.conf and put in the following:

label       ::1/128        0
label       ::/0           1
label       2002::/16      2
label       ::/96          3
label       ::ffff:0:0/96  4
precedence  ::1/128        50
precedence  ::/0           40
precedence  2002::/16      30
precedence  ::/96          20
precedence  ::ffff:0:0/96  100

On Ubuntu you can also edit that file and uncomment the line

precedence ::ffff:0:0/96  100

Source on Rackspace Community Hub

edited Oct 25 '19 at 14:38

Peter Mortensen

30,738
21
105
131

answered Jan 02 '19 at 22:13

Aaron Chamberlain

653
2
10
26

Just for a note, this did not seem to help me personally, although I will have to resimulate it to confirm all the options, which of them could be the cause. – FantomX1 May 31 '20 at 15:31
@FentomX1 Sorry to hear that. That's why I included the test up top. If you do both curl tests and it's connecting, then obviously, the changes shouldn't be made because your network is set up correctly. – Aaron Chamberlain Jun 01 '20 at 16:53
1

Found a short YouTube video showing how to do this on Windows 10. It fixed my problem. https://www.youtube.com/watch?v=63Lt_vlNWLc – Marcus Sep 20 '20 at 03:59

Liam Mitchell · Answer 6 · 2020-08-11T12:51:59.227

5

On Ubuntu Xenial 16.04 VPS, you need to do the following:

sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"
composer global require hirak/prestissimo

It configures IPv4 as preferred over IPv6.

https://serverfault.com/questions/93717/setting-ipv4-as-preferred-protocol-over-ipv6

edited Aug 11 '20 at 12:51

answered Mar 07 '19 at 00:40

Liam Mitchell

1,001
13
23

since i installed prestissimo, my composer speed has been excellent. – Big Tree Jun 29 '19 at 14:49
3

I can confirm that this solution works even for ubuntu 18.04LTS – mwangaben Oct 10 '19 at 13:56
Please add some explanation to your answer such that others can learn from it. What does that first line do? – Nico Haase Aug 10 '20 at 10:37
@NicoHaase If you look at the timestamps, this answer is actually a response to the issue I described, but they didn't put it as a comment. I incorporated it into my answer anyways. It seems that packagist prefers to use IPV6, but some networks still don't work well with it. The first line makes it so that your Linux Machine will prefer IPv4 addresses and look for those first. – Aaron Chamberlain Aug 10 '20 at 22:48

FantomX1 · Answer 7 · 2020-08-10T11:08:38.563

Edit: Conclusion: no solution listed here or generally seems to be bulletproof. What ultimately helps is usually using composer incrementally, requiring or removing only a single package at a time using composer require, composer remove command, also regards adding any "non-dependency specific" setting, any library can be added/removed for the sake of it of updating/refreshing the composer.json lock cache configuration.

Grouping my experience with answers from here and from the linked in question.

Prior I tried every single solution mention in this question to this time. However, it still did not help me, though I tried/noticed installing any other single library was considerably fast, so I went on investigating libraries one by one which could cause the bottle-neck.

1) YES And I located it to be codeception, "codeception/codeception": "2.4.0",

It took almost 200 seconds alone, though running it together with other libraries seemed at some times running almost for 12 minutes. Furthermore composer does not seem to reflect real-time when after initiating for 20 seconds it outputs it run 0.35s and so on later.

[374.9MiB/173.14s]     39/45:   https://codeload.github.com/sebastianbergmann/php-text-template/legacy.zip/31f8b717e51d9a2afca6c9f046f5d69fc27c8686
[374.9MiB/173.16s]     40/45:   https://codeload.github.com/sebastianbergmann/diff/legacy.zip/720fcc7e9b5cf384ea68d9d930d480907a0c1a29
[374.9MiB/173.17s]     41/45:   https://codeload.github.com/sebastianbergmann/exporter/legacy.zip/68609e1261d215ea5b21b7987539cbfbe156ec3e
[374.9MiB/173.19s]     42/45:   https://codeload.github.com/sebastianbergmann/phpunit-mock-objects/legacy.zip/f9756fd4f43f014cb2dca98deeaaa8ce5500a36e
[374.9MiB/173.20s]     43/45:   https://codeload.github.com/sebastianbergmann/recursion-context/legacy.zip/5b0cd723502bac3b006cbf3dbf7a1e3fcefe4fa8
[374.9MiB/173.23s]     44/45:   https://codeload.github.com/sebastianbergmann/php-code-coverage/legacy.zip/4cab20a326d14de7575a8e235c70d879b569a57a
[374.9MiB/173.24s]     45/45:   https://codeload.github.com/doctrine/instantiator/legacy.zip/ae466f726242e637cebdd526a7d991b9433bacf1
[374.9MiB/173.24s]     Finished: success: 45, skipped: 0, failure: 0, total: 45
[374.8MiB/173.25s] Analyzed 6622 packages to resolve dependencies
[374.8MiB/173.25s] Analyzed 435842 rules to resolve dependencies
[374.8MiB/173.25s] Package operations: 54 installs, 0 updates, 0 removals
[374.8MiB/173.26s] Installs: sebastian/recursion-context:3.0.0, sebastian/exporter:3.1.2, doctrine/instantiator:1.3.0, phpunit/php-text-template:1.2.1, phpunit/phpunit-mock-objects:6.1.2, codeception/stub:1.0.4, sebastian/diff:3.0.2, sebastian/comparator:3.0.2, theseer/tokenizer:1.1.3, sebastian/version:2.0.1, sebastian/environment:3.1.0, sebastian/code-unit-reverse-lookup:1.0.1, phpunit/php-token-stream:3.1.1, phpunit/php-file-iterator:1.4.5, phpunit/php-code-coverage:6.0.5, sebastian/object-reflector:1.1.1, sebastian/object-enumerator:3.0.3, sebastian/global-state:2.0.0, phpunit/php-timer:2.1.2, symfony/polyfill-ctype:v1.17.0, webmozart/assert:1.8.0, phpdocumentor/reflection-common:2.1.0, phpdocumentor/type-resolver:1.1.0, phpdocumentor/reflection-docblock:5.1.0, phpspec/prophecy:v1.10.3, myclabs/deep-copy:1.9.5, sebastian/resource-operations:1.0.0, phar-io/version:1.0.1, phar-io/manifest:1.0.1, phpunit/phpunit:7.1.5, codeception/phpunit-wrapper:7.6.1, symfony/yaml:v4.4.8, behat/gherkin:v4.6.2, symfony/polyfill-mbstring:v1.17.0, symfony/dom-crawler:v4.4.8, symfony/css-selector:v4.4.8, symfony/browser-kit:v4.4.8, symfony/event-dispatcher-contracts:v1.1.7, psr/container:1.0.0, symfony/event-dispatcher:v4.4.8, symfony/service-contracts:v2.0.1, symfony/polyfill-php73:v1.17.0, symfony/console:v4.4.8, symfony/finder:v4.4.8, ralouphie/getallheaders:3.0.3, psr/http-message:1.0.1, guzzlehttp/psr7:1.6.1, guzzlehttp/promises:v1.3.1, symfony/polyfill-php72:v1.17.0, symfony/polyfill-intl-idn:v1.17.0, guzzlehttp/guzzle:6.5.3, symfony/process:v4.4.8, facebook/webdriver:1.7.1, codeception/codeception:2.4.0
[374.8MiB/173.28s]   - Installing sebastian/recursion-context (3.0.0): [374.9MiB/173.28s] Loading from cache[374.9MiB/173.28s]
[374.9MiB/173.28s]  Extracting archive[374.9MiB/173.51s]   - Installing sebastian/exporter (3.1.2): [374.9MiB/173.52s] Loading from cache[374.9MiB/173.52s]
[374.9MiB/173.52s]  Extracting archive[374.9MiB/173.75s]   - Installing doctrine/instantiator (1.3.0): [374.9MiB/173.76s] Loading from cache[374.9MiB/173.76s]
[374.9MiB/173.76s]  Extracting archive[374.9MiB/174.00s]   - Installing phpunit/php-text-template (1.2.1): [374.9MiB/174.00s] Loading from cache[374.9MiB/174.00s]
[374.9MiB/174.00s]  Extracting archive[374.9MiB/174.23s]   - Installing phpunit/phpunit-mock-objects (6.1.2): [374.9MiB/174.23s] Loading from cache[374.9MiB/174.23s]
[374.9MiB/174.23s]  Extracting archive[374.9MiB/174.55s]   - Installing codeception/stub (1.0.4): [374.9MiB/174.56s] Loading from cache[374.9MiB/174.56s]
[374.9MiB/174.56s]  Extracting archive[374.9MiB/174.80s]   - Installing sebastian/diff (3.0.2): [374.9MiB/174.80s] Loading from cache[374.9MiB/174.80s]
[374.9MiB/174.80s]  Extracting archive[374.9MiB/175.07s]   - Installing sebastian/comparator (3.0.2): [374.9MiB/175.07s] Loading from cache[374.9MiB/175.07s]
[374.9MiB/175.07s]  Extracting archive[374.9MiB/175.33s]   - Installing theseer/tokenizer (1.1.3): [374.9MiB/175.33s] Loading from cache[374.9MiB/175.33s]

The run before

 Problem 1
    - Installation request for codeception/codeception 2.4.0 -> satisfiable by codeception/codeception[2.4.0].
    - Conclusion: remove symfony/finder v5.0.8
    - Conclusion: don't install symfony/finder v5.0.8
    - codeception/codeception 2.4.0 requires symfony/finder >=2.7 <5.0 -> satisfiable by symfony/finder[v2.7.0, v2.7.1, v2.7.10, v2.7.11, v2.7.12, v2.7.13, v2.7.14, v2.7.15, v2.7.16, v2.7.17, v2.7.18, v2.7.19, v2.7.2, v2.7.20, v2.7.21, v2.7.22, v2.7.23, v2.7.24, v2.7.25, v2.7.26, v2.7.27, v2.7.28, v2.7.29, v2.7.3, v2.7.30, v2.7.31, v2.7.32, v2.7.33, v2.7.34, v2.7.35, v2.7.36, v2.7.37, v2.7.38, v2.7.39, v2.7.4, v2.7.40, v2.7.41, v2.7.42, v2.7.43, v2.7.44, v2.7.45, v2.7.46, v2.7.47, v2.7.48, v2.7.49, v2.7.5, v2.7.50, v2.7.51, v2.7.6, v2.7.7, v2.7.8, v2.7.9, v2.8.0, v2.8.1, v2.8.10, v2.8.11, v2.8.12, v2.8.13, v2.8.14, v2.8.15, v2.8.16, v2.8.17, v2.8.18, v2.8.19, v2.8.2, v2.8.20, v2.8.21, v2.8.22, v2.8.23, v2.8.24, v2.8.25, v2.8.26, v2.8.27, v2.8.28, v2.8.29, v2.8.3, v2.8.30, v2.8.31, v2.8.32, v2.8.33, v2.8.34, v2.8.35, v2.8.36, v2.8.37, v2.8.38, v2.8.39, v2.8.4, v2.8.40, v2.8.41, v2.8.42, v2.8.43, v2.8.44, v2.8.45, v2.8.46, v2.8.47, v2.8.48, v2.8.49, v2.8.5, v2.8.50, v2.8.52, v2.8.6, v2.8.7, v2.8.8, v2.8.9, v3.0.0, v3.0.1, v3.0.2, v3.0.3, v3.0.4, v3.0.5, v3.0.6, v3.0.7, v3.0.8, v3.0.9, v3.1.0, v3.1.1, v3.1.10, v3.1.2, v3.1.3, v3.1.4, v3.1.5, v3.1.6, v3.1.7, v3.1.8, v3.1.9, v3.2.0, v3.2.1, v3.2.10, v3.2.11, v3.2.12, v3.2.13, v3.2.14, v3.2.2, v3.2.3, v3.2.4, v3.2.5, v3.2.6, v3.2.7, v3.2.8, v3.2.9, v3.3.0, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.14, v3.3.15, v3.3.16, v3.3.17, v3.3.18, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0, v3.4.1, v3.4.10, v3.4.11, v3.4.12, v3.4.13, v3.4.14, v3.4.15, v3.4.16, v3.4.17, v3.4.18, v3.4.19, v3.4.2, v3.4.20, v3.4.21, v3.4.22, v3.4.23, v3.4.24, v3.4.25, v3.4.26, v3.4.27, v3.4.28, v3.4.29, v3.4.3, v3.4.30, v3.4.31, v3.4.32, v3.4.33, v3.4.34, v3.4.35, v3.4.36, v3.4.37, v3.4.38, v3.4.39, v3.4.4, v3.4.40, v3.4.5, v3.4.6, v3.4.7, v3.4.8, v3.4.9, v4.0.0, v4.0.1, v4.0.10, v4.0.11, v4.0.12, v4.0.13, v4.0.14, v4.0.15, v4.0.2, v4.0.3, v4.0.4, v4.0.5, v4.0.6, v4.0.7, v4.0.8, v4.0.9, v4.1.0, v4.1.1, v4.1.10, v4.1.11, v4.1.12, v4.1.2, v4.1.3, v4.1.4, v4.1.5, v4.1.6, v4.1.7, v4.1.8, v4.1.9, v4.2.0, v4.2.1, v4.2.10, v4.2.11, v4.2.12, v4.2.2, v4.2.3, v4.2.4, v4.2.5, v4.2.6, v4.2.7, v4.2.8, v4.2.9, v4.3.0, v4.3.1, v4.3.10, v4.3.11, v4.3.2, v4.3.3, v4.3.4, v4.3.5, v4.3.6, v4.3.7, v4.3.8, v4.3.9, v4.4.0, v4.4.1, v4.4.2, v4.4.3, v4.4.4, v4.4.5, v4.4.6, v4.4.7, v4.4.8].
    - Can only install one of: symfony/finder[v2.7.0, v5.0.8].
    - Can only install one of: symfony/finder[v2.7.1, v5.0.8].
    - Can only install one of: symfony/finder[v2.7.10, v5.0.8].
    - Can only install one of: symfony/finder[v2.7.11, v5.0.8].

2) YES Btw, prestissimo as I mentioned was already applied and it seemed to help, as on another very fast computer which has much faster internet altogether without codeception, installation took 5 times more, 518 seconds, while perhaps due to prestissimo or other advices here, it took 110 seconds.

composer global require hirak/prestissimo

3) YES Windows is slow, and so are virtualized folders from Windows to Linux. Running outside the shared folder inside Linux seemed to speed it up about twice. Though it could be due cache.

4) NO

    "process-timeout": 1800,

is per single process like git checkout and did not seem to help at all even set to 10s, as it was already considerably huge. It perhaps helps only when there is a total outage of some service.

5) YES installing with a vendor folder removed or empty=freshly seems to be considerably faster (about 1 minute and more), than adding to the vendor files and other packages existing in it

6) YES seems to be slower on Ubuntu18 apache2 without xdebug own image, than on Debian10 php-fpm even with xdebug at Yii2-starter-kit , for some reason about twice slower , cat /etc/*-release to find out the Linux distribution

7) NO php -ddefault_socket_timeout=1 /usr/local/bin/composer --verbose --profile install mentioned in here did not seem to help Slow updating of composer dependencies, despite --prefer-dist flag nor there mentioned IP v6 v v4 protocol Though it could be due cache.

8) NO Installing zip doesn't seem to help, PHP installation had zip preinstalled, it still complained not being there until were installed as Linux packages but it made process in a single simulation slower by 100 seconds from 650 to 750 seconds. Same environmental conditions. As there is no 'unzip' command installed zip files are being unpacked using the PHP zip extension https://stackoverflow.com/a/51208804/3419535 testing on cacheless conditions --no-cache

9) YES remove "minimum-stability ": "dev",

10) YES use prefer-dist composer require robmorgan/phinx:@dev --prefer-dist -vvv --profile (using a require command as an example, as using partial require commands as mentioned very first above, instead of a full installation via an install command, seems to be one of the most significant speedups, plus requiring @dev- as along the previous points when minimum-stability: dev not applied generically to all dependencies seems to be harmless using on per case(dependency) basis)

How is this related to the given question? Accoirding to the problem description, there is not a single dependency listed in the OPs problem — Nico Haase, Aug 10 '20 at 10:35
The problem should be addressed generically, I tried to summarize all that helped me, and added some other solutions from elsewhere.Not always only for what the asker asks for, here come thousands of other users scenarios.Majority of responses are generic. Composer require is basically just a subpart of composer install. Just because I used also a word/command 'require' in the response, does not mean it does not apply also to install,but if you wish I can remove that word.'There is not a single dependency listed', but how it changes anything, composer install is about nothing but dependencies. — FantomX1, Aug 10 '20 at 10:47
I went from 1 point to -1 just a few mins after because I replied to you, maybe because you voted me up previously. Tell me that the chosen answer prestistimo or using ipv 6 or disabling xdebug is not generic too and do not apply to a concrete composer require command. I apologize for a few haste edits but I use it also as a personal wiki, and I did not even list a concrete depedency name, but will adjust it. If you dont like I did a typo, mention that, but not being generic doesnt make sense. I used a 'require' command as a reference, as using 'require' is one of the solutions itself. — FantomX1, Aug 10 '20 at 10:56
The OP asked why Composer is slow **with zero dependencies** - even if your list of stuff might help in many other situations, I see no connection to the given question — Nico Haase, Aug 10 '20 at 11:22
You are correct regards that but I either overlooked that or wondered if the user did not use it just for the mere exaggeration of the topic to distance from anybody thinking a particular dependency could be the cause. Somehow when solving it I stumble upon this question from google all the time, maybe also because it is the most popular/most answers regards this topic. And also because the headlines is very generic `Why is php composer so slow`. — FantomX1, Aug 10 '20 at 11:29
You know like sometimes is important also how the community forms the question, the guy can be a one-question guy. You say we should focus on the details what the OP asks,though many moderators explicitly require to be generic. But you say he wanted an empty dependency list,I wonder how the chosen answer with 400 votes using prestissimo paralel downloading benefits an empty dependency list. Or the question with 100 votes. Same with other answers ips,timeouts.It might be not the most proper way, but that's how huge stackoverflow behaves with popular questions.I read between lines of prestisimo. — FantomX1, Aug 10 '20 at 11:34
Well, the OP has selected an answer (XDebug should not be enabled) and wrote that the problem was solved after having disabled XDebug — Nico Haase, Aug 10 '20 at 11:35
You are right, however that reply is becoming outdated, my comment about that got thrice upvoted. Plus ten time more 365 - people/developers voted for the prestissimo reply, which is unrelated to en empty list. Just saying, the community subconsciously or not want this question to evolve into/answer a different(generic) question, of the composer being slow generally then imo. He asked for an empty list, but in practice solving an issue of an empty list on daily basis is just ludicrous if not used mainly for description. So this question should not have become that popular but other. — FantomX1, Aug 10 '20 at 11:40
Prestissimo helps even with empty require list - some files are downloaded by composer regardless of dependencies list, so parallel download will help here too. — rob006, Aug 10 '20 at 11:44
If it's the case - seems reasonable, then beg my pardon, though I am still not sure the reply is voted for an empty list, and you can delete these my comments if you want. Thanks — FantomX1, Aug 10 '20 at 11:45
This answer helped me, I had this problem for almost three days, you just have to increase the composer timeout, that's it — majid mohammadian, Jun 26 '22 at 09:16

lwin moe hein · Answer 8 · 2021-06-26T08:19:34.447

I found another possible solution , the problem is lack of cUrl extension in your environment.So please follow these steps

Firstly , check if you have accesss to

packagist.org with ping packagist.org.If you got reply back from the server , you are ready for the next step.
Check if cUrl extension exists with composer diagnose , for me I got these results which says I don't have cUrl extension ,so it may reduce performance during downloading things
install curl according to your environment's php version ,mine was 8 ,so sudo apt-get install php8.0-curl worked for me
after installing cUrl , please check if it was installed with again composer diagnose, and I got these results,which describes cUrl version.
That solved my problem with composer slowing down when installing packages.

score 1 · Answer 9 · edited Jul 10 '20 at 19:19

1

In my case, the composer version i was running backdated. After updated the composer version itself the problem was gone.

To update the composer version run

composer self-update

and then require the composer package and you're done.

composer require "<package-name>"

edited Jul 10 '20 at 19:19

dbf

3,278
1
24
34

answered Jan 31 '20 at 02:27

sh6210

4,190
1
37
27

sudo ? root ? why ? – Mohamed Elbahja Jun 30 '20 at 22:30
sorry brother, add sudo if you've permission issues. – sh6210 Jul 01 '20 at 04:42
or should you fix file mode and owner/group permissions? rather than just running SUDO! without knowing what that means? definitely not a FIX. – Mohamed Elbahja Jul 02 '20 at 00:37
of course, you can fix the owner/group permission issue by running the "chown" command, but you can do this in one go. My main intension was to show the solution in the simplest way from my point of view. However, I'm sorry if my words don't make any sense to you. – sh6210 Jul 02 '20 at 12:46
@sh6210 Do not encourage to use sudo when using composer. Assuming there 'might' a `permission` problem is prejudice. – dbf Jul 10 '20 at 19:20

score 0 · Answer 10 · edited Oct 25 '19 at 14:36

0

If any of the previous answers don't work, check if your firewall allows for TCP_OUT on port 9418.

My firewall security was too sharp. This caused Composer to take so long, I never got any timeout or indication the port was blocked.

edited Oct 25 '19 at 14:36

Peter Mortensen

30,738
21
105
131

answered Feb 16 '18 at 15:57

gidomanders

465
5
16

score 0 · Answer 11 · answered Aug 02 '20 at 18:21

0

Mine was slow when downloading json files because of the antivirus. Some antiviruses scan all web traffic and it may be slow at analyzing json files. Try disabling your AV while running composer.

answered Aug 02 '20 at 18:21

Dima L.

3,443
33
30

score 0 · Answer 12 · answered Sep 23 '20 at 04:55

0

step 1

$ composer self-update

step 2

$ composer clear-cache

step 3

$ composer update

answered Sep 23 '20 at 04:55

Yevgeniy Afanasyev

37,872
26
173
191

score 0 · Answer 13 · answered Jul 28 '22 at 23:24

0

I had 2 PHPStorm windows open on 2 different projects, the first project ran fast and the second was slow for composer install and for composer start, I left it on all day to do install. A powershell window had the same issue. When I closed the first project composer start ran well in the second project.

answered Jul 28 '22 at 23:24

Aryeh Baker

1
1

As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Jul 30 '22 at 12:53

score 0 · Answer 14 · answered Mar 07 '23 at 19:02

The accepted answer is right about disabling XDebug, but doesn't elaborate on how to do so. For anyone like me who came here trying to speed up the composer install on their GitHub Actions CI/CD workflows, disabling xdebug and similar debugging tools while setting up PHP can result in a significant decrease in build time and usage.

GitHub's documentation for the Ubuntu 22.04 Github Actions runner states that Xdebug is enabled by default, and the documentation of Shivam Mathur's Setup PHP action also makes mention of this:

Note: Xdebug is enabled by default on Ubuntu GitHub Actions images, so if you are not using it in your workflow it is recommended to disable it as that will have a positive impact on your PHP performance. Please refer to the disable coverage section for details.

It recommends disabling it by adding coverage: none to your GitHub Actions workflows:

- name: Setup PHP
  uses: shivammathur/setup-php@v2
    with:
    php-version: 8.1
    coverage: none        # Add this
    extensions: :xdebug   # OR add this to only disable XDebug - note the colon
- name: Run Composer install
  run: composer install -o -q --no-ansi --no-interaction --no-scripts --no-progress --prefer-dist

However, bear in mind that if you make use of GitHub Actions' advanced debug logging or plan to in the future, XDebug at least will probably need to be re-enabled for it.

score -1 · Answer 15 · answered Jul 21 '20 at 12:02

-1

Best way to find out is running composer update/install with verbosity. composer {install/update} -vvv. Using the flag -h may help you in the future

answered Jul 21 '20 at 12:02

Edu

1

Please share an explanation for that. The OP is running the tests using a completely empty list of dependencies – Nico Haase Aug 10 '20 at 10:36

score -1 · Answer 16 · answered Aug 17 '20 at 20:28

-1

In case, If you have deleted your composer.lock file, and then gone for composer install it gets too slow to download dependencies. If this is the case, use composer update command and then it may help you or others.

answered Aug 17 '20 at 20:28

NadZ

1,024
9
10

Why is PHP Composer so slow?

16 Answers16

Linked