2

There is a delay between saving code changes in a controller and being able to view them in the browser.

This is frustrating (to say the least) and makes it very hard to develop and debug module code.

I have tried setting up a development environment in docker and it's working quite well except for this nasty and unpredictable delay.

For a minimal example I tried installing the Hello World example module from the Prepare a Module skeleton guide.

My (minimal, but complete) setup is available here: https://github.com/glaux/drupal8docker.

To replicate the delay

  • Get the site up and running.
  • Log in as admin with pass 123 on http://localhost:8090
  • Navigate to /hello
  • Change the markup in the file /docker/project/modules/D8HWexample/src/Controller/HelloController.php
  • Refresh /hello - the changes will show up after between 5 and 300 seconds.

What I've tried

I've tried disabling all the caches by following the official guides. When making css changes to a custom theme (not included in the minimal repo above) the code changes are visible immediately, so this is not a cache problem I believe.

This is also emphasized by the fact that rebuilding the cache via the interface, drush and/or drupal console seems to have no effect on this delay.

In a similar manner I've tried disabling the browser cache (by opening the dev console on chrome). This have no effect either, nor have clearing the browser cache manually.

How can I get rid of this delay, what am I doing wrong here?

Edit

I think Clive could be right that this is possibly on the file system level. Here is an excerpt from the docker-compose file:

volumes: - ./docker/project/modules:/var/www/html/modules - ./docker/project/themes:/var/www/html/themes - ./docker/project/libraries:/var/www/html/libraries - ./docker/project/profiles:/var/www/html/profiles - ./docker/project/sites:/var/www/html/sites # Add anonymous volumes to exclude cache files explicitly - /var/www/html/sites/default/files/js - /var/www/html/sites/default/files/css - /var/www/html/sites/default/files/php

The files are added as explicit volumes, and the changes I make to HelloController.php are reflected in the image. I'm running this on Windows 10. Could this be the culprit, and how can I test this?

Improve this question
8
  • Sure it's not Varnish or another reverse proxy cache? I don't have this problem in half a dozen Drupal 8 sites, a couple of them sitting on Docker images, so it's likely to be something specific to your environment. Also are you editing in the docker image or via NFS/etc? If NFS, check that the delay isn't at the file system level Commented Jan 4, 2018 at 12:52
  • It's very possible it's at the file system level, any ideas to how I can check that? I'll add some sections of the docker-compose file to the question. Commented Jan 4, 2018 at 13:02
  • 1
    Er....good question! How about writing a quick script on the docker image with a file watcher, which logs the current time every time one of the files in your web folder changes. Then you can tail -f the log file, edit a file in Windows, and see how long it takes to register. Feels like there would a better way but that'll do in a pinch. See stackoverflow.com/questions/6475252/… for hints Commented Jan 4, 2018 at 13:10
  • Which makes the question off-topic for Drupal Answers? Commented Jan 4, 2018 at 14:29
  • 1
    Big change it is opcache as well. Your image appears to be based on drupal:8.4.3-apache, which sets an opcache revalidate frequency of 60 seconds. This means that if you access the same file within 60 seconds, it will be served from RAM instead. Commented Jan 4, 2018 at 18:09

1 Answer 1

Reset to default
5

Your image is based on drupal:8.4.3-apache, which sets an opcache revalidate frequency of 60 seconds:

# set recommended PHP.ini settings # see https://secure.php.net/manual/en/opcache.installation.php RUN { \ echo 'opcache.memory_consumption=128'; \ echo 'opcache.interned_strings_buffer=8'; \ echo 'opcache.max_accelerated_files=4000'; \ echo 'opcache.revalidate_freq=60'; \ echo 'opcache.fast_shutdown=1'; \ echo 'opcache.enable_cli=1'; \ } > /usr/local/etc/php/conf.d/opcache-recommended.ini

This means that if you access the same file within 60 seconds, it will be served from RAM instead.

Improve this answer
2
  • Hah, I've been using docker for mac for months now and just dealing with this infuriating delay. Once I discovered this I was so happy. I turned down the revalidate freq to 2 seconds instead of 60 and performance tanked. File access is now ~2.5x slower. :( Commented Jul 12, 2018 at 18:58
  • 1
    @Brian I am not an expert, but I think setting it to 2 seconds might even be worse than disabling it entirely. PHP would need to check all files used in a request (which are a lot with all different classes) and see if they have changed in the last 2 seconds. If a request takes a little longer, I can imagine some files even being checked multiple times. I have disabled it entirely in my dev and speeds are acceptable, otherwise try something like 10 seconds. Commented Sep 3, 2021 at 17:33

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.