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

Named Volume Performance Feature #1460

Closed
dustinleblanc opened this issue Feb 13, 2019 · 80 comments
Closed

Named Volume Performance Feature #1460

dustinleblanc opened this issue Feb 13, 2019 · 80 comments
Assignees
Labels

Comments

@dustinleblanc
Copy link
Collaborator

@dustinleblanc dustinleblanc commented Feb 13, 2019

As a Mac OS / Windows Lando user,
I want to selectively mount paths within my application in named volumes,
So that I can increase my development speed by bypassing a significant portion of the speed penalty imposed by Docker's underlying filesharing mechanisms.

Notes from today's discussion:

  • Feature should be activated in each app specifically, within it's .lando.yml
  • 'Easy button' inside recipe config that would activate for common paths (D8 - vendor, core, etc).
  • Exclude key in root of lando.yml takes an array of paths that are relative to app root
  • On rebuild we spin up a util container, that copies the exclude paths into their respective volumes, then stops, starts the app, and mounts those volumes in the needed locations.
  • Upon disabling of feature, don't do anything with mounted code, notify user of change, and give them steps to remediate.
  • start/stop/restart should make no changes, rebuild required for all ops
  • potential future feature is two-way syncing, or even, container-authorative one way syncing.
@pirog pirog added this to the 3.0.0-rc.11 milestone Feb 19, 2019
pirog added a commit that referenced this issue Feb 21, 2019
pirog added a commit that referenced this issue Feb 21, 2019
pirog added a commit that referenced this issue Feb 21, 2019
@pirog
Copy link
Member

@pirog pirog commented Feb 25, 2019

@dustinleblanc so have some initial stuff over in https://github.com/lando/lando/tree/hyperdrive-motivator

the syntax is as follows

name: my-lando-app
excludes:
  - vendor
  - modules/contrib

And requires a lando rebuild.

We also could consider adding support for this sort of syntax as well, eg exclude all of X except Y, but that might be better as a separate issue.

name: my-lando-app
excludes:
  - modules/contrib
  - '!modules/contrib/search_api'

@pirog
Copy link
Member

@pirog pirog commented Feb 25, 2019

@dustinleblanc dropping a note here:

  1. Let's make sure we create any exclude directories that don't exist

@pirog
Copy link
Member

@pirog pirog commented Feb 25, 2019

@serundeputy... adding you to the party here. Dustin and I need a third opinion, can you...

  1. Get lando running on macOS from source with https://github.com/lando/lando/tree/hyperdrive-motivator checked out
  2. Get the dgreat and pe sites spin up with database and files and all needed things pulled
  3. Try out a few time lando drush cr and time lando drush status and log the average times somewhere

Then let's meet and see if we can get the hyperdrive-motivator working. Here are my stats for dgreat

without excluding

lando drush status: 20s
lando drush cr: 1m30s

excluding vendor, web/core and web/*/contrib

lando drush status: 1.3s
lando drush cr: 19s

So one thing i did notice @dustinleblanc (and @serundeputy), was restarting docker seemed to be necessary to get these gains to show up. No idea why but until i did that i saw "good" performance improvements but not "great"(eg the above) ones

@serundeputy
Copy link
Collaborator

@serundeputy serundeputy commented Feb 27, 2019

In order to get the performance increase I had to restart docker as @pirog also indicated.

dgreat

sans exclude

lando drush st
  real	1m56.403s
  user	0m0.907s
  sys	0m0.287s

lando drush cr:
  real	2m39.110s
  user	0m0.816s
  sys	0m0.280s

excluding vendor, web/core, and web/*/contrib

lando drush st:
  real	0m3.855s
  user	0m0.657s
  sys	0m0.318s

lando drush cr:
  real	0m15.643s
  user	0m0.724s
  sys	0m0.175s

pe

sans exclude

lando drush st: 
  real 0m1.328s
  user 0m0.457s
  sys 0m0.507s

