Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement user-guided caching for web mount #253

Closed
tannerjfco opened this issue May 22, 2017 · 18 comments

Comments

@tannerjfco
Copy link
Contributor

commented May 22, 2017

What happened (or feature request):

Recent Docker releases (17.04 CE Edge onwards) bring significant performance improvements to bind-mounted directories on macOS. Docker users on the stable channel will see the improvements in the forthcoming 17.06 release. The new "cached" mode for bind mounts specifically provides improvements for large numbers of read operations.

What you expected to happen:

When Docker 17.06 is released (this should be sometime in June, as docker releases are time-based YY.MM format), we should consider updating our mount definition for the web container to use the cached mount mode. Using this mode provides notable performance improvements for various Drupal 8 tasks:

(Please note: the "default" mode is also referred to as "consistent" in the user-guided caching documentation.)
Running drush site-install from host:
Default: 1m03.13s
Cached: 1m04.79s

Running drush site-install from container:
Default: 2m23.51s
Cached:2m04.45s

Home page initial load time:
Default: 0m20.27s
Cached:0m05.74s

Load time using one-time login link:
Default: 0m08.65s
Cached:0m06.93s

Load time on user edit screen after login from one-time login:
Default: 0m14.22s
Cached:0m06.95s

Load time on /admin/modules:
Default: 0m14.75s
Cached:0m10.16s

How to reproduce it (as minimally and precisely as possible):

The cached mode can be tested by using Docker 17.05 CE Edge. To test with ddev, edit the docker-compose.yml for a site and change the web container mount to the following:

volumes:
      - "../:/var/www/html/docroot:cached"

Anything else do we need to know:

With cached, the host's view of the mount is authoritative. There may be delays before updates made on the host are visible within a container.

cached mode does not provide appreciable gains for write-heavy operations. Another mode, delegated, is in the works, that would address this concern. This mode makes the container runtime's view of the mount authoritative, which could mean delays before updates made in the container are visible on the host. We should follow up with more testing when the delegated option becomes available, in order to determine what will provide the best performance possible for most cases.

Cross-platform ramifications: These mount cache modes were largely introduced to address file system performance issues with Docker for Mac, but all docker releases should be able to interpret the new mode definitions. On Linux, where full consistency comes for free, cached behaves identically to consistent (default mode). Additional testing on Windows is required, as the current documentation does not state how Windows treats the configuration. The intent from Docker seems to be for this configuration to be cross-platform, even if it won't provide any difference on platforms like Linux.

My tests so far have been limited in scope to primary operations that we know to be more resource intensive. It would be beneficial to test this caching under heavier development task loads, to ensure the potential for delays in updates reaching the container do not impact development more adversely than the performance issues did.

Related source links or issues:

https://blog.docker.com/2017/05/user-guided-caching-in-docker-for-mac/

@rickmanelius

This comment has been minimized.

Copy link
Contributor

commented May 23, 2017

Getting this to an actionable state. I suggest the following acceptance criteria (beyond the handy data that @tannerjfco already recorded in the issue summary):

  • Compare site-install time for D8 site w/standard profile using competitor (Kalabox) and native LAMP/MAMP stack.
  • Compare site-install time for D8 site w/distribution profile using competitor (Kalabox) and native LAMP/MAMP stack.
  • Perform a set of routine tasks a site builder might do: create a gallery content type, devel generate 50 nodes, create a grid view.
  • Note any gotchas in utilizing the cached mode.
  • Decision on whether or not to adopt this as our default/recommended approach.
  • End-user documentation for changing this back to default mode.
@rickmanelius

This comment has been minimized.

Copy link
Contributor

commented May 23, 2017

It should be worth noting that the competitor comparison was intended to be performed here #257.

@rickmanelius

This comment has been minimized.

Copy link
Contributor

commented May 23, 2017

Looks like I'm up and running w/17.05.0-ce and will continue testing this tonight/tomorrow. Thanks for the instructions!

@rfay

This comment has been minimized.

Copy link
Member

commented May 24, 2017

:cached does in fact break current stable version of docker for windows, and works with edge. It might be worth detecting the current version and choosing based on that, not sure.

@rfay

This comment has been minimized.

Copy link
Member

commented May 24, 2017

Not necessarily relevant information, but a drush si on our drupal8 repo is easy to run on lots of platforms and does lots of stuff and is easy to time. I did drush si inside the container on several environments and at the end tried out :cached, which made a significant difference for OSX and even more for Windows.

Context Time for drush si - run inside container
ddev on windows drupal8 install drush si 2:11
ddev on windows with :cache 0:30
ddev on linux virtualbox running over OSX 0:54
ddev on OSX 3:52
ddev on OSX with :cache in docker mount 2:55
native nginx/fpm on OSX: 1:11
@rickmanelius

This comment has been minimized.

Copy link
Contributor

commented May 24, 2017

Initial drupal 8 site install results on macOS 10.12.5 with two variables:

  1. cache vs no cache
  2. UI vs CLI

Results

Caching Method Time
no cache UI 3:20
no cache CLI 1:10
cache UI 1:30
cache CLI 0:40

Testing details: drush.settings.php used to hold the credentials and I ran a ddev rm && ddev start before each test to fully remove the previous db.

Comparing to another experience, simplytest.me gets through a UI installation for Drupal 8 in just under 40 seconds.

