'composer create' and 'composer update' seem to hang then complete tens of minutes later

Created on 4 February 2025, 19 days ago

Problem/Motivation

Building a new dev environment and trying to install with composer. I have done this many times over the years but have been off for over a year now. There is a chance my LAMP environment is messed up but when I install just a vanilla core d11 site it works fine. Mem, CPU and Disk seem ok during the steps.

Anyone recognize this symptom?

p.s. I used to have a discord channel that I was in. Is that still active? Can I get an invite or link to rejoin?

Thanks

Steps to reproduce

$ composer create-project vardot/varbase-project:10.0.x-dev $drupal_root --stability dev --no-interaction
Creating a "vardot/varbase-project:10.0.x-dev" project at "/var/www/varbase"
Installing vardot/varbase-project (10.0.x-dev 51bd57dc9020738250b79d0280998a83accb75e8)
  - Installing vardot/varbase-project (10.0.x-dev 51bd57d): Extracting archive
Created project in /var/www/varbase
Loading composer repositories with package information

or

composer update

Take a very very long time. Doing the same for the core d10 project create works fine.

I am starting a new dev env after years off so I might have messed something up.

Has anyone ever seen something like this before?

Proposed resolution

Remaining tasks

  • βœ… File an issue about this project
  • ❌ Addition/Change/Update/Fix to this project
  • ❌ Testing to ensure no regression
  • βž– Automated unit/functional testing coverage
  • βž– Developer Documentation support on feature change/addition
  • βž– User Guide Documentation support on feature change/addition
  • βž– UX/UI designer responsibilities
  • βž– Accessibility and Readability
  • ❌ Code review from 1 Varbase core team member
  • ❌ Full testing and approval
  • ❌ Credit contributors
  • ❌ Review with the product owner
  • ❌ Update Release Notes and Update Helper on new feature change/addition
  • ❌ Release

Varbase update type

  • βœ… No Update
  • βž– Optional Update
  • βž– Forced Update
  • βž– Forced Update if Unchanged

User interface changes

  • N/A

API changes

  • N/A

Data model changes

  • N/A

Release notes snippet

  • N/A
πŸ’¬ Support request
Status

Active

Version

10.1

Component

Composer or Makefile

Created by

