Massive performance decrease when enabling XDEBUG_ENABLE

[fmuellerprevion]

Describe the bug When using our VMs, the loading times vary between one second on small and up to four seconds on very complex projects.

When enabling XDebug (XDEBUG_ENABLE: "true" in docker-compose.yml), the site slows down dramatically. Loading times vary between one and 10 Minutes!

The com.docker.hyperkit process takes up most of the physical CPUs performance when loading the site.

To Reproduce Steps to reproduce the behavior:

1. Go to docker-compose.yml
2. Set XDEBUG_ENABLE to "true"
3. docker-compose up -d
4. Load your application

Expected behavior A decrease in loading time to several seconds is absolutely ok. Up to 20 Seconds would be takeable.

Screenshots

Docker configuration

Additional context none

[fmuellerprevion]

docker-compose.yml

version: '2.3'

x-lagoon-project:
  # Lagoon project name (leave `&lagoon-project` when you edit this)
  &lagoon-project myproject

x-volumes:
  &default-volumes
    # Define all volumes you would like to have real-time mounted into the docker containers
    volumes:
      - .:/app:delegated

x-environment:
  &default-environment
    LAGOON_PROJECT: *lagoon-project
    # Route that should be used locally, if you are using pygmy, this route *must* end with .docker.amazee.io
    LAGOON_ROUTE: http://my-project.docker.amazee.io
    # Uncomment if you like to have the system behave like in production
    #LAGOON_ENVIRONMENT_TYPE: production
    # Uncomment to enable xdebug and then restart via `docker-compose up -d`
    #XDEBUG_ENABLE: "true"

x-user:
  &default-user
    # The default user under which the containers should run. Change this if you are on linux and run with another user than id `1000`
    user: '1000'

services:

  cli: # cli container, will be used for executing composer and any local commands (drush, drupal, etc.)
    build:
      context: .
      dockerfile: Dockerfile.cli
    image: *lagoon-project # this image will be reused as `CLI_IMAGE` in subsequent Docker builds
    labels:
      # Lagoon Labels
      lagoon.type: cli-persistent
      lagoon.persistent.name: nginx # mount the persistent storage of nginx into this container
      lagoon.persistent: /app/docroot/sites/default/files/ # location where the persistent storage should be mounted
    << : *default-volumes # loads the defined volumes from the top
    volumes_from: # mount the ssh-agent from the pygmy or cachalot ssh-agent
      - container:amazeeio-ssh-agent
    environment:
      << : *default-environment # loads the defined environment variables from the top

  nginx:
    build:
      context: .
      dockerfile: Dockerfile.nginx
      args:
        CLI_IMAGE: *lagoon-project # Inject the name of the cli image
    labels:
      lagoon.type: nginx-php-persistent
      lagoon.persistent: /app/docroot/sites/default/files/ # define where the persistent storage should be mounted too
    << : *default-volumes # loads the defined volumes from the top
    depends_on:
      - cli # basically just tells docker-compose to build the cli first
    environment:
      << : *default-environment # loads the defined environment variables from the top
      LAGOON_LOCALDEV_URL: nginx-my-project.docker.amazee.io # generate another route for nginx, by default we go to varnish
    networks:
      - amazeeio-network
      - default

  php:
    build:
      context: .
      dockerfile: Dockerfile.php
      args:
        CLI_IMAGE: *lagoon-project
    labels:
      lagoon.type: nginx-php-persistent
      lagoon.name: nginx # we want this service be part of the nginx pod in Lagoon
      lagoon.persistent: /app/docroot/sites/default/files/ # define where the persistent storage should be mounted too
    << : *default-volumes # loads the defined volumes from the top
    depends_on:
      - cli # basically just tells docker-compose to build the cli first
    environment:
      << : *default-environment # loads the defined environment variables from the top

  mariadb:
    image: amazeeio/mariadb-drupal
    labels:
      lagoon.type: mariadb
    ports:
      - "3306" # exposes the port 3306 with a random local port, find it with `docker-compose port mariadb 3306`
    << : *default-user # uses the defined user from top
    environment:
      << : *default-environment

  redis:
    build:
      context: .
      dockerfile: Dockerfile.redis
    labels:
      lagoon.type: redis
    <<: *default-user # uses the defined user from top
    environment:
      <<: *default-environment

  varnish:
    build:
      context: .
      dockerfile: Dockerfile.varnish
    labels:
      lagoon.type: varnish
    links:
      - nginx # links varnish to the nginx in this docker-compose project, or it would try to connect to any nginx running in docker
    environment:
      << : *default-environment
      VARNISH_BYPASS: "true" # by default we bypass varnish, change to 'false' or remove in order to tell varnish to cache if possible
    networks:
      - amazeeio-network
      - default

networks:
  amazeeio-network:
    external: true

[twerthmueller]

Would be great to get some feedback. I cannot believe that we're the only one that have this problem. Currently XDEBUGing is not really usable.

[Schnitzel]

@twerthmueller we unfortunately don't have other customers complaining about this.

Can you test with the https://github.com/amazeeio/drupal-example if you see the same amount of decrease of performance?

[twerthmueller]

@Schnitzel we will do that.

[alianov]

@twerthmueller I am facing a similar performance issue with xdebug on. Were you able to solve it?

[Feng-Shui]

I am seeing this too, page load times go out from a second or two to 30 to 120 seconds. Xhprof shows that it's northing specific, the whole request is just slow.

[fmuellerprevion]

@alianov actually, no. On our large projects, we still face the issue. Harshest requests are if you enable the debugger and restart the VM and furthermore clear Drupal caches - then it takes up to 6 minutes for the breakpoint to get caught. In regular development, we got down to mostly a few seconds ranging from 1 to 10 seconds until a breakpoint is activated in our IDE.

What maybe was a big part is that we initially did not ignore the Drupal files directory in .dockerignore. This is now inside and may or may not have contributed to increasing the allover speed a little bit:

.git
.lagoon.yml
docker-compose.yml
web/sites/default/files

But still, even compared to same Drupal 8 sites that run on vagrant, it's absolutely not comparable, as vagrant debugging works almost real time while the delay is massive on docker.

[twerthmueller]

Maybe this is also related to https://github.com/docker/for-mac/issues/3455

[chx]

Check https://jtreminio.com/blog/developing-at-full-speed-with-xdebug/ for a potential kludge of a workaround.

[mvorisek]

@fmuellerprevion @twerthmueller I work on some time refactoring in https://github.com/xdebug/xdebug/pull/602 , can you provide more details on used host OS/docker OS and ideally a minimalistic DockerFile to reproduce with one command to run?

[twerthmueller]

@mvorisek we're using the following docker compose configuration: https://github.com/amazeeio/drupal-example/blob/master/docker-compose.yml

[rocketeerbkw]

Looks like there's a fix for the sleep/wake issue now https://github.com/docker/for-mac/issues/3455#issuecomment-1064614213

//cc @twerthmueller

[twerthmueller]

Thanks @rocketeerbkw, will check that. But I switched to an M1 macbook and Docker Desktop 4.5.0. Currently I do not expect this behaviour anymore.

[Feng-Shui]

As per @twerthmueller, I'm not getting this issue anymore on an M1 MBP. Same Docker Desktop version.

[rocketeerbkw]

Both docker for mac and Xdebug have upstream fixes for the timing issue that causes performance problems in x86 macs.