Composer: Composer liest und schreibt Cache-Dateien sehr langsam

Sieht nach einem Umgebungsproblem aus, das nicht mit dem Composer zusammenhängt. Ich kann dem nichts weiter hinzufügen, ohne mehr über Ihr System-Setup zu wissen (Betriebssystem, Partitionen, Verwendung von VM ja/nein, alle symbolischen Links in Ihrem Pfad oder nicht, verschlüsseltes Home-Verzeichnis oder nicht usw.).

Fürs Protokoll, ich habe gerade Ihr composer.json auf einem von Westmere Xeon unterstützten virtuellen Server mit SSD ausprobiert:

[269.9MB/5.05s] Resolving dependencies through SAT
[271.3MB/5.35s] Dependency resolution completed in 0.297 seconds

Beachten Sie die 5 Sekunden, während das am anderen Ende der Skala schnell ist, sind Ihre 270 Sekunden definitiv ein lokales Problem.

Außerdem: Führen Sie die neueste Version von Composer auf PHP 7.x aus? Sie sollten sich darüber im Klaren sein, dass PHP 5.6 mit Xdebug auf einer alten Composer-Version allein schon mehr als 5-mal langsamer sein kann als ein neuerer Build, der Xdebug deaktiviert, auf PHP 7.1, das häufig 2- bis 3-mal schneller ist als PHP 5.6 in Bezug auf die Art der Operationen die während der Cache-Deserialisierung passieren.

@curry684 danke für den Vergleich. Ich verwende die Composer-Version 1.4.1 und die PHP-Version 7.0.15 .

@Alkohol Entschuldigung, ich hätte daran denken sollen, weitere Informationen hinzuzufügen. Das ist an:

• 2016 rMBP 13" Touchbar, 3,1 GHz Prozessor
• macOS Sierra 10.12.3
• 512 GB SSD, einzelne Partition
• Keine VM
• Symlinks im Pfad: _vielleicht_, siehe unten
• Kein verschlüsseltes Home-Verzeichnis (obwohl ich FileVault aktiviert habe)

Mein $PATH :

/Users/travis/.phpbrew/bin:/Users/travis/go/bin:/usr/local/opt/php70/bin:/usr/local/opt/coreutils/libexec/gnubin:/Users/travis/.yarn/bin:/Users/travis/bin:/Users/travis/.composer/vendor/bin:/Users/travis/dotfiles/bin:/usr/local:/usr/local/sbin:/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

Ich habe Symlinks in meinem Home-Verzeichnis, aber sie zeigen _auf_ ein Verzeichnis in meinem Pfad. Das (vielleicht?) Relevante:

bin -> /Users/travis/dotfiles/bin

Ich habe eine separate/neue Installation von Composer aus der Quelle versucht, indem ich den Anweisungen in CONTRIBUTING.md gefolgt bin , aber das hat im Wesentlichen identische Zeiten ergeben.

Irgendwelche anderen Vorschläge, wie man weiter debuggen kann?

Verschlüsselt FileVault standardmäßig nicht Ihr Home-Verzeichnis?

Ich glaube, das tut es, hatte aber den Eindruck, dass es die Leistung nicht beeinträchtigt, wenn es angemeldet ist. Ich schalte es jetzt testweise aus.

_Bearbeiten: Eine schnelle Suche zeigt, dass FileVault wahrscheinlich nicht der Übeltäter ist, aber ich werde es trotzdem testen._

Sie können auch versuchen, das Repository in ein Verzeichnis zu verschieben, das sich außerhalb eines vorhandenen Pfads befindet, z. B. /code .

Meinst du das Projekt, an dem ich arbeite, oder die Composer-Installation?

Das Projekt, an dem Sie arbeiten. Sie können auch versuchen, /composer zu erstellen und dann sicherzustellen, dass Ihre Umgebungsvariable COMPOSER_HOME auf /composer zeigt.

@tnorthcutt Besteht die Möglichkeit, dass Sie die Beispielanwendung in einem Containerdienst ausführen?

