6 ms·

I believe most macOS PHP developers use Homebrew. Some in combination with Laravel Valet for easy version switching and local domain management. Docker is horr

by iruoy 5y ago

I believe most macOS PHP developers use Homebrew. Some in combination with Laravel Valet for easy version switching and local domain management. Docker is horribly slow on macOS. I'd wish that on no developer. We had to use docker for one project, but quickly decided to just run the tests in Docker and let the developers figure their environments out by themselves.

toxik 5y ago
If you wonder why that is, it's because Docker for Mac actually runs the Docker engine inside a Linux virtual machine. That means that whenever you call Docker, it has to copy your "context" to the virtual machine, then actually run the Docker invocation inside the VM. This gets slow and annoying very fast for even 10MB "contexts". "Context" is anything in your working directory, more or less.
- udp 5y ago
  FreeBSD once had Docker working through the Linux compatibility layer. No virtualisation. I always thought would have been really cool to see that ported to macOS.
  - Stranger43 5y ago
    That depends a lot on weather the freeBSD compatiblity layer is kernel or user space as MacOS contrary to common space does not use an freeBSD derived kernel but one derived from the CMU mach64 project, and yes i know jobs said otherwise but he was never a trustworthy source for anything. I think macos actually uses an different binary executable format then the elf64 one shared between linux and freebsd, so the kind of binary level compatiblity that linux and freebsd share might not be shared between macos and freebsd.
- sa46 5y ago
  Another common slow down is bind mounts. Each file system operation is an RPC request between Docker for Mac and the Linux VM. I’ve never been super happy with Docker for Mac. I did a pretty deep dive into figuring out why it’s so slow with no satisfying conclusion: https://stackoverflow.com/q/58277794/30900 https://stackoverflow.com/q/58277794/30900
  - fart32 5y ago
    This is also true for Windows. WSL2 made containers faster, but FS is painfully slow. Sounds like the best thing (apart from switching) is running Linux in a VM (Hyper-V does OK) and having IDE, Docker and all the data in there.
    - nickjj 5y ago
      > WSL2 made containers faster, but FS is painfully slow. If you keep your code base in WSL 2's file system it's really really fast. Even thousands of tiny asset files will get picked up and compiled through multiple Webpack loaders in ~100ms on 5+ year old hardware.
      - fart32 5y ago
        What I really had an issue with was the timespan between modifying a file in an editor (running in Windows) and the change being actually present in the container. I had to restart tests way too often because the old code was executing, which was really annonying, as sometimes you can't really tell if it failed because of the old code, or because the implementation was wrong. The problem here is the delay between Windows and WSL2, once the files are in WSL2, it's fine. I may give it another chance, though. Thank you.
- lugged 5y ago
  This is trivially worked around with volume mounts and properly configuring VM / container resources. The overhead should be incredibly minimal. It is a waste of time though. Just use Linux.
  - oblio 5y ago
    I don't think they can really use Linux on Apple hardware. At least not as professional developers that don't want to fight the hardware, the OS <<and>> their development project.
    - lugged 5y ago
      So get a ThinkPad? Or a surface pro, or a Dell, or a Chromebook, or a system76?
      - oblio 5y ago
        I guess you missed the latest news about those devices with 20 hour battery life and the performance of a Intel device weighing twice as much :-)
        contriban 5y ago
        I doubt anyone would need to work anywhere near 20 hours without being connected at all. The vast majority of people work on desks with plugs.
        toxik 5y ago
        Hey, where are you going with that goalpost? Put that down again.
        daemoon 5y ago
        Probably not, but if your are doing some heavy work the battery will last significantly longer.
      - 5y ago
- nly 5y ago
  > If you wonder why that is, it's because Docker for Mac actually runs the Docker engine inside a Linux virtual machine. True of Windows too.
  - pantulis 5y ago
    Doesnt more recent Docker versions use HyperKit?
    - toxik 5y ago
      Correct but it’s still a virtual machine.
      - pantulis 5y ago
        I think I see your point, so it's not like the old explicit Boot2Docker mechanism but you are not running containers natively, right?
        toxik 5y ago
        It’s not like Docker on Linux, where there are cgroups and everything just zooms along.
  - pjmlp 5y ago
    Not when using Windows containers.
