Is there a way to make Rails deployments faster?
I'm using nixpacks and it always takes around 7 minutes for a Rails app to build and deploy.
What can I do to make it faster?
Project ID: 9c6db4bc-b375-44fd-87b5-09e05a5e88f1
30 Replies
Project ID:
9c6db4bc-b375-44fd-87b5-09e05a5e88f1You might find these helpful:
- Build stuck on nix pack
- Project doesn't build
- How Can I Fix My Nixpacks Build?
⚠️ experimental feature
we dont do proper caching for ruby rn, and we dont know how to. if u can figure out what we need to cache i can spin up a pr to make it faster
The key question for me right now is how you invalidate cache when using nixpack?
We have no cache invalidation, we always bring in the cache then just update it if something changes.
What's that "something"? What do you mean by "something changes"?
Let's take npm modules for example. If package-lock.json changes, do you update the cache automatically? Or how does it work?
basically regardless of if it changes, we always update the cache with the latest package-lock.json
And what if the contents of package-lock.json don't change at all?
Will nixpacks build the npm packages again? Or will it use cache and therefore make the deployment faster?
Let me explain what I'm thinking about.
90% of the build time takes building the gems (Ruby libraries).
They are located in a file called Gemfile and Gemfile.lock.
We could cache Gemfile.lock to make the deployment faster.
We still run the cache update
I don’t think that’ll work tbh
Okay, I think I don't understand how your cache works then. I assumed it was similar to Docker image cache.
it works how the github actions cache works. we always recache it, it doesnt matter if the file hasnt changed
Gemfile.lock is a lockfile, caching that won't do anything, and im pretty sure that should be commited. we need to commit the directory with the built gems
I see
I'll try to think of other ways of improving the build then
Thanks 🙌
do u know where built gems are sent/located?
You want to know the directory where the gems are located?
They are not located in the project like it's with node_modules
You can check where the specific gem is located with
bundle show <gem_name> or bundle info <gem_name> --path
(I believe bundle show is deprecated)
Should the path be "static" (defined) in order to optimize it with nixpacks?yeah the built gems
not sure will look into later
All right
Milo, I'm sending a kind reminder 😄
I'd love to help but I need some directions
Why did you ask about the locations of the gems?
oh shit my badi forgot
basically, we need to cachce the built direction of the gems
if u can figure out where the built gems are, this'll work and we can cache it
It would be great
gems take 80% of the build time
Haha, it happens, no worries ^^
yea. jus lmk if u find it
sure thing
Can the cache be turned on and off?
For example when someone has custom build directory
no dont think so
Looks like nixpacks are using
rbenvyes we are
With rbenv the gems location is:
.rbenv/versions/3.1.1/lib/ruby/gems/3.1.0/gems/pay-6.3.1
Where:
3.1.1 is the installed Ruby version
3.1.0 is the minor version.
pay-6.3.1 is an example library.
---
So the gems location looks like this
~/.rbenv/versions/{version-number}/lib/ruby/gems/{minor-version}~/.rbenv/versions/{version-number}/lib/ruby/gems
so we will cache that
GitHub
Better Ruby caching by Milo123459 · Pull Request #817 · railwayapp/...
This PR caches the .rbenv directory. This will lead to significant speedups in Ruby builds.
Awesome, thanks!
When are changes like this usually merged?
depends. usually when jr reviews them 😄
Fingers crossed 🤞
Thanks once again. It's going to be huge for me. I love quick deployments.
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View