@davidjeddy Meinst du so etwas wie Docker? Wenn ja, nein.

Ok, neue Infos zu berichten. ICH:

1. FileVault deaktiviert
2. Composer aus der Quelle in /composer installiert
3. Setzen Sie COMPOSER_HOME auf /composer
4. In /composer /composer/composer global require franzl/studio -vvv --profile gelaufen
5. Lief '/composer/composer update -vvv --profile while in /composer (dieses Paket einfach, weil ich es mir kürzlich angesehen habe)

Ausgabe von 4: https://gist.github.com/tnorthcutt/6b88fb29713baf9d425b626afafb73aa (528,28 Sekunden)
Ausgabe von 5: https://gist.github.com/tnorthcutt/1db9a4cbdeac8edfb2183b3ebb17a953 (196,55 Sekunden)

Liege ich richtig, dass dies _sehr_ langsam erscheint?

Jetzt scheint es, dass ein Großteil der Langsamkeit beim Herunterladen von Dateien von Packagist liegt; andere melden ebenfalls Probleme .

Anekdaten:

Wenn ich wget https://packagist.org/p/provider-latest%242f333ec502b004ca61c6fb3bc4bc1190d623c76fe2ff036e7bd89effb214ca25.json , beträgt meine Geschwindigkeit 19,3 KB/s

Wenn ich wget https://gist.github.com/tnorthcutt/9cd436dda5a607cd994aaeff3d1ab318/raw/862e2ba6eb3e5fba571e4b7112929b2d12643a74/provider.json (dieselbe Datei) verwende, beträgt meine Geschwindigkeit 604 KB/s.

Ich habe ähnliche Verhältnisse bei Menschen an anderen geografischen Standorten bestätigt. Was mir seltsam erscheint, ist, dass meine Verbindung zu Packagist um eine Größenordnung langsamer ist als zu Github, und das gilt auch für andere - aber ihre liegen in der Größenordnung von ~ 900 KB / s von Packagist und ~ 3 MB / s von Github. Es ist also nicht so, dass ich gerade die mögliche Verbindungsgeschwindigkeit zu Packagist ausreize.

Ja, es scheint, als hätten wir zu Spitzenzeiten, wenn die USA zu arbeiten beginnen, eine gewisse Bandbreitenknappheit. An der Verbesserung der Dinge arbeiten. Wir melden uns später bei Ihnen.

OK, wir werden sehen, wie sich die Dinge entwickeln, aber wir haben jetzt einen Live-Spiegel in Nordamerika. Die DNS-Propagation sollte langsam einsetzen, also denke ich, dass wir in ein paar Stunden, wenn US an der Arbeit ist, die Situation etwas detaillierter beurteilen können. Bitte melden Sie jede Verrücktheit.

Ich bin mir nicht sicher warum, aber manchmal führt /composer/composer update -vvv --profile dazu, dass neue Dateien in den Cache heruntergeladen werden, und manchmal nicht. Wie auch immer, ich habe diesen Befehl gerade jetzt ausgeführt, und es dauerte 558,14 Sekunden, bis er ausgeführt wurde, ohne etwas herunterzuladen: https://gist.github.com/tnorthcutt/a9553be31e79af9e1cadeb59bc1e573e

Ich bin völlig verblüfft darüber, warum das Lesen und Schreiben von Dateien so lange dauert. Ich würde gerne in der Lage sein, dies mehr zu debuggen, aber ich bin mir im Moment nicht sicher, wie. Irgendwelche Hinweise wären sehr dankbar.

@tnorthcutt Ich sehe, dass Sie das Lade-Plugin Hirak \ Prestissimo \ Plugin dort verwenden, können Sie dasselbe ohne das Plugin profilieren? Können Sie uns auch sagen, zu welcher IP Ihr DNS packagist.org auflöst und wo Sie sich befinden?