- hibbelig 5y ago
  Another problem is that bind mounts are slow; we put data into volumes if it's accessed often.
admissionsguy 5y ago
It used to be very slow, but I think they fixed it for the most part some months ago. It is certainly no longer a problem for my dev work since a certain docker version upgrade.
mschuster91 5y ago
Use :delegated in the volume mount to speed stuff up. Alternatively, if you are running Docker Compose, you can use two mounts and a volume. I'm assuming your application is a standard Symfony/Composer application, checked out in $HOME/Projects/foo: 1) $HOME/Project:/var/www 2) some-volume:/var/www/vendor Then, once the containers are created, run composer install inside the container, and then either run it again on the host or copy the files over using docker cp so that your IDE picks up the dependencies. For more complex stuff such as Drupal where you also have to account for web/modules/contrib, web/themes/contrib and the likes, you'll need to do the volume trick once again for each Composer-installed folder. The result will be that the tens of thousands of files that Composer installs and each request requires will be inside the Linux VM without any performance impact, whereas the dynamic files you are using for development will be instantly available in the VM. Long term I'd really wish if Docker for Mac/Windows could use inotify, on-demand synchronization plus a boatload of caching to get the performance issues under control. Oh, and while we're at it, it really really sucks that "host.docker.internal" is only available on Macs - you need that one to get xdebug to connect back to the "host", so you need two separate Docker Compose files, one for Mac developers and one for Linux developers. Sigh.
efficax 5y ago
The fact that Docker runs in Hyperkit/virtualization is not really the culprit for the slowness. That makes it a bit slower than native docker but virtualization is pretty good these days. The real problem is filesystem access. If you keep your volumes inside docker, it's pretty fast. Alternatively, you can try using NFS: https://www.jeffgeerling.com/blog/2020/revisiting-docker-macs-performance-nfs-volumes https://www.jeffgeerling.com/blog/2020/revisiting-docker-mac...

by iruoy 5y ago

toxik 5y ago

If you wonder why that is, it's because Docker for Mac actually runs the Docker engine inside a Linux virtual machine. That means that whenever you call Docker, it has to copy your "context" to the virtual machine, then actually run the Docker invocation inside the VM. This gets slow and annoying very fast for even 10MB "contexts". "Context" is anything in your working directory, more or less.

udp 5y ago
FreeBSD once had Docker working through the Linux compatibility layer. No virtualisation. I always thought would have been really cool to see that ported to macOS.
- Stranger43 5y ago
  That depends a lot on weather the freeBSD compatiblity layer is kernel or user space as MacOS contrary to common space does not use an freeBSD derived kernel but one derived from the CMU mach64 project, and yes i know jobs said otherwise but he was never a trustworthy source for anything. I think macos actually uses an different binary executable format then the elf64 one shared between linux and freebsd, so the kind of binary level compatiblity that linux and freebsd share might not be shared between macos and freebsd.
sa46 5y ago
Another common slow down is bind mounts. Each file system operation is an RPC request between Docker for Mac and the Linux VM. I’ve never been super happy with Docker for Mac. I did a pretty deep dive into figuring out why it’s so slow with no satisfying conclusion: https://stackoverflow.com/q/58277794/30900 https://stackoverflow.com/q/58277794/30900
- fart32 5y ago
  This is also true for Windows. WSL2 made containers faster, but FS is painfully slow. Sounds like the best thing (apart from switching) is running Linux in a VM (Hyper-V does OK) and having IDE, Docker and all the data in there.
  - nickjj 5y ago
    > WSL2 made containers faster, but FS is painfully slow. If you keep your code base in WSL 2's file system it's really really fast. Even thousands of tiny asset files will get picked up and compiled through multiple Webpack loaders in ~100ms on 5+ year old hardware.
    - fart32 5y ago
      What I really had an issue with was the timespan between modifying a file in an editor (running in Windows) and the change being actually present in the container. I had to restart tests way too often because the old code was executing, which was really annonying, as sometimes you can't really tell if it failed because of the old code, or because the implementation was wrong. The problem here is the delay between Windows and WSL2, once the files are in WSL2, it's fine. I may give it another chance, though. Thank you.