lando drush cc all:
  real 3m0.532s
  user 0m0.808s
  sys 0m0.183s

excluding vendor, sites/all/modules/contrib

lando drush st: 
  real	0m3.120s
  user	0m0.628s
  sys	0m0.163s

lando drush cc all:
  real	1m16.717s
  user	0m0.699s
  sys	0m0.313s

pirog added a commit that referenced this issue Feb 27, 2019
pirog added a commit that referenced this issue Feb 27, 2019
pirog added a commit that referenced this issue Feb 27, 2019
@pirog
Copy link
Member

@pirog pirog commented Feb 27, 2019

Alright gents i've injected the coaxium into the motivator and TURBO MODE is now experimentally/unofficially in Lando
https://github.com/lando/lando/releases/tag/v3.0.0-rc.13

This is currently an "unsupported/undocumented" feature but i've got a PR queued up for when we want to put a ring on it
#1500

And the relevant documentation for it:
http://docs---warpfactor9-u6dlhhi-iaimrn624qfk6.us.platform.sh/config/performance.html

I'm going to ping people over at #763 to see if we can find any pioneers who want to try this out

@wss-chadical
Copy link

@wss-chadical wss-chadical commented Feb 27, 2019

@dustinleblanc @pirog @serundeputy
So far so good. Sorry, no actual benchmarks other then I would say it's BEYOND faster then vanilla lando, and significantly faster then the functioning NFS based setup we have been using for the last week.

.lando.yml for my pantheon wordpress recipe....

excludes:
  - vendor
  - web/wp-content/uploads
  - web/wp-content/themes/wholesalesolar/node_modules
  - web/wp-content/themes/wholesalesolar/vendor

Other observations:

  • Before rebuilding I rmrf'ed the above directories on the host.
  • Our lando build which consists of 2 seperate composer installs, and 1 yarn install was definitely faster.
  • A terminus rsync of a WP uploads folder with 2000+ files was MUCH faster (Excluded).
  • The yarn install and node builds were faster.
  • Browsersync is faster.
  • SASS builds are a "little" faster - maybe 5%?
  • Wordpress page loads much faster
  • Wordpress admin performance much faster

Overall I'd say this is a huge win.

We could probably exclude even more files since we are using a composer based wordpress install. Assuming we don't need our code editors to search wp core from the host, we could exclude web/wp as well.

EXCELLENT PROGRESS! Thank You.

I'll roll this out to some other devs and see how it goes.

@danielnitsche
Copy link
Contributor

@danielnitsche danielnitsche commented Feb 28, 2019

On RC13 comparing no excludes -> excludes I get:
lando start 69 seconds -> 155 seconds
drush site-install is 110 seconds -> 73 seconds

So pretty good on that front. Interestingly, site install was taking more like 300 seconds on RC1, so I feel like there have been other improvements along the way too.

Thanks!

🚀 🚀 🚀 👍

These were my excludes:

excludes:
  - vendor
  - web/themes/custom/my_theme/node_modules
  - web/themes/custom/my_theme/pattern-lab
  - modules/contrib

@danielnitsche
Copy link
Contributor

@danielnitsche danielnitsche commented Feb 28, 2019

About 10 minutes in, things are going really fast, but I'm wishing I didn't exclude modules/contrib. Considering the number of contrib modules and files in each of those modules, I not sure it's worth including this path in the example documentation.

@pirog
Copy link
Member

@pirog pirog commented Feb 28, 2019

@tormi
Copy link
Contributor

@tormi tormi commented Feb 28, 2019

For me, lando composer update drupal/mymodule --with-dependencies doesn't work anymore after excluding vendor folder:

screenshot 2019-02-28 at 06 35 24

@vaclavgreif
Copy link

@vaclavgreif vaclavgreif commented Feb 28, 2019

Does excluding the directories mean the autocompletition in IDE also won't work?

@pirog
Copy link
Member

@pirog pirog commented Feb 28, 2019

@tormi i also ran into this earlier this morning. what do you have for lando ssh -c "ls -lsa /app"?

my excluded directories are showing 1000:1000 ownership. Resetting these to www-data:www-data ownership seemed to be a workaround for now. I've also pushed up some stuff to master so we can enforce the ownership of excluded directories.

@pirog
Copy link
Member

@pirog pirog commented Feb 28, 2019

@vasikgreif possibly, i think it would depend on whether the code you exclude exists on your host before you exclude it or not. There are definitely consequences to excluding code and we aren't 100% sure of what they all are at this point hence why we've only pinged this thread about the feature and haven't released it generally yet.

@wss-chadical
Copy link

@wss-chadical wss-chadical commented Feb 28, 2019

Also seeing permissions related stuff going on...

➜  pl-wss-dot-com (master) ✗ lando ssh --service=sage
node@faa5180fbdd4:/app$ cd $LANDO_MOUNT/web/wp-content/themes/wholesalesolar
node@faa5180fbdd4:/app/web/wp-content/themes/wholesalesolar$ yarn install
yarn install v1.13.0
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
info fsevents@1.2.4: The platform "linux" is incompatible with this module.
info "fsevents@1.2.4" is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
warning " > stylelint-webpack-plugin@0.10.5" has incorrect peer dependency "webpack@^1.13.2 || ^2.7.0 || ^3.11.0 || ^4.4.0".
error An unexpected error occurred: "EACCES: permission denied, mkdir '/app/web/wp-content/themes/wholesalesolar/node_modules/abbrev'".
info If you think this is a bug, please open a bug report with the information provided in "/app/web/wp-content/themes/wholesalesolar/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
node@faa5180fbdd4:/app/web/wp-content/themes/wholesalesolar$

Seems like we don't have proper perms in the node_modules folder for some reason:

node@faa5180fbdd4:/app/web/wp-content/themes/wholesalesolar$ cd node_modules/
node@faa5180fbdd4:/app/web/wp-content/themes/wholesalesolar/node_modules$ ls -al
total 4
drwxr-xr-x  2 www-data www-data 4096 Feb 27 23:01 .
drwxr-xr-x 23 www-data www-data  736 Feb 28 16:42 ..
node@faa5180fbdd4:/app/web/wp-content/themes/wholesalesolar/node_modules$ touch t
touch: cannot touch 't': Permission denied

May have something to do with the directory already being there (or not) on rebuild?

@pirog
Copy link
Member

@pirog pirog commented Feb 28, 2019

@tormi
Copy link
Contributor

@tormi tormi commented Feb 28, 2019

@pirog , I have

4 drwxr-xr-x 50 www-data www-data 4096 Feb 28 16:44 vendor.

Fresh site install (git clone repo && lando start) with excludes: - vendor gives

0 drwxr-xr-x 2 root root 64 Feb 28 16:33 vendor

initially and lando composer update drupal/mymodule works.

The ownership of vendor folder has changed to

0 drwxr-xr-x 50 www-data www-data 1600 Feb 28 16:58 vendor

after using lando composer update .. stuff and I can use Composer from here on as usual.

@stale stale bot added the stale label Aug 10, 2019
@pirog pirog removed the stale label Aug 13, 2019
@mrweiner
Copy link

@mrweiner mrweiner commented Aug 13, 2019

Hitting a composer error when excluding my core directory, on windows if it makes a difference

