Slow Compile Times on Heroku #1347
Comments
|
@gauravtiwari Hey, this is still a WIP. The only thing I've noticed for sure is that adding font-awesome jumps the precompile speed a lot from (26s with no deps to 119 sec). I'm going to keep experimenting when I have a bit more time because I'm in the 400 second mark with a marginally more complicated file. Don't worry about this issue as of now. |
|
What size dyno(s) are you deploying? I'm assuming your dynos are hitting up against memory limits; webpack will certainly eat up a lot of memory depending on a number of factors like bundle size, plugins and loaders in use, etc. |
|
@rossta For the sake of this test, I'm using dynos with 512 mb. I'm using a marginally more complicated application.js (fontawesome free vs pro, maybe 50 lines of javascript) and it's taking over 6 minutes. |
|
@gauravtiwari Okay, I did some more experiments and found when I removed fontawesome pro from my repo, I was able to drop the compile time from ~400 seconds to ~40 seconds. Font Awesome Pro has more icons as well an additional library, fontawesome light (listed above is solid, normal and brands). I guess the additional library + more icons is adding about another 200 seconds. I don't know if this an issue with webpacker + fonts, webpacker + node_modules or webpacker + fontawesome. Hopefully, this helps enough for reproducability. If there's anything else I can do to help, let me know. I'm going to email the maintainers of fontawesome and let them know. |
|
I'm going to close this issue since I believe my problem can be isolated to FontAwesome. Based on the comments on the issue, it does not seem they have a solution in mind. I will wait for a gem to (hopefully) be released or maybe upgrading to Webpacker 4 will help. |
|
@sunnyrjuneja google brought me there; not exactly related, but as heroku provides caching for node_modules, how one would benefit from this while running webpacker ? So far, I've witnessed that, when deploying on heroku :
Thx alot if you have any help on this one |
|
@benbonnet as far as I know there's no way to do so and heroku is aware heroku/heroku-buildpack-ruby#654 |
|
More or less trying to make sure nothing was wrong in my current setup |
|
@benbonnet no problem have a nice weekend |
ericboehs
added a commit
to ericboehs/heroku-buildpack-ruby
that referenced
this issue
Sep 2, 2018
## Goal Facilitate Webpacker's existing caching to skip running Webpack on builds where no changes are made. ## Approach Cache Webpacker's default pack output and cache paths between deploys. ## Context Currently all deploys using Webpacker will recompile on every deploy even if there are no files changed. This is because the digest file and packs directory is not cached between deploys. By default, Webpacker stores a cache digest in `tmp/cache/webpacker` and its packs in `public/packs`. Webpacker iterates over the watched paths to compute a digest based on the mtime of the files. If none of the files have changed and the packs directory is in place, running Webpack is skipped, saving a lot of time (e.g. my company's Rails app takes 8 minutes to run webpack). ## Caveats The environment variable `CI` needs to be set as the mtime does not seem to be preserved correctly across deploys. If `ENV['CI']` is set, Webpacker will use the file contents to compute the cache digest file instead of the files' mtime. I'm not familiar enough with the Heroku infrastructure to understand why the mtime isn't being preserved. I did notice that `cp`ing is done via `-a` which preserves timestamps via `--preserve=all` but that doesn't seem to be enough. ## Further Notes This could technically be solved without modifying either Webpacker or the Heroku build pack but I thought this would be the best place as it fixes all existing configurations provided they used the default settings. This would also make the default "just work" instead of requiring end users to configure their Rails apps specifically for Heroku. I didn't mean for this pull request to be the canonical place to fix this issue but merely an issue report with a solution attached. ## Related * rails/webpacker#1347
|
@benbonnet I too had this issue and I believe the only thing I changed was setting |
|
I have the same issue with the new package The following helps me solve this issue:
|
|
Turning off the I hate to randomly turn things off like this, but when deploying to Heroku the build times are even slower (around 10 min, but twice b/c of the Rails + Node build pack issues e.g. heroku/heroku-buildpack-ruby#654). Does anyone know why this is happening? Or if there's a better fix than a random configuration change? |
|
Our fix was to use FontAwesome's precompiled builds. You can still use package.json and add to Webpacker: |
Closed
qrush
pushed a commit
to chatterbugapp/heroku-buildpack-ruby
that referenced
this issue
May 17, 2019
## Goal Facilitate Webpacker's existing caching to skip running Webpack on builds where no changes are made. ## Approach Cache Webpacker's default pack output and cache paths between deploys. ## Context Currently all deploys using Webpacker will recompile on every deploy even if there are no files changed. This is because the digest file and packs directory is not cached between deploys. By default, Webpacker stores a cache digest in `tmp/cache/webpacker` and its packs in `public/packs`. Webpacker iterates over the watched paths to compute a digest based on the mtime of the files. If none of the files have changed and the packs directory is in place, running Webpack is skipped, saving a lot of time (e.g. my company's Rails app takes 8 minutes to run webpack). ## Caveats The environment variable `CI` needs to be set as the mtime does not seem to be preserved correctly across deploys. If `ENV['CI']` is set, Webpacker will use the file contents to compute the cache digest file instead of the files' mtime. I'm not familiar enough with the Heroku infrastructure to understand why the mtime isn't being preserved. I did notice that `cp`ing is done via `-a` which preserves timestamps via `--preserve=all` but that doesn't seem to be enough. ## Further Notes This could technically be solved without modifying either Webpacker or the Heroku build pack but I thought this would be the best place as it fixes all existing configurations provided they used the default settings. This would also make the default "just work" instead of requiring end users to configure their Rails apps specifically for Heroku. I didn't mean for this pull request to be the canonical place to fix this issue but merely an issue report with a solution attached. ## Related * rails/webpacker#1347
ankane
pushed a commit
to ankane/heroku-buildpack-ruby
that referenced
this issue
May 25, 2019
## Goal Facilitate Webpacker's existing caching to skip running Webpack on builds where no changes are made. ## Approach Cache Webpacker's default pack output and cache paths between deploys. ## Context Currently all deploys using Webpacker will recompile on every deploy even if there are no files changed. This is because the digest file and packs directory is not cached between deploys. By default, Webpacker stores a cache digest in `tmp/cache/webpacker` and its packs in `public/packs`. Webpacker iterates over the watched paths to compute a digest based on the mtime of the files. If none of the files have changed and the packs directory is in place, running Webpack is skipped, saving a lot of time (e.g. my company's Rails app takes 8 minutes to run webpack). ## Caveats The environment variable `CI` needs to be set as the mtime does not seem to be preserved correctly across deploys. If `ENV['CI']` is set, Webpacker will use the file contents to compute the cache digest file instead of the files' mtime. I'm not familiar enough with the Heroku infrastructure to understand why the mtime isn't being preserved. I did notice that `cp`ing is done via `-a` which preserves timestamps via `--preserve=all` but that doesn't seem to be enough. ## Further Notes This could technically be solved without modifying either Webpacker or the Heroku build pack but I thought this would be the best place as it fixes all existing configurations provided they used the default settings. This would also make the default "just work" instead of requiring end users to configure their Rails apps specifically for Heroku. I didn't mean for this pull request to be the canonical place to fix this issue but merely an issue report with a solution attached. ## Related * rails/webpacker#1347 Signed-off-by: Andrew Kane <[email protected]>
timm-oh
pushed a commit
to howler/heroku-buildpack-ruby
that referenced
this issue
Jul 9, 2019
## Goal Facilitate Webpacker's existing caching to skip running Webpack on builds where no changes are made. ## Approach Cache Webpacker's default pack output and cache paths between deploys. ## Context Currently all deploys using Webpacker will recompile on every deploy even if there are no files changed. This is because the digest file and packs directory is not cached between deploys. By default, Webpacker stores a cache digest in `tmp/cache/webpacker` and its packs in `public/packs`. Webpacker iterates over the watched paths to compute a digest based on the mtime of the files. If none of the files have changed and the packs directory is in place, running Webpack is skipped, saving a lot of time (e.g. my company's Rails app takes 8 minutes to run webpack). ## Caveats The environment variable `CI` needs to be set as the mtime does not seem to be preserved correctly across deploys. If `ENV['CI']` is set, Webpacker will use the file contents to compute the cache digest file instead of the files' mtime. I'm not familiar enough with the Heroku infrastructure to understand why the mtime isn't being preserved. I did notice that `cp`ing is done via `-a` which preserves timestamps via `--preserve=all` but that doesn't seem to be enough. ## Further Notes This could technically be solved without modifying either Webpacker or the Heroku build pack but I thought this would be the best place as it fixes all existing configurations provided they used the default settings. This would also make the default "just work" instead of requiring end users to configure their Rails apps specifically for Heroku. I didn't mean for this pull request to be the canonical place to fix this issue but merely an issue report with a solution attached. ## Related * rails/webpacker#1347 Signed-off-by: Andrew Kane <[email protected]>
timm-oh
pushed a commit
to howler/heroku-buildpack-ruby
that referenced
this issue
Jan 24, 2020
## Goal Facilitate Webpacker's existing caching to skip running Webpack on builds where no changes are made. ## Approach Cache Webpacker's default pack output and cache paths between deploys. ## Context Currently all deploys using Webpacker will recompile on every deploy even if there are no files changed. This is because the digest file and packs directory is not cached between deploys. By default, Webpacker stores a cache digest in `tmp/cache/webpacker` and its packs in `public/packs`. Webpacker iterates over the watched paths to compute a digest based on the mtime of the files. If none of the files have changed and the packs directory is in place, running Webpack is skipped, saving a lot of time (e.g. my company's Rails app takes 8 minutes to run webpack). ## Caveats The environment variable `CI` needs to be set as the mtime does not seem to be preserved correctly across deploys. If `ENV['CI']` is set, Webpacker will use the file contents to compute the cache digest file instead of the files' mtime. I'm not familiar enough with the Heroku infrastructure to understand why the mtime isn't being preserved. I did notice that `cp`ing is done via `-a` which preserves timestamps via `--preserve=all` but that doesn't seem to be enough. ## Further Notes This could technically be solved without modifying either Webpacker or the Heroku build pack but I thought this would be the best place as it fixes all existing configurations provided they used the default settings. This would also make the default "just work" instead of requiring end users to configure their Rails apps specifically for Heroku. I didn't mean for this pull request to be the canonical place to fix this issue but merely an issue report with a solution attached. ## Related * rails/webpacker#1347 Signed-off-by: Andrew Kane <[email protected]>
joshkinabrew
pushed a commit
to KingmanAg/heroku-buildpack-ruby
that referenced
this issue
Oct 21, 2020
## Goal Facilitate Webpacker's existing caching to skip running Webpack on builds where no changes are made. ## Approach Cache Webpacker's default pack output and cache paths between deploys. ## Context Currently all deploys using Webpacker will recompile on every deploy even if there are no files changed. This is because the digest file and packs directory is not cached between deploys. By default, Webpacker stores a cache digest in `tmp/cache/webpacker` and its packs in `public/packs`. Webpacker iterates over the watched paths to compute a digest based on the mtime of the files. If none of the files have changed and the packs directory is in place, running Webpack is skipped, saving a lot of time (e.g. my company's Rails app takes 8 minutes to run webpack). ## Caveats The environment variable `CI` needs to be set as the mtime does not seem to be preserved correctly across deploys. If `ENV['CI']` is set, Webpacker will use the file contents to compute the cache digest file instead of the files' mtime. I'm not familiar enough with the Heroku infrastructure to understand why the mtime isn't being preserved. I did notice that `cp`ing is done via `-a` which preserves timestamps via `--preserve=all` but that doesn't seem to be enough. ## Further Notes This could technically be solved without modifying either Webpacker or the Heroku build pack but I thought this would be the best place as it fixes all existing configurations provided they used the default settings. This would also make the default "just work" instead of requiring end users to configure their Rails apps specifically for Heroku. I didn't mean for this pull request to be the canonical place to fix this issue but merely an issue report with a solution attached. ## Related * rails/webpacker#1347 Signed-off-by: Andrew Kane <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue is an offshoot of #1319 (comment).
We're trying to debug why compile times are slow on Heroku. We are using https://github.com/sunnyrjuneja/wbspeedtest as a reproducible guide.
Reproduce steps:
$ heroku create$ heroku buildpacks:set heroku/ruby$ heroku buildpacks:add --index 1 heroku/nodejsThis is necessary getting webpack working.An application with no webpacker but both buildpacks added. Using commit: sunnyrjuneja/wbspeedtest@db5fd72
Result: Pretty fast.
Using sunnyrjuneja/wbspeedtest@a503b21
Changes: Add webpacker
Details:
Result:
Compile takes 26 seconds (with no additional deps)
Using sunnyrjuneja/wbspeedtest@8cc9a32
Changes: Add dependencies (fontawesome) and include in application.js
Result:
Asset precompilation completed (119.01s) (Big jump)
Add typescript sunnyrjuneja/wbspeedtest@aebad73
Result:
Asset precompilation completed (123.62s)
The text was updated successfully, but these errors were encountered: