Pourquoi le composeur php est-il si lent?
Pourquoi le compositeur est-il si lent alors que tout ce que je fais est d'initier un projet avec zéro dépendance? Voici les commandes que je lance:
composer init
composer install
Attendez 3 minutes (pas une exagération).
Tout ce que le compositeur doit faire est d’arriver dans un autochargeur et de créer /vendor, alors pourquoi cela prend-il si longtemps? D'ailleurs, pourquoi cette étape ne se produit-elle pas sur composer init?
Existe-t-il une option de configuration que je peux utiliser pour extraire un chargeur automatique et un fournisseur mis en cache sur init?
En outre, désactivez xdebug. Xdebug peut entraîner que Composer prenne quelques minutes même lors de l'exécution d'une commande aussi simple que composer --version.
Parce que le compositeur implémente par file_get_contents(). Cela n'a pas d'optimisations TCP, pas de Keep-Alive, pas de multiplexage ...
J'ai créé un plugin composer pour télécharger des paquets en parallèle.
https://packagist.org/packages/hirak/prestissimo
composer install devient 10 fois plus rapide.- Assurez-vous de disposer de la dernière version de Composer.
- Installez en mode commenté en ajoutant -vvv, par exemple
composer global require "squizlabs/php_codesniffer=*" -vvv - Si vous êtes capable de savoir où le compositeur est confronté à la lenteur, par exemple, le mien était bloqué pendant 5 minutes lors du téléchargement de packages. Il a fallu plus de 5 minutes pour télécharger un fichier de 20 Ko sur une connexion de 50 Mbps. C'était parce qu'il téléchargeait les paquets depuis packagist en utilisant http et non en https. Apporter ces modifications à la configuration a résolu mon problème:
composer config --global repo.packagist composer https://packagist.org
Pareil ici. Obtenez plus de détails avec "composer install --profile -vvv". Dans mon cas, le téléchargement de quelques fichiers JSON prend beaucoup de temps. Ils sont mis en cache sur mon serveur mais sont toujours téléchargés à chaque appel de mise à jour/d'installation de composer.
... 30 minutes plus tard ...
Cela ressemble à un problème de performance @ packagist.org. Maintenant, l’installation du compositeur s’exécute en moins de 2 secondes! Et les fichiers json téléchargés sont correctement mis en cache.
Sur Ubuntu Xenial 16.04 VPS, vous devez procéder comme suit:
Sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"
composer global require hirak/prestissimo
Je me heurtais à ce problème et cela me laissait aller à la courbe, car XDebug n’est installé nulle part sur ma machine. Il s’avère que c’était des échecs du mode d’adressage IPv6. Donc pour tester j'ai couru
curl --ipv4 'https://packagist.org/packages.json'
curl --ipv6 'https://packagist.org/packages.json'
IPv4 est passé, mais IPv6 a échoué. En fin de compte, vous devriez chercher à savoir pourquoi votre pile réseau ne la prend pas en charge, mais dans mon cas, j'ai décidé de privilégier le trafic IPv4 jusqu'à ce que je puisse résoudre ce problème. Sur CentOS, j'ai créé/modifié le fichier /etc/gai.conf et ajouté les éléments suivants:
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
Sur Ubuntu, vous pouvez également éditer ce fichier et décommenter la ligne.
precedence ::ffff:0:0/96 100
Si l’une des réponses ci-dessus ne fonctionne pas, vérifiez si votre pare-feu autorise TCP_OUT sur le port 9418. La sécurité de mon pare-feu était trop nette. Cela a pris si longtemps au compositeur que je n'ai jamais eu de délai d'attente ni d'indication que le port était bloqué. J'espère que ça aide!