λ lando composer update drupal/core
    1/7:        http://repo.packagist.org/p/provider-latest$afb01c74abd36587b21f8c2236bf0e570db1793b24dbe21c56d18bbd6cfd6b96.json
    2/7:        http://repo.packagist.org/p/provider-2019-04$540f80defa19af1bbf855afaadc3cc6e4ee04fb54bb071b4df627a615e0b4632.json
    3/7:        http://repo.packagist.org/p/provider-2016$7361df6435a0942610c6619b5cbaaf350007adbcf0cd928f8e4207dda7c6d337.json
    4/7:        http://repo.packagist.org/p/provider-2019-07$9e91e76798beafedf23ccf56725d3d088278192fb48ee96c8b2267c0a73664a3.json
    5/7:        http://repo.packagist.org/p/provider-2018$0785964fbd05606fdd81679ebe8fde72adc8d1b7cf506b830ddba7166527eefe.json
    6/7:        http://repo.packagist.org/p/provider-2017$bcdd918fa4125f012aa3ab5e3a1775f80c13cc6e5cb9f1b6ea19ef07cf462d01.json
    7/7:        http://repo.packagist.org/p/provider-2019-01$75cb18f70539666b6897b83eacf219b97779e88b01ffff05278aa31230d5062c.json
    Finished: success: 7, skipped: 0, failure: 0, total: 7
Gathering patches for root package.
  - Removing drupal/core (8.7.6)
Removing package drupal/core so that it can be re-installed and re-patched.


  [RuntimeException]      
  Could not delete core:

lando ssh then trying rm -rf core throws rm: cannot remove 'core': Device or resource busy

@pirog
Copy link
Member

@pirog pirog commented Aug 13, 2019

@mrweiner
Copy link

@mrweiner mrweiner commented Aug 13, 2019

Ah okay. Does that essentially mean that excluded directories cannot be updated/re-installed with composer? Do we need to completely destroy and restart the machine in order to run updates?

@pirog
Copy link
Member

@pirog pirog commented Aug 13, 2019

yeah unfortunately docker wont let you delete an entire mounted directory and composer tries to delete an entire mounted directory when it updates... so this is always going to be a struggle.

what i've done in this situation is

  1. remove the excludes
  2. rebuild the app
  3. composer update
  4. re-add the excludes
  5. rebuild the app

its not pretty but i think that is the best (only?) workaround for now. definitely down for other suggestions if anyone's got them!

@mrweiner
Copy link

@mrweiner mrweiner commented Sep 9, 2019

@pirog not sure if this is at all viable, but do you think it'd be possible to setup some sort of symlink internally so that the mounted directory itself doesn't need to be removed? I guess the idea would be that a separate "copy" of the vendor folder (vendor_copy) would exist in another location on the docker machine and could be deleted/manipulated by composer as needed, and the "real" vendor folder would actually be empty and symlinked to read the contents of vendor_copy.

@pirog
Copy link
Member

@pirog pirog commented Sep 10, 2019

@mrweiner maybe im not understanding exactly what you are describing but i feel like you'd end up with the same problem in that model as well. Even if you didn't my guess is something like that would be very hard to implement eg it would likely be brittle and possibly cause more problems than it fixed. Sadly, im not sure there is really a great way to deal with this mismatch between what docker needs and what composer needs beyond documenting a workaround.

definitely open to other ideas though!

@eelkeblok
Copy link

@eelkeblok eelkeblok commented Sep 23, 2019

Not sure if it's been reported before, but I didn't recall seeing this. It seems that on an entirely fresh start for a project, the Turbo Mode doesn't "trigger".

Because I had a mismatched Docker version I uninstalled Lando and Docker for Mac and reinstalled everything. My projects had to be set up from scratch, obiously. The named volumes weren't created, though, I needed to issue a rebuild to get things to work again. I don't think this is expected behaviour, right?

@stale
Copy link

@stale stale bot commented Oct 23, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.

@stale stale bot added the stale label Oct 23, 2019
@pirog pirog removed the stale label Oct 23, 2019
@stale
Copy link

@stale stale bot commented Nov 22, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.

@stale stale bot added the stale label Nov 22, 2019
@pirog pirog removed the stale label Nov 23, 2019
@pirog pirog removed this from the 3.0.0 milestone Dec 17, 2019
@stale
Copy link

@stale stale bot commented Jan 16, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.

@mrweiner
Copy link

@mrweiner mrweiner commented Mar 26, 2020

