rails docker_在Mac上的Docker上加速Rails

rails docker

Rails on Docker on Mac is slow. It’s so unbearably slow that the first time I launched it I just deleted Docker from my laptop and continued to run everything natively: 5.6s to 25.8s start-up slow down was just too high.

Mac上的Docker上的Rails速度很慢。 它是如此之慢，以至于我第一次启动它时，我只是从笔记本电脑中删除了Docker并继续以本机方式运行：5.6s到25.8s的启动速度实在太高了。

But there’s an easy solution to alleviate the issue significantly. With this one-line change, I decreased start-up time down to 9.8s (≈ 2.5x faster):

但是，有一个简单的解决方案可以大大缓解该问题。 通过这一行更改，我将启动时间降低到9.8s(快约2.5倍)：

为什么会发生？ (Why does it happen?)

By default, Docker maintains perfect consistency between the container’s and host’s file systems. When you run Linux containers on Linux hosts, there’s no overhead: both container and host end up using the same FS.

默认情况下，Docker保持容器和主机的文件系统之间的完美一致性。 在Linux主机上运行Linux容器时，没有任何开销：容器和主机最终都使用相同的FS。

However, that’s not the case for OS X, because it uses another file system type, and syncing changes between host and container takes some time. It adds relatively high penalty on IO-intensive operations — like reading sources of each of your app’s dependencies and their dependencies. So, the start-up is slowed down, but once the app is in the memory, performance comes back to normal.

但是，对于OS X并非如此，因为它使用另一种文件系统类型，并且在主机和容器之间同步更改需要一些时间。 这会给IO密集型操作带来相对较高的损失-例如读取应用程序每个依赖项及其依赖项的来源。 因此，启动速度变慢，但是一旦应用程序进入内存，性能就会恢复正常。

To circumvent this issue, you could switch the mode of the mounted volume from consistent (default one) to either cached or delegated. What does that mean? Those configurations allow micro-delays between propagating changes from one FS to another. Here's how official documentation describes them:

为了避免此问题，您可以将已安装卷的模式从consistent (默认值)切换为cached或delegated 。 那是什么意思？ 这些配置允许从一个FS到另一个FS的传播更改之间存在微延迟。 这是官方文档描述它们的方式 ：

• cached "typically improves the performance of read-heavy workloads, at the cost of some temporary inconsistency between the host and the container."

  cached “通常以主机和容器之间的某些暂时不一致为代价，提高了读取大量工作负载的性能。”

• with delegated, "writes performed by containers may not be immediately reflected on the host file system".

  如果使用delegated ，则“容器执行的写操作可能不会立即反映在主机文件系统上”。

The docs also say that delegates offer significantly better performance than the other configurations, though I didn't notice significant changes regarding Rails start-up time. I guess delegated shines with write-heavy flows, and performs on the same level as cached for read-heavy cases.

这些文档还说，与其他配置相比， delegates提供了显着更好的性能，尽管我没有注意到Rails启动时间的重大变化。 我猜delegated在大量写入的数据流中表现出色，并且在读取大量情况下的性能与cached相同。

这些微延迟有害吗？ (Are those micro-delays harmful?)

If we speak about loading Rails in dev environment — no, those delays are not harmful; it’s safe to put cached directive in your docker-compose.yml.

如果我们谈论在开发环境中加载Rails，则不会，这些延迟是无害的。 将cached指令放到docker-compose.yml是安全的。

I searched for approximate values for those possible delays but didn’t find any, unfortunately. On the bright side, during the search, I’ve found a nice blog post from the Docker team with details of the issues and some benchmarks.

我搜索了那些可能的延迟的近似值，但不幸的是没有找到任何近似值。 好的一面是，在搜索过程中，我从Docker团队那里找到了一篇不错的博客文章 ，其中包含问题的详细信息和一些基准。

我如何测量Rails的加载时间 (How I measured Rails load time)

I hope you would find the advice useful. Stay safe — and code joyfully.

希望您会觉得建议有用。 保持安全-快乐地编写代码。

If you liked this article, consider reading other ones I wrote:

如果您喜欢这篇文章，请考虑阅读我写的其他文章：

• How to Make a Perfect Pull Request

  如何提出完美的请求

• A Code Review Your Colleagues Would Thank You For

  代码审查您的同事将感谢您

翻译自: https://levelup.gitconnected.com/speed-up-rails-on-docker-on-mac-2c9871c33f63

rails docker