Eine Frage ist, ob es heute besser läuft als gestern, aber angesichts der Tatsache, dass Sie in Australien zu sein scheinen, wird es wahrscheinlich nicht so viel helfen wie den Menschen in den USA und Umgebung.

Ich bin in Oklahoma, in den USA.

traceroute packagist.org :

traceroute to packagist.org (87.98.253.214), 64 hops max, 52 byte packets
 1  dsldevice (192.168.1.254)  7.653 ms  11.825 ms  12.931 ms
 2  108-220-130-1.lightspeed.okcbok.sbcglobal.net (108.220.130.1)  49.499 ms  29.246 ms  30.032 ms
 3  71.147.108.64 (71.147.108.64)  30.002 ms  53.982 ms  32.427 ms
 4  * * *
 5  12.83.71.73 (12.83.71.73)  400.389 ms
    12.83.71.77 (12.83.71.77)  409.175 ms
    12.83.71.73 (12.83.71.73)  436.222 ms
 6  gar26.dlstx.ip.att.net (12.123.16.85)  431.853 ms  462.154 ms  474.891 ms
 7  * * *
 8  * * *
 9  be100-155.nwk-5-a9.nj.us (198.27.73.29)  98.558 ms  67.636 ms  99.753 ms
10  be100-1298.ldn-5-a9.uk.eu (192.99.146.132)  177.426 ms  204.570 ms
    be100-1295.ldn-1-a9.uk.eu (192.99.146.126)  204.755 ms
11  be10-1194.gra-g2-a9.fr.eu (91.121.128.92)  248.548 ms
    be10-1193.gra-g1-a9.fr.eu (91.121.128.90)  237.393 ms
    be10-1194.gra-g2-a9.fr.eu (91.121.128.92)  205.076 ms
12  vl21.gra-g1-a75.fr.eu (213.251.128.43)  204.071 ms  143.825 ms *
13  be50-7.gra-3a-a9.fr.eu (37.187.231.88)  181.233 ms  248.780 ms
    be50-7.gra-3b-a9.fr.eu (37.187.231.92)  201.475 ms
14  eu.packagist.org (87.98.253.214)  244.092 ms *  230.853 ms

@tnorthcutt ok du wirst hoffentlich bessere ergebnisse bekommen sobald dein dns cache neu geladen ist, das ist das französische packagist.org mit dem du dich verbindest.

Sie können versuchen, packagist.org in Ihrer Hosts-Datei auf 144.217.203.53 fest zu codieren, um es jetzt auszuprobieren, aber bitte stellen Sie sicher, dass Sie es später wieder entfernen, da sich die IP ohne Vorwarnung ändern kann.

Verstanden, ich werde es hartcodiert versuchen.

Irgendwelche Ideen zu den super langsamen Lese- und Schreibvorgängen von Dateien? Ein Update dauert fast 10 Minuten ohne Downloads 😕

@tnorthcutt wie gesagt, bitte versuchen Sie es ohne das Plugin, da ich nicht sicher bin, ob es genau meldet, was lange dauert, wenn die Downloads parallel stattfinden.

@naderman oh Entschuldigung, ich wollte erwähnen, dass ich es ohne das versuche - es dauert nur eine Weile 😬

Das langsame Lesen/Schreiben im Cache ist höchstwahrscheinlich nur ein Eindruck, den Sie von der Ausgabe haben, da es nicht ausgegeben wird, wenn die CPU arbeitet.

@Seldaek Verstanden . Scheint Ihnen das eine normale Zeitspanne zu sein?

Keine 10min ist definitiv auf der langen Seite der Dinge. Ich untersuche andere Faktoren als das Netzwerk (was definitiv ein Problem war, und ich hoffe, dass sich die Dinge verbessern werden, aber es ist möglicherweise nicht die einzige Ursache für Sie).

@naderman hier ist eine Wiederholung ohne Prestissimo: https://gist.github.com/tnorthcutt/2f41f421198b88329c64a52d0730a8b1