Fwiw, tested this a few days ago while running Docker 2.2.0.4 (patched version from #2052 (comment)) before downgrading back to 2.2.0.3 and the sync time appears to be exponentially faster with the update applied. Syncd ~400mil files of whatever that first number is between vendor + drupal core in about 8 mins. Right now on 2.2.0.3 I'm about 30% thru syncing at 16mins.

Possible that it's coincidence and something else was going on but it seemed noteworthy. Vendor seems to be syncing at ~142kb/s which seems terribly slow but I don't know enough to say why this might be.

EDIT: Welp, in the end, failure

Syncing web/vendor - web/core - web/modules/contrib...
rsync: link_stat "/tmp/web/vendor" failed: No such file or directory (2)
    401,279,748  76%  135.97kB/s    0:48:02 (xfr#87388, to-chk=0/149410)   
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]
chown: cannot access '/tmp/web/vendor': No such file or directory

@dustinleblanc
Copy link
Collaborator Author

@dustinleblanc dustinleblanc commented Mar 27, 2020

@mrweiner that is quite interesting! I wonder what would account for the major different between 2.2.0.3 and 2.2.0.4, but I won't look a gift horse in the mouth if we get mo powa baby

@mrweiner
Copy link

@mrweiner mrweiner commented Mar 28, 2020

@dustinleblanc I like the part where he says mo powa baby

@amaisano
Copy link

@amaisano amaisano commented Jul 30, 2020

To confirm, as of now changes made inside the container for an excluded path like /vendor will never sync back to the host, even on rebuild, correct? It's a one-way street from host->container on rebuild only (although I've noticed lando restart will also enter Turbo Mode)?

@pirog
Copy link
Member

@pirog pirog commented Jul 30, 2020

@amaisano its a 0-way street. Host and container are completely decoupled. The exception is on the first start/rebuild when the host files will be synced into the container to make sure you are starting from a consistent place.

Another caveat is if you are running on a Docker Desktop for Mac that supports mutagen eg the latest Docker Desktop Edge and running on a newer version of Lando then Lando will mutagen sync the excluded directories which means you should get performance gains without sacrificing the ability to edit files on either side and have those edits propagate to "the other side".

@amaisano
Copy link

@amaisano amaisano commented Jul 30, 2020

The exception is on the first start/rebuild when the host files will be synced into the container to make sure you are starting from a consistent place

Is this any time I run rebuild or just "the first [...]/rebuild"? Because I have been running rebuild to "sync" updates from our repo to the vendor folder (yes, I know, this sucks but it's a company limitation) back into the container, and it seems to work.

@pirog
Copy link
Member

@pirog pirog commented Jul 30, 2020

the first lando start and any lando rebuild, the comment would probably read clearer like

The exception is on the "first start"/rebuild when the host files will be synced into the container to make sure you are starting from a consistent place

@nik-lampe
Copy link

@nik-lampe nik-lampe commented Oct 10, 2020

I'd love to have some way to disable the automatic syncing in the beginning and have some way to do a manual sync from container to host.

I have the following use case:
I have a node express server running in lando on mac, which uses the sharp library for image manipulation.
It seems like there are different builds of this depending on the OS where the package is being installed.

So I need to run the npm install in the container.
But I want to exclude the node_modules folder so that adding a depenency doesn't take so long.
But I also need (at least a snapshot of) the contents of the folder on my host machine for the autocompletion in my IDEs to work.

Right now my solution is

  • delete the node_modules folder on the host
  • build the containers with running yarn in the build step
  • when the container is built I run yarn on the host
  • and everytime I add a new dependency I do it in the container and the host

Whenever I need to rebuild the container, I repeat the steps above

This seems like a little too much overhead and stuff to think about. As I don't really care if excluded folders of the container are in a consistent state with the host when the containers are being built.

I thought about having a command that spins up the same container with the node_modules (just for this example, it can be whatever folder) folder from the host being mounted to a different path on the container and then doing a rsync to sync the contents and then kill the new container again. This could be called manually whenever I want to sync the content back to my host system. Just as an Idea

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet