3 ms·
> but usually virtualization is a mostly unnecessary step in achieving production-like behavior. Mostly, we just need to make sure we're running the Rails serve
by why-el 11y ago
> but usually virtualization is a mostly unnecessary step in achieving production-like behavior. Mostly, we just need to make sure we're running the Rails server in production mode.
Isn't this assuming your development mode has the same memory/cpu as your production? I can't tell you how many times I get questions from clients who ask why their 16GB dev box is running fine while their 512MB dyno is slow. The point of a docker image is to limit these resources, which `rails s production` does not do.
- nateberkopec 11y agoSorry, I should have qualified that sentence: "a mostly unnecessary step in achieving production-like behavior *when trying to determine a page's average response time". That's just been my experience with this. I haven't noticed significant differences in my Macbook vs Heroku when measuring response times. It's a fast-and-loose measurement, to be sure. Virtualization/dockerization is the only way to get a super-accurate measurement.
- why-el 11y agoYeah I have been thinking about this as well. I guess it depends on how wide the difference is (when I said 512MB, I really meant it. People are still comparing that to their dev machines). Somewhat related: How has your experience been setting up docker with Rails? I have an idea for a project that seamlessly integrate docker into one's Rails dev workflow, but so far I have found its setup (let alone working with it) to be cumbersome to say the least.