Langsame Aktualisierung der Composer-Abhängigkeiten trotz --prefer-dist-Flag

73

Warum dauert es bis zu zwei Minuten, bis meine Composer-Abhängigkeiten aktualisiert sind, auch wenn keine Änderungen vorgenommen wurden?

Ein beliebter Vorschlag ist das Anhängen der --prefer-distFlagge:

php composer.phar update --prefer-dist

Aber das macht in meinem Fall keinen Unterschied. Unten ist meine composer.json-Datei - fehlt mir etwas Offensichtliches?

{
    "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"
        }
    }
}
php  symfony  composer-php 
— Jonathan
quelle
2
Haben Sie versucht, den Befehl -vvv --profilewie in meiner Antwort vorgeschlagen auszuführen? Welche Operationen dauern so lange? Hattest du xdebug in php-cli aktiviert?
— Nicolai Fröhlich

Antworten:

114

Dieses Problem hängt häufig damit zusammen, dass xdebug in Ihre CLI-Umgebung geladen wird. (Es spielt keine Rolle, ob xdebug aktiviert ist oder nicht.)

Sie können mit einem der folgenden Befehle überprüfen, ob xdebug aktiviert ist.

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

Weitere Informationen darüber, welche Vorgänge so lange dauern, erhalten Sie, indem Sie maximale Ausführlichkeit und Profilinformationen aktivieren. (Ersetzen Sie die Installation durch ein Update, wenn Sie die Pakete aktualisieren.)

composer install --prefer-dist -vvv --profile
— Nicolai Fröhlich
quelle
36
Ich habe xdebug nicht mit meinem PHP installiert und Composer läuft sehr langsam.
— Gustavo Straube
2
Mit PHP 5.3.10 gingen eine schnelle Verbindung, 6 Kerne, ein SSD-Laufwerk, viel Speicher und 4 zusätzliche "Anforderungen" in einem Composer.json von Symfony composer updatevon 58 auf 46 Sekunden. : /
— bksunday
Dies ist kein Problem mit bower (unterstützt von Twitter) oder npm (unterstützt von joyent), daher vermute ich, dass dies ein Problem beim Laden des Composer-Servers ist.
— Michael J. Calkins
1
XDebug in der Befehlszeile wird zum Erstellen von Codeabdeckungsstatistiken mit PHPUnit benötigt.
— Sven
1
Was --prefer-distmacht genau?
— Crmpicco
28

Faktoren, die Composer verlangsamen können:

  • Wie bereits erwähnt, xdebugkann dies die Leistung von Composer beeinträchtigen. Das Laufen composer diagnosewarnt Sie auch davor.

  • Laufen updatestatt install. Die Leute rennen zu oft einfach updateständig. Dadurch durchläuft Composer den gesamten Prozess der Abhängigkeitsauflösung, unabhängig davon, ob sich etwas geändert hat oder nicht. Beim Ausführen installübernimmt Composer die Anforderungen direkt aus Ihrer .lock-Datei und überspringt den Prozess zur Auflösung von Abhängigkeiten. Sie sollten nur updatewährend des Entwicklungslebenszyklus Ihrer Anwendung ausgeführt werden. Und selbst dann muss man normalerweise nicht täglich laufen.

  • Wenn Sie eine bestimmte Abhängigkeit haben, die Sie häufig selbst aktualisieren, können Sie versuchen, den Prozess zu vereinfachen, indem Sie composer update vendor/package --with-dependenciesstattdessen ausführen.

  • Einstellung minimum-stabilityauf dev. Dies erweitert die Möglichkeiten, die der Abhängigkeitsauflöser berücksichtigen muss, erheblich. Sie sollten den Wert fast nie senken minimum-stability, es devsei denn, Sie haben absolut keine andere Wahl. Suchen Sie nach Alternativen, z. B. vorübergehend mit einem Inline- @devFlag.

— Alkohol
quelle
1
Ihr Vorschlag zur Verwendung hat installmein Problem gelöst. Vielen Dank !
— Realtebo
5

Das Problem scheint behoben zu sein, aber dies könnte jemandem helfen.

Jedes Mal, wenn ich die Installation oder Aktualisierung von Composer ausgeführt habe, dauerte es mehr als 10 Sekunden, um die Datei https://packagist.org/packages.json abzurufen . Schließlich stellte ich fest, dass das Problem mit IPv6 zusammenhängt, da das Abrufen von Dateien von IPv4-Sites weniger als eine Sekunde dauerte.
Das Problem ist, dass mein ISP IPv6 nicht unterstützt, ich es jedoch in meinen Ethernet-Eigenschaften aktiviert habe. Nachdem ich Internet Protocol Version 6 (TCP/IPv6)meine Netzwerkeinstellungen deaktiviert habe, haben sich die Installations- / Aktualisierungsgeschwindigkeiten drastisch verbessert (von mehr als 200 Sekunden auf 10 Sekunden gesunken).

— Rai
quelle
2
Die beste Antwort, die ich für dieses Problem gefunden habe, besteht darin, den Befehl php zu aliasen und das Socket-Timeout auf etwas Lächerliches zu setzen. alias php="php -d default_socket_timeout=1 -d xdebug.remote_enable=0"
— Alex Barker
@AlexBarker danke für den Vorschlag, jedoch nur zu bemerken, schien in meinem Fall nicht zu helfen, -ddefault_socket_timeout = 10 Ergebnis, 308 Sekunden, -ddefault_socket_timeout = 100 Ergebnis 309 Sekunden, noch das IP v6 und v4 Protokoll
— FantomX1
3

Sie verwenden ein privates Repository. Dadurch kann die komprimierte Version der von Ihnen angegebenen Version nicht heruntergeladen werden, das Repository muss jedoch geklont werden. Außerdem muss möglicherweise das gesamte Repository gescannt werden, um die erforderliche Version zu finden.

Sie sollten prüfen, ob die Verwendung von Satis eine Option ist. Auf diese Weise können Sie ZIPs Ihrer eigenen Software vorbereiten und herunterladen, genau wie die auf Github gehosteten Dinge (die eine API dafür haben, die von Composer verwendet wird, um das Herunterladen von ZIPs zu ermöglichen, auch wenn diese nicht explizit vorbereitet sind).

— Sven
quelle
3

Ich hatte dieses Problem beim Ausführen von Symfony2 auf einer VM mit wenig Arbeitsspeicher. Ich habe den Arbeitsspeicher der Maschine vergrößert und er hat sich drastisch verbessert. Sie können den Speicher Ihres Systems überprüfen und prüfen, ob er aktualisiert werden kann.

— John Sampson
quelle
Dies war die Verwendung des Standard-Vagrant-Speichers von 384 MB, eine Erhöhung auf 1 GB war ausreichend. Es stellte sich heraus, dass der Komponist einen Höchststand von 456 MB erreichte
— Aren
2

Ich hatte das gleiche Problem mit composer update, ich habe den Composer selbst auf die neueste Version aktualisiert composer selfupdateund jetzt ist die Geschwindigkeit akzeptabel.

— ako
quelle
0

In der Tat wird xdebug die Dinge sicherlich verlangsamen. Die Deinstallation von xdebug ist jedoch nicht ideal. Eine gute Option ist es, HHVM zu verwenden und es als Komponisten einzusetzen.

Die Installation von HHVM ist ziemlich schmerzlos und HHVM selbst ist viel schneller als PHP5. Es ist ein doppelter Gewinn - YMMV, aber ich habe eine fast 5-fache Geschwindigkeitssteigerung (zugegebenermaßen auf dem Augapfelprüfstand) in der Komponistenverwendung erhalten, die ich erhalten würde, selbst wenn xdebug nicht auf dem Bild wäre.

Wenn Sie unter OS X arbeiten, kann dieser Link hilfreich sein (Blog-Artikel, den ich zu diesem Thema geschrieben habe):

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

— Saeven
quelle
0

Überprüfen Sie, ob zipund unzipinstalliert sind. Wenn sie fehlen, klont Composer das Repo, anstatt eine komprimierte Version herunterzuladen.

— Stian S.
quelle
Vielen Dank, es scheint logisch, da sich der Komponist auch darüber beschwert hat As there is no 'unzip' command installed zip files are being unpacked using the PHP zip extension., es mit installierter Zip-Bibliothek auszuführen, den gleichen Prozess und die gleichen Bedingungen - es waren 750 Sekunden, ohne Bibliotheken 650 Sekunden, nur eine Simulation. Abgesehen davon, dass in meiner Installation PHP-Zip unabhängig davon vorinstalliert war, dass Linux Zip- und Unzip-Pakete nicht installiert wurden, beschwerte sich Composer dennoch, dass es nicht vorhanden war, bis es als Linux-Bibliotheken installiert wurde.
— FantomX1
0

MEIN LÖSUNGSFENSTER 10 x 64 Bit WAMP-Benutzer mit Laravel, nach wochenlangem langsamen Composer-Update und Composer-Bedarf

Sie benötigen eine Sache namens cacert.pem

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

Fügen Sie diese Datei dann in Ihr Wamp-Hauptverzeichnis C: \ wamp64 \ cacert.pem ein

Öffnen Sie dann auf der Registerkarte Suche nach php.ini alle Dateien mit diesem Namen in sublime oder einem beliebigen Texteditor

Suchen Sie eine Zeile mit dem Namen curl.cainfo und openssl.cafile

Legen Sie Ihren Weg in diese Datei - siehe das Beispiel in meinem Fall:

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

und

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

Tun Sie dies für alle php.ini-Dateien, die Sie zuvor durchsucht haben, in allen Dateien!

OKAY RESTART SERVER, die für mich arbeiten, hoffe für Sie Ich wünschte, jemand zuvor würde diesen Kommentar abgeben! Ich würde also keine 2 Wochen damit verbringen, das Problem zu beheben

auch anrufen

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

Dadurch wird die Verbindung auf https auch ausgeführt

composer install --prefer-dist -vvv --profile
— ivn
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.