Description I'm trying to leverage docker to be a the core of some frontend development flow. To do that I'm trying to run some code from a local folder inside a node:7.4-slim container by mounting the folder in a volume.

In general file watching and serving files works as expected and doesn't have any performance hit from the volume mounting, but running unit tests with the JEST framework is extremely slow. An issue has been opened a few months ago on the JEST repository but I think opening one here might give the core team a better idea of the problem we're facing.

Steps to reproduce the issue:. Considering you have npm installed on your machine run npm install -g create-react-app. create-react-app test && cd test. docker run -rm -v $(pwd):/app -w /app node:7.4-slim bash -c 'npm install && npm run test'. To compare the performance with the previous result just run locally npm run test Describe the results you received: PASS src/App.test.js ✓ renders without crashing (33ms) Test Suites: 1 passed, 1 total Tests: 1 passed, 1 total Snapshots: 0 total Time: 7.334s Ran all test suites.

Watch Usage › Press p to filter by a filename regex pattern. › Press q to quit watch mode. › Press Enter to trigger a test run. To run one simple unit tests it takes more than 7s Describe the results you expected: In local the performance are really fast here's the output of the test task: PASS src/App.test.js ✓ renders without crashing (26ms) Test Suites: 1 passed, 1 total Tests: 1 passed, 1 total Snapshots: 0 total Time: 1.229s Ran all test suites. Watch Usage › Press p to filter by a filename regex pattern. › Press q to quit watch mode.

› Press Enter to trigger a test run. Thanks for the easily reproducible performance test case. Looking at some basic access statistics, it appears that whatever is executed from npm run test does about 300,000 file system operations resulting in more than 800,000 vsock messages before printing the Watch Usage message. This may be due to traversing all of nodemodules (multiple times?) to set up inotify watches on subdirectories. I measure 132s from docker run invocation until the Watch Usage message but the test system reports 6.2s elapsed so there may be some overhead here.

Is it possible to only run the test without doing the rest? How do you normally use this software? Just npm run test and let it watch? I also see that the access is highly parallel (up to 6 file system operations outstanding simultaneously). Perhaps surprisingly, this workload performs better with 1 vcpu allocated to Docker for Mac compared to 4 with test system-reported time of 5s (vs 6.2s) and end-to-end time of 98s (vs 132s). Free total commander alternative for mac.

We've been investigating this issue for several months (in parallel to other work) and the cause is a combination of the Linux scheduler, thread migration policy, and HyperKit interprocessor interrupt overhead. We have some modifications to Linux configuration and our in-VM thread use which may alleviate this multiprocessing bottleneck but those changes require more validation before being deployed which is currently prioritized below other performance improvement work.

What version of macOS are you running? The file system team has some improvements to performance nearing release which may help with this use case so I'm going to leave this issue open to track improvement of your usage. Thanks for your report! Yes there's a way to run the test without the watch mode. export CI=true. npm run test -coverage But in general our use case is to let it watch for changes. I ran it in non watch mode in docker and here are the results: ❯ docker run -rm -v $(pwd):/app -w /app -e CI=true node:7.4-slim bash -c 'npm run test -coverage' npm info it worked if it ends with ok npm info using npm@4.0.5 npm info using node@v7.4.0 npm info lifecycle test@0.1.0pretest: test@0.1.0 npm info lifecycle test@0.1.0test: test@0.1.0 test@0.1.0 test /app node scripts/test.js -env=jsdom PASS src/App.test.js ✓ renders without crashing (23ms) Test Suites: 1 passed, 1 total Tests: 1 passed, 1 total Snapshots: 0 total Time: 7.805s Ran all test suites.

Npm info lifecycle test@0.1.0posttest: test@0.1.0 npm info ok Maybe you'll get more info from this. I'm running macOS Sierra 10.12.3, but I had this same issue on 10.11 as well.

Thanks for sharing. Can you please share with the development community the modifications to Linux configurations and any possible changes to the configuration for VMs as soon as they become available. We know how the validation process works with some performance issues taking priority over others.

Binary Is Improperly Signed Issue 3137 Docker/for-mac Github Free

Please hit us back at this posting as-soon-as the information becomes available. Thanks in advance.

I have a MacOs, version 12.6.3. I would like to have that information specific to my operating system.

Hello, I am having an issue using docker for mac, i think is the udp packet who can't reach my target. This is a exemple: $ docker run -rm -it debian:8 /bin/bash $ apt-get update && apt-get install traceroute $ traceroute docker.com traceroute to docker.com (54.87.209.221), 30 hops max, 60 byte packets 1 172.17.0.1 (172.17.0.1) 0.035 ms 0.016 ms 0.025 ms 2. 3. 4.

30. i tried with -net=host and -net=bridge but it's not working either. Of course it working well outside of a docker container With the -I option, ( -I Use ICMP ECHO instead of UDP datagrams.) i have no issue $ traceroute -I docker.com traceroute to docker.com (54.87.209.221), 30 hops max, 60 byte packets 1 172.17.0.1 (172.17.0.1) 0.033 ms 0.010 ms 0.009 ms 2 ec2-54-87-209-221.compute-1.amazonaws.com (54.87.209.221) 0.181 ms 0.155 ms 0.712 ms docker for mac 1.13.1 (15353). Thank you for the report @ale-batt.

This is currently a limitation of vpnkit, used by Docker for Mac to provide networking. The ICMP messages are not forwarded to/from the external network, so the ICMP replies you see within the container are actually local replies. It appears to work, but the destination is always reached in one hop and the results are unfortunately incorrect. The TTL on packets going out of the container is also not preserved, so currently traceroute would be unable to find the route even if the ICMP messages came back correctly. I've opened issues in the vpnkit repo for the TTL value and ICMP messages. There are some experimental fixes in vpnkit for ICMP and UDP (not yet TCP). On Nov 3, 2017, at 8:48 AM, David Scott.@.

wrote: There are some experimental fixes in vpnkit for ICMP and UDP (not yet TCP).