Discussion

  • The cache option has a significant impact on performance, easily dropping the required time by 50% with each installation method.
  • It's concerning to me that the UI installation takes over 2.5X longer when a bulk of the work should be PHP executing a series of mySQL writes. There has to be a way to close this gap by profiling both experiences and figuring out if the issue is a php config mismatch, traffic through the proxy layer, etc.
@rfay

This comment has been minimized.

Copy link
Member

commented May 24, 2017

If I'm not mistaken, all of the files in all of the modules which are enabled by installation have to be read in order to write those mysql records, so that would explain the cost of the install. Install may be a bogus benchmark, but you certainly feel it when you try it!

One thing to add to your report: With your drush si did you do it within the container or from the host? @tannerjfco had reported both, although IMO the more realistic is the inside-container approach, because that's where all our stuff works.

@rickmanelius

This comment has been minimized.

Copy link
Contributor

commented May 24, 2017

It should be noted that my previous results were obtained while on a very fast wifi connection (200+ down/up). When I got on the bus and started to tether, my CLI w/caching time went up to 2 minutes! I'm curious how/why that would affect anything unless the install is reaching out to check something in the outside world.

@rickmanelius

This comment has been minimized.

Copy link
Contributor

commented May 24, 2017

Seems like there might be some network and/or system resource considerations.

  • Bus: CLI w/cache and tether 2:20
  • Offline: CLI w/cache 2:00
  • Offline w/ddev rm: CLI w/cache 2:00
  • Slow wifi w/ddev rm: CLI w/cache 2:10

System Restart

  • Slow wifi w/ddev rm: CLI w/cache 0:44
  • Again Slow wifi w/ddev rm: CLI w/cache 0:45
@rfay

This comment has been minimized.

Copy link
Member

commented May 24, 2017

IMO we should go with :cached. The outstanding concerns are:

  • How do we make it work with various versions of docker? Can we change the template to account for that?
  • How does this affect real developer activities? For example, if a dev changes a line of code in a module on the host (using an editor), what happens? What's the delay before the change shows up in the code in the container and affects website behavior?
@tannerjfco

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2017

I agree that :cached seems worthy of pursuit. Re: concerns:

  1. User-guided caching is slated for the 17.06 Stable release. Docker releases follow YY.MM versioning, which means 17.06 should be released sometime in June. Given that timing, I think we should wait for the stable release to drop to introduce :cached in our compose template. At that point, I think it's reasonable to update the System Requirements to require Docker 17.06+.
  2. I did some trivial tests changing theme template files and could not discern any delays in changes. It might be worth considering a more complex case to test here, but I don't think there's a concern when it comes to a developer iterating changes on individual files.
@rickmanelius

This comment has been minimized.

Copy link
Contributor

commented May 26, 2017

I'm in agreement that we should proceed and we just need to do, as Tanner mentioned, a bit more testing to see if there are any gotchas. However, we could also ship now and wait until we get real world feedback, which is going to be far more diverse than a mock series of tests that we step through.

@rickmanelius

This comment has been minimized.

Copy link
Contributor

commented May 26, 2017

To actually implement this, proposed changes would be:

  • Append the ":cached" value in the docker-compose.yml by default.
  • Adjust our documentation (Readme.md in the main repo and readthedocs) with a link to the edge version of Docker for Mac/Windows.

Anything else?

@rickmanelius rickmanelius added this to the v0.6 milestone May 26, 2017

@rfay

This comment has been minimized.

Copy link
Member

commented May 26, 2017

I did casual developer-focused testing of module changes on the host, then hitting the site to see if the changes showed up. I had no trouble at all, my changes displayed immediately. Of course it was a manual process:

  • Drupal8 install (our drupal8)
  • Edit node_help() in core/modules/node/node.module on the host to change direct output. I just used vim to make minor changes.
  • Refresh http://drupal8.ddev.local/admin/help/node
  • Each change was reflected as soon as I could hit the refresh.
@rickmanelius

This comment has been minimized.

Copy link
Contributor

commented May 26, 2017

Thanks, @rfay! That's encouraging.

I think even the casually testing by you and @tannerjfco indicates that there are no obvious gotchas. I think pushing to see if we get end-user feedback noting any issues will be more efficient/effective than testing a larger set of scenarios. I'd like to push to get the :cached value in place so we can close this out and get it merged.

@rickmanelius rickmanelius removed their assignment May 30, 2017

@rickmanelius

This comment has been minimized.

Copy link
Contributor

commented May 30, 2017

Lost my comment. 2nd attempt. Consolidated actions:

  • Confirm Docker is 17.05.0-ce or later. Prompt user to update and exit if this is not met.
  • Append the ":cached" value in the docker-compose.yml by default.
  • Specify our required version of docker in Readme.md. If an edge version is required, link the user to where they can find installers for these specific versions.

@tannerjfco tannerjfco changed the title Consider implementing user-guided caching for web mount Implement user-guided caching for web mount May 31, 2017

@rickmanelius

This comment has been minimized.

Copy link
Contributor

commented Jun 1, 2017

@beeradb This is the ticket that is the v0.6 blocker if you free up and @tannerjfco isn't able to get it.

@rickmanelius

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2017

PR merged. Thanks, @tannerjfco!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.