15

Things I've tried:

  • Removing everything except for Laravel (version 4.2.*) - This completes but still hangs for around 5 minutes
  • Updating composer
  • Removing /vendor
  • Doing clean Laravel 4.2 install (hangs around 3 minutes)
  • Doing clean Laravel 5 install (doesn't hang at all)
  • Turning off xdebug completely (doesn't seem to make a difference)

With all my packages, I've seen composer complete but only when I left it running overnight. I can't deploy to forge at all because it times out! This only started happening two or so weeks ago.

Sabrina Leggett
  • 9,079
  • 7
  • 47
  • 50
  • 2
    `Turning off xdebug completely (doesn't seem to make a difference)` - This should make a **huge** difference, especially on machines without an SSD, or without a high-end Intel chip, or both. Are you *sure* it was turned off? I've seen this issue before on another one of my colleagues development machine, where composer would take hours to do a simple update. The issue ended up being a corrupted composer installation. Wiping the system of the composer artifacts and re-installing worked great. – Ohgodwhy Jun 14 '16 at 17:23
  • 1
    OK, yes, it did make a big difference (had turned it off in wrong php.ini), but it's still slow enough to time out my forge server. The bottom line is when something goes from taking 10 minutes to 10 hours (even with xdebug enabled), there's something bigger going on. – Sabrina Leggett Jun 24 '16 at 17:01
  • 1
    I don't disagree with you whatsoever. I think there's other things going on here, maybe there's an issue with DNS resolution, or a Firewall issue. Can you `strace /usr/bin/composer` and see what's happening while performing `composer update`? *sidenote* strace will dump ALOT of stuff out, so it's kind of a needle in the haystack, but it's definitely useful. There might be something better to debug this, however. I did also find a tip to `composer config --global repo.packagist composer https://packagist.org` which requires the setup to use HTTPS and seemed to fix the issue for others. – Ohgodwhy Jun 24 '16 at 18:46
  • 1
    It happens on all of our dev environments, even with a completely new 4.2 install. I'm almost sure it's due to Laravel 4.2 dependencies because 5.2 doesn't hang at all at this point. And I switch to https earlier while trying to debug, might have helped but benchmarks are with that already done. – Sabrina Leggett Jun 27 '16 at 14:29
  • Can I see your `composer.json` so I can try to install it locally? We maintain 4.2 LTS stacks and don't have this problem. – Ohgodwhy Jun 27 '16 at 17:42
  • https://jsfiddle.net/n10tvgcw/ – Sabrina Leggett Jun 27 '16 at 21:10
  • Same thing happens with 4.2.* and 4.2. And, they complete. I can just tell that they hang for a minute or two on "Resolving Dependencies Through SAT" where 5 doesn't at all. And, nothing we did triggered this to happen, so I just have to think it's something was updated with a dependency that doesn't place nice with the other packages... – Sabrina Leggett Jun 27 '16 at 21:18
  • @SabrinaGelbart did you found a solution to this? i am also going nuts with the slowness of composer. – Luis Lopes Dec 15 '16 at 17:41
  • Yes, kinda - 1) if you're not already you can run 'composer update' on one machine and then commit your lock file then run 'composer install' on each other machine 2) declare versions as explicitly as possible. – Sabrina Leggett Dec 15 '16 at 19:37

1 Answers1

2

For all looking for an answer...here's what helped increase performance:

  1. Commit composer.lock: if you're not doing this already you can run 'composer update' on one machine and then commit your lock file then run 'composer install' on each other machine. This saved our deployment process!
  2. Generally declare versions as explicitly as possible.

and/or

  1. update your Laravel version!
Sabrina Leggett
  • 9,079
  • 7
  • 47
  • 50
  • 1
    Didn't actually solved the issue, but made me remember about the composer.lock file, which I only deleted and the problem was solved. – emerino Jul 28 '17 at 05:25