Gesamtzeit 138,15 s, das ist also eine enorme Verbesserung. Ich habe auch gleich danach eine Traceroute erneut ausgeführt und drücke immer noch 87.98.253.214 .

@tnorthcutt TTL für diesen DNS-Eintrag war ein Tag, kann also einige Stunden dauern

Ich habe gerade mein DNS geleert und bekomme jetzt 144.217.203.53 .

Scheint die Download-Geschwindigkeit jedoch nicht drastisch zu verbessern (derzeit läuft composer udpate ). Zum Beispiel gibt mir wget http://packagist.org/p/provider-2015%2419f785235d2cb13e2b2aa2a23244e050b64cf79d7387d678b20088406c571053.json immer noch ~13KB/s, während ein wget zu einer ähnlich großen Datei bei Github ~1MB/s bekommt.

Gibt es neben den langsamen Netzwerkgeschwindigkeiten eine Möglichkeit, meine nur lokalen Probleme weiter zu diagnostizieren? Ich bin mir nicht sicher, wie ich vorgehen soll, da ich Composer neu installiert habe, ein neues COMPOSER_HOME -Set usw.

@tnorthcutt Ich sehe in dieser Protokolldatei per se keine rein lokalen Probleme mehr? Können Sie eine andere Traceroute senden?

traceroute to packagist.org (144.217.203.53), 64 hops max, 52 byte packets
 1  dsldevice (192.168.1.254)  8.286 ms  8.449 ms  4.865 ms
 2  108-220-130-1.lightspeed.okcbok.sbcglobal.net (108.220.130.1)  89.297 ms  28.015 ms  28.277 ms
 3  71.147.108.64 (71.147.108.64)  34.490 ms  32.461 ms  33.858 ms
 4  * * *
 5  12.83.71.77 (12.83.71.77)  28.156 ms
    12.83.71.73 (12.83.71.73)  32.521 ms
    12.83.71.77 (12.83.71.77)  31.109 ms
 6  gar26.dlstx.ip.att.net (12.123.16.85)  37.299 ms  41.726 ms  38.924 ms
 7  * * *
 8  * * *
 9  be100-104.nwk-1-a9.nj.us (192.99.146.253)  567.632 ms
    be100-155.nwk-5-a9.nj.us (198.27.73.29)  542.429 ms  555.572 ms
10  be10-1037.bhs-g1-a9.qc.ca (192.99.146.99)  515.780 ms  569.876 ms  547.976 ms
11  * vl21.bhs-g1-a75.qc.ca (198.27.73.63)  137.918 ms
    vl21.bhs-g2-a75-lo2.qc.ca (198.27.73.91)  189.143 ms
12  be50-5.bhs-3a-a9.qc.ca (198.27.73.92)  464.066 ms  418.524 ms
    be50-7.bhs-3b-a9.qc.ca (198.27.73.98)  98.177 ms
13  ca.packagist.org (144.217.203.53)  86.854 ms  129.686 ms  183.286 ms

Sie haben Recht, keine nur lokalen Probleme bei der letzten Ausführung: https://gist.github.com/tnorthcutt/538b77aa8bde471114686f074762a012

Mir fehlt vielleicht ein grundlegendes Verständnis dafür, wie Composer funktioniert, aber manchmal lädt es viele Dateien herunter (wie bei diesem Lauf) und manchmal lädt es fast nichts herunter. Ich _denke_ das Muster ist, dass bei Läufen, wenn nicht viel heruntergeladen wird, die lokalen Lese-/Schreibvorgänge sehr langsam sind. Das kann ich aber nicht mit Sicherheit sagen.

@tnorthcutt hat das Illuminate-Zeug aufgeräumt. Ich werde hier nicht zu sehr ins Detail gehen, aber das sollte die Dinge trotzdem weiter beschleunigen.

Bisher scheint alles gut zu laufen, also schließen Sie diese https://twitter.com/packagist/status/842441015839608833

@Seldaek danke! Mirror ist viel, viel schneller.

