Медленное обновление зависимостей композитора, несмотря на флаг --prefer-dist

почему обновление зависимостей моего композитора занимает до двух минут, даже если изменений не было?

популярное предложение-добавить --prefer-dist флаг, который я добавил к моей команде:

php composer.phar update --prefer-dist

но это не имеет никакого значения. Ниже мой композитор.JSON-файл - я сделал что-то глупое?

{
    "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": [
            "SensioBundleDistributionBundleComposerScriptHandler::buildBootstrap",
            "SensioBundleDistributionBundleComposerScriptHandler::clearCache",
            "SensioBundleDistributionBundleComposerScriptHandler::installAssets",
            "SensioBundleDistributionBundleComposerScriptHandler::installRequirementsFile"
        ],
        "post-update-cmd": [
            "SensioBundleDistributionBundleComposerScriptHandler::buildBootstrap",
            "SensioBundleDistributionBundleComposerScriptHandler::clearCache",
            "SensioBundleDistributionBundleComposerScriptHandler::installAssets",
            "SensioBundleDistributionBundleComposerScriptHandler::installRequirementsFile"
        ]
    },
    "config": {
        "bin-dir": "bin"
    },
    "minimum-stability": "dev",
    "extra": {
        "symfony-app-dir": "app",
        "symfony-web-dir": "web",
        "branch-alias": {
            "dev-master": "2.3-dev"
        }
    }
}
8 51
symfony php composer-php

8 ответов:

эта проблема часто связана с xdebug lodaed (не имеет значения, включен или нет) в вашей среде CLI.

вы можете проверить, включен ли xdebug для CLI с помощью:

// unix
php -m | grep xdebug
// windows
php -m | findstr xdebug

дополнительную информацию о том, какие операции занимают так много времени, можно получить, включив максимальную детализацию и информацию о профилировании:

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

или

composer update --prefer-dist -vvv --profile
86

факторы, которые могут замедлить композитор:

  • как указано,xdebug может повлиять на производительность композитор. Работает composer diagnose также предупредит вас об этом.

  • под управлением update вместо install. Люди слишком часто просто бегут update постоянно. Это заставляет композитора пройти весь процесс разрешения зависимостей, независимо от того, изменилось ли что-либо. Когда вы бежите install, композитор принимает требования прямо с вашего .заблокируйте файл, пропустив процесс разрешения зависимостей. Вы должны только запустить update во время жизненного цикла разработки вашего приложения. И даже тогда, это не то, что вы должны работать ежедневно, как правило.

  • если у вас есть определенная зависимость, которую вы часто обновляете сами, вы можете попробовать упростить процесс, запустив composer update vendor/package --with-dependencies вместо.

  • задание minimum-stability до dev. Это значительно расширяет количество возможности, которые должен учитывать преобразователь зависимостей. Вы почти никогда не должны опускать minimum-stability до dev если у вас нет абсолютно никакого другого выбора. Посмотрите на альтернативы, такие как временное использование inline @dev флаг.

18

У меня была эта проблема при запуске Symfony2 на виртуальной машине, которая имела низкую память. Я увеличил память машины, и она значительно улучшилась. Вы можете проверить память в своей системе и посмотреть, можно ли ее обновить.

3

похоже, проблема была решена, но это может кому-то помочь.

всякий раз, когда я запускал composer install или update, потребовалось более 10 секунд, чтобы просто получить https://packagist.org/packages.json файл. В конце концов я узнал, что проблема была связана с IPv6, так как извлечение файлов с сайтов IPv4 заняло меньше секунды.
Проблема в том, что мой интернет-провайдер не поддерживает IPv6, но я включил его в свойствах ethernet. После того, как я снял Internet Protocol Version 6 (TCP/IPv6) in мои сетевые настройки, скорость установки / обновления резко улучшилась (упала с 200+ секунд до 10)

3

вы используете частный репозиторий. Это не позволит загрузить заархивированную версию включенной версии, но необходимо клонировать репозиторий. Кроме того, для поиска требуемой версии может потребоваться сканирование всего репозитория.

вы должны проверить, является ли использование Satis опцией. Таким образом, вы можете подготовить молнии своего собственного программного обеспечения и загрузить его так же, как вещи, размещенные на Github (который имеет API для этого, который используется Composer для загрузки Молнии даже если они явно не готовы).

2

действительно, xdebug, безусловно, будет замедлять работу. Удаление xdebug не является идеальным, хотя. Хороший вариант-использовать HHVM и поставить его на службу композитора.

установка поведение довольно безболезненно, и поведение само по себе является гораздо более быстрым, чем в php5. Это двойная победа - YMMV, но я получил почти 5-кратное увеличение скорости (по общему признанию, на глазном яблоке) в использовании композитора, которое я получил бы, даже если бы xdebug не был на картинке.

Если вы находитесь на OS X, то эта ссылка может помочь (блог статью я написал по этому поводу):

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

1

у меня была такая же проблема с composer update, я обновил сам композитор до последней версии с помощью composer selfupdate и теперь это приемлемая скорость.

0

проверить, если zip и есть. Если они отсутствуют, Composer будет клонировать РЕПО вместо загрузки молнии выпуска.

0