πŸ‡ΊπŸ‡ΈUnited States HeneryH

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @HeneryH
  • πŸ‡ΊπŸ‡ΈUnited States HeneryH

    I figured I would add some specifics and my machine metrics during the 15 minute composer update.

    I'm running an Ubuntu 22.04 LXC on ProxMox.

    First run in the screenshot was with 8g ram and 2 CPUs. I saw that cpu usage was capped at 50% so I doubled to 4 cpus. That doesn't seem to be it because the second run just capped at 25%.

    RAM usage seems to be ramping but that does not necessarily indicate a memory leak although it could.

    I'm running a LAMP stack with MariaDB/Apache2 and PHP 8.3.11.

    Here are some of my PHP settings.

    sudo a2enmod rewrite
    sudo phpenmod mbstring
    sudo a2enmod headers
    sudo a2enmod env
    sudo a2enmod dir
    sudo a2enmod mime
    sudo apt install php8.3-fpm
    sudo a2dismod php8.3
    sudo a2dismod mpm_prefork
    sudo a2enmod mpm_event proxy_fcgi setenvif
    sudo a2enconf php8.3-fpm
    sudo apt install php8.3-apcu
    sudo apt-get -y install redis-server php-redis
    sudo usermod -a -G redis $USER
    me@Drupal:/var/www/varbase$ grep -E "items" /etc/php/8.3/apache2/php.ini
        max_execution_time = 1200
        max_input_time = 1000
        max_input_vars = 3000
        memory_limit = -1
        post_max_size = 96M
        upload_max_filesize = 64M
        opcache.enable=1
        opcache.enable_cli=1
        opcache.memory_consumption=128
        opcache.interned_strings_buffer=10
        opcache.max_accelerated_files=10000
        opcache.revalidate_freq=60
        opcache.save_comments=1
        ;opcache.enable_file_override=0
    
    
    me@Drupal:/var/www/varbase$ grep -E "items" /etc/php/8.3/fpm/php.ini
        max_execution_time = 1200
        max_input_time = 1000
        max_input_vars = 3000
        memory_limit = -1
        post_max_size = 96M
        upload_max_filesize = 64M
        opcache.enable=1
        opcache.enable_cli=1
        opcache.memory_consumption=128
        opcache.interned_strings_buffer=10
        opcache.max_accelerated_files=10000
        opcache.revalidate_freq=60
        opcache.save_comments=1
        ;opcache.enable_file_override=0
    
    /etc/php/8.3/fpm/pool.d/www.conf
        pm.max_children = 64
        pm.start_servers = 16
        pm.min_spare_servers = 16
        pm.max_spare_servers = 32
        ;env[HOSTNAME] = $HOSTNAME
        env[PATH] = /usr/local/bin:/usr/bin:/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/snap/bin
        ;env[TMP] = /tmp
        ;env[TMPDIR] = /tmp
        ;env[TEMP] = /tmp
    
  • πŸ‡ΊπŸ‡ΈUnited States HeneryH

    I did a verbose composer update and it just seems like on a handful of downloads it just hangs for a while. I'll update this with the list of exactly which ones hang.

  • πŸ‡ΊπŸ‡ΈUnited States HeneryH

    To summarize the results above. There seems to be three packages that cause delays.

    • $jquery.fancytree.json accounts for 1.40 minutes of delay
    • $ckeditor--ckeditor5-dll-inline.json accounts for 14 minutes of delay
    • $blurhash.json accounts for 2 minutes of delay

    Any ideas on if there is user error or some systemic issue at the moment?

  • πŸ‡ΊπŸ‡ΈUnited States HeneryH
  • πŸ‡ΊπŸ‡ΈUnited States HeneryH
  • πŸ‡―πŸ‡΄Jordan Rajab Natshah Jordan

    Thanks, Joseph, for following up
    Yes, I confirm the issue
    https://asset-packagist.org is slow.

    Not sure if this issue is from asset-packagist.org server.

  • πŸ‡―πŸ‡΄Jordan Rajab Natshah Jordan

    Joseph, Could you please file an issue about this at https://github.com/hiqdev/asset-packagist/issues

  • πŸ‡―πŸ‡΄Jordan Rajab Natshah Jordan

    Moving this issue to Needs Work for now.
    asset-packagist.org is running slow. ( and fetching all nested libraries in package.json) which not what we want.

    Using the following TEMP fix

      "replace": {
        "npm-asset/ckeditor5": "*",
        "npm-asset/ckeditor5-dll-inline": "*",
        "npm-asset/ckeditor5-core": "*",
        "npm-asset/ckeditor5-engine":"*",
        "npm-asset/ckeditor5-ui": "*",
        "npm-asset/ckeditor5-utils": "*",
        "npm-asset/ckeditor5-widget": "*",
        "npm-asset/ckeditor--ckeditor5": "*",
        "npm-asset/ckeditor--ckeditor5-dll-inline": "*",
        "npm-asset/ckeditor--ckeditor5-core": "*",
        "npm-asset/ckeditor--ckeditor5-engine":"*",
        "npm-asset/ckeditor--ckeditor5-ui": "*",
        "npm-asset/ckeditor--ckeditor5-utils": "*",
        "npm-asset/ckeditor--ckeditor5-widget": "*",
        "npm-asset/lodash-es": "*",
        "npm-asset/lodash.debounce": "*",
        "npm-asset/lodash.throttle": "*",
        "npm-asset/nouislider": "*",
        "npm-asset/rtseo.js": "*",
        "bower-asset/jquery": "*",
        "bower-asset/jquery-ui": "*"
      },
    

    Drupal Core brings their ckeditor5 and Jquery. ( not needed to have them in libraries )

    Considering switching to a faster alternative.

  • πŸ‡―πŸ‡΄Jordan Rajab Natshah Jordan

    Builds in CIs are taking almost 20m for the "composer install"
    https://app.circleci.com/pipelines/github/Vardot/varbase/1035/workflows/...

  • πŸ‡―πŸ‡΄Jordan Rajab Natshah Jordan
Production build 0.71.5 2024