lugged 5y ago
This is trivially worked around with volume mounts and properly configuring VM / container resources. The overhead should be incredibly minimal. It is a waste of time though. Just use Linux.
- oblio 5y ago
  I don't think they can really use Linux on Apple hardware. At least not as professional developers that don't want to fight the hardware, the OS <<and>> their development project.
  - lugged 5y ago
    So get a ThinkPad? Or a surface pro, or a Dell, or a Chromebook, or a system76?
    - oblio 5y ago
      I guess you missed the latest news about those devices with 20 hour battery life and the performance of a Intel device weighing twice as much :-)
      - contriban 5y ago
        I doubt anyone would need to work anywhere near 20 hours without being connected at all. The vast majority of people work on desks with plugs.
        toxik 5y ago
        Hey, where are you going with that goalpost? Put that down again.
        daemoon 5y ago
        Probably not, but if your are doing some heavy work the battery will last significantly longer.
    - 5y ago
nly 5y ago
> If you wonder why that is, it's because Docker for Mac actually runs the Docker engine inside a Linux virtual machine. True of Windows too.
- pantulis 5y ago
  Doesnt more recent Docker versions use HyperKit?
  - toxik 5y ago
    Correct but it’s still a virtual machine.
    - pantulis 5y ago
      I think I see your point, so it's not like the old explicit Boot2Docker mechanism but you are not running containers natively, right?
      - toxik 5y ago
        It’s not like Docker on Linux, where there are cgroups and everything just zooms along.
- pjmlp 5y ago
  Not when using Windows containers.
hibbelig 5y ago
Another problem is that bind mounts are slow; we put data into volumes if it's accessed often.

admissionsguy 5y ago

It used to be very slow, but I think they fixed it for the most part some months ago. It is certainly no longer a problem for my dev work since a certain docker version upgrade.

mschuster91 5y ago

Use :delegated in the volume mount to speed stuff up. Alternatively, if you are running Docker Compose, you can use two mounts and a volume. I'm assuming your application is a standard Symfony/Composer application, checked out in $HOME/Projects/foo: 1) $HOME/Project:/var/www 2) some-volume:/var/www/vendor Then, once the containers are created, run composer install inside the container, and then either run it again on the host or copy the files over using docker cp so that your IDE picks up the dependencies. For more complex stuff such as Drupal where you also have to account for web/modules/contrib, web/themes/contrib and the likes, you'll need to do the volume trick once again for each Composer-installed folder. The result will be that the tens of thousands of files that Composer installs and each request requires will be inside the Linux VM without any performance impact, whereas the dynamic files you are using for development will be instantly available in the VM. Long term I'd really wish if Docker for Mac/Windows could use inotify, on-demand synchronization plus a boatload of caching to get the performance issues under control. Oh, and while we're at it, it really really sucks that "host.docker.internal" is only available on Macs - you need that one to get xdebug to connect back to the "host", so you need two separate Docker Compose files, one for Mac developers and one for Linux developers. Sigh.

efficax 5y ago

The fact that Docker runs in Hyperkit/virtualization is not really the culprit for the slowness. That makes it a bit slower than native docker but virtualization is pretty good these days. The real problem is filesystem access. If you keep your volumes inside docker, it's pretty fast. Alternatively, you can try using NFS: https://www.jeffgeerling.com/blog/2020/revisiting-docker-macs-performance-nfs-volumes https://www.jeffgeerling.com/blog/2020/revisiting-docker-mac...