Bei mir ist es immer sehr langsam, ich habe versucht überall zu suchen ohne viel Erfolg. Ich kann nicht feststellen, was der Schuldige ist, der Download ist die meiste Zeit langsam, aber manchmal scheint es keine Netzwerkaktivität oder CPU zu sein, und Composer bleibt einfach dort.

Es ist normalerweise langsam, heute ist es super super langsam ... vielleicht ist es eine vorübergehende Sache.

-v hängt an Writing /Users/ariel/.composer/cache/repo/https---packagist.org/packages.json into cache , aber das darf nicht so lange dauern.

Ich verwende 1.4.2 und PHP 7.0.18, keinen Container, OSX 10.12.5, SSD-Laufwerk, FileVault aktiviert. Gibt es hier Hilfe?

@hanoii siehe https://github.com/composer/composer/issues/6342

Dieses Problem besteht für mich immer noch, und keines der in dieser Ausgabe angesprochenen Probleme löst mein Problem nicht.

Ja, Composer war heutzutage super super langsam :( was ist hier eigentlich passiert? Hier ist ein Protokoll, als ich versuchte, ein einzelnes Paket zu installieren:

[6.5MB/394.61s] Downloading https://packagist.org/p/provider-2013%241e6878bf2b5d94a5e3cb2e852c378b6e41db311b4a339875ab02c22dedf4a221.json
[ErrorException] zlib_decode(): data error

EDIT: egal, das war ein Verbindungsproblem. Ich habe meine Verbindung geändert und es funktioniert gut, obwohl es immer noch ein bisschen langsam ist.

gleiches Problem in der Docker-Architektur (PHP-Container 1 GB RAM und 4 Kerne)

@juanantoniomosq du auf OSX? Wenn dies der Fall ist, ist die Lese-/Schreibleistung der Datei ein Docker-Problem.
https://blog.docker.com/2017/05/user-guided-caching-in-docker-for-mac/ zum Beispiel.

@davidjeddy nein, Linux-Umgebung.

Ah, interessant; Was ist die Ausgabe von Traceroute?

Ich habe jetzt seit ein paar Wochen mit der Geschwindigkeit von Composer zu kämpfen. Zuerst dachte ich, es hätte etwas mit meiner Umgebung zu tun, aber heute hatte ich auch Geschwindigkeitsprobleme in einer ganz anderen Umgebung. Das Ausführen von Composer mit Docker oder das Ausführen auf einem Linux-Host macht keine Unterschiede in Bezug auf die Geschwindigkeit. Wenn ich composer update starte, liest es eine Menge Dateien aus dem Cache. Manchmal lädt es es herunter und schreibt es dann in den Cache-Ordner. Die Verarbeitung von etwa 10 Dateien dauert etwa 1 oder 2 Sekunden. Das summiert sich auf mindestens eine Minute. Ich habe ein Protokoll von composer update bereitgestellt, falls das hilfreich sein könnte.

https://gist.github.com/pascal08/c9cdfc476b09a468989e9b95f4831671

Mein Problem wurde mit dem neuesten Kernel von CentOS gelöst (vor der Verwendung des Elrepo-Kernels).

Langsamkeit für mich auf Docker
````
Composer erfordern zendframework/zend-inputfilter -vvv --profile

[7,7 MB/0,00 s] Composer-Repositories mit Paketinformationen werden geladen
[7,9 MB/0,01 s] Herunterladen von https://repo.packagist.org/packages.json
[7,9 MB/0,20 s] Schreiben von /root/.composer/cache/repo/https---repo.packagist.org/packages.json in den Cache
[8,0 MB/0,21 s] Abhängigkeiten aktualisieren (einschließlich require-dev)
[8,1 MB/0,21 s] Lesen von /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2013.json aus dem Cache
[12,1 MB/1,01 s] Lesen von /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2014.json aus dem Cache
[20,3 MB/4,37 s] Lesen von /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2015.json aus dem Cache
[33,3 MB/12,09 s] Lesen von /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2016.json aus dem Cache
[52,6 MB/25,94 s] Lesen von /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2017.json aus dem Cache
[69,9 MB/35,49 s] Lesen von /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2017-10.json aus dem Cache
[76,4 MB/40,08 s] Lesen von /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2018-01.json aus dem Cache
[91,4 MB/47,77 s] Lesen von /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2018-04.json aus dem Cache
[102,3 MB/56,47 s] Herunterladen von http://repo.packagist.org/p/provider-2018-07%24bd48a4a312894b4b8c944cab441fe479f3ce547c949cf6e4c22546ff6a399f90.json
[119,5 MB/62,95 s] Schreiben von /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2018-07.json in den Cache
[115,8 MB/63,43 s] Lesen von /root/.composer/cache/repo/https---repo.packagist.org/p-provider-archived.json aus dem Cache
[115,6 MB/63,70 s] Herunterladen von http://repo.packagist.org/p/provider-latest%2486b0f858d808d6a10b6f375c1e3842bfce12a7b84ca118737c1bf77bbcd42d4f.json
[122,7 MB/65,42 s] Schreiben von /root/.composer/cache/repo/https---repo.packagist.org/p-provider-latest.json in den Cache
.....
[448,1 MB/271,58 s] Speicherverbrauch: 448,11 MB (Spitze: 498,2 MB), Zeit: 271,58 s
````
Ich bin mir auch nicht sicher, wie viel Speicher Composer verbrauchen sollte, aber 500 MB klingen zu viel, um eine Abhängigkeit zu installieren.

Langsamkeit für mich auf Docker

composer require zendframework/zend-inputfilter -vvv --profile

[7.7MB/0.00s] Loading composer repositories with package information
[7.9MB/0.01s] Downloading https://repo.packagist.org/packages.json
[7.9MB/0.20s] Writing /root/.composer/cache/repo/https---repo.packagist.org/packages.json into cache
[8.0MB/0.21s] Updating dependencies (including require-dev)
[8.1MB/0.21s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2013.json from cache
[12.1MB/1.01s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2014.json from cache
[20.3MB/4.37s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2015.json from cache
[33.3MB/12.09s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2016.json from cache
[52.6MB/25.94s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2017.json from cache
[69.9MB/35.49s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2017-10.json from cache
[76.4MB/40.08s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2018-01.json from cache
[91.4MB/47.77s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2018-04.json from cache
[102.3MB/56.47s] Downloading http://repo.packagist.org/p/provider-2018-07%24bd48a4a312894b4b8c944cab441fe479f3ce547c949cf6e4c22546ff6a399f90.json
[119.5MB/62.95s] Writing /root/.composer/cache/repo/https---repo.packagist.org/p-provider-2018-07.json into cache
[115.8MB/63.43s] Reading /root/.composer/cache/repo/https---repo.packagist.org/p-provider-archived.json from cache
[115.6MB/63.70s] Downloading http://repo.packagist.org/p/provider-latest%2486b0f858d808d6a10b6f375c1e3842bfce12a7b84ca118737c1bf77bbcd42d4f.json
[122.7MB/65.42s] Writing /root/.composer/cache/repo/https---repo.packagist.org/p-provider-latest.json into cache
.....
[448.1MB/271.58s] Memory usage: 448.11MB (peak: 498.2MB), time: 271.58s

Ich bin mir auch nicht sicher, wie viel Speicher Composer verbrauchen sollte, aber 500 MB klingen zu viel, um eine Abhängigkeit zu installieren.

Kernel-Host-Problem wahrscheinlich ..

PC neu gestartet und Docker-Image jetzt neu erstellt
[330.7MB/6.22s] Memory usage: 330.71MB (peak: 383.52MB), time: 6.22s
also vielleicht hattest du recht

@juanantoniomosquera @svycka danke! Du rettest meinen Tag!
Gleiches Problem, PC neu starten und es funktioniert wieder gut.