Heroku 和蛞蝓大小膨胀答案

【问题标题】：Heroku and slug size bloatHeroku 和蛞蝓大小膨胀
【发布时间】：2015-02-08 14:31:42
【问题描述】：

我的 Heroku 应用开始碰壁了。

我很清楚 slug 大小、re: 图像、PDF 和其他材料的正常问题，但我的问题可能与 bower 或可能构建包带来的其他资产有关。

https://devcenter.heroku.com/articles/slug-compiler Heroku Slug Size After Multiple Deployments

我的 Heroku 编译的 slug 看起来像这样：

$ du -h --max-depth=1

4.0K    ./.bower-tmp
30M ./tmp
24K ./features
236K    ./config
195M    ./public
4.0K    ./log
34M ./bin
792K    ./db
355M    ./vendor
8.0K    ./.heroku
22M ./app
64K ./lib
8.0K    ./.bundle
136K    ./.bower-registry
22M ./.bower-cache
24M ./node_modules
12K ./.profile.d

到目前为止，最大的是 Vendor (355M)，但我的本地 vendor 文件夹实际上是空的，公共文件夹 (195M)。

但在 heroku 上它看起来像：

40M vendor/ruby-2.0.0
21M vendor/node
32K vendor/heroku
12K vendor/assets
103M vendor/jvm
192M vendor/bundle

195M public/assets (bower bloat?)

我猜这是 Bower 和 PDF 生成的几个构建包之一。

https://github.com/heroku/heroku-buildpack-nodejs
https://github.com/heroku/heroku-buildpack-ruby
https://github.com/razorfly/wkhtmltopdf-buildpack

我的应用程序本身看起来很精简，只有 22M，但我当前的 heroku SLUG 是 298.4MB！并且单独的供应商目录比du 的目录要多，我是否应该不使用这些构建包，而是在构建之间迁移到本地计算机上的资产编译？我不确定一个好的部署策略（/ slug diet）应该是什么样子，任何想法都会非常感激。

更新：

我还尝试根据我读到的对其他人有用的内容来重建 slug，但没有效果。编译后的 Slug 大小保持不变。

heroku plugins:install https://github.com/heroku/heroku-repo.git
heroku repo:rebuild -a appname

构建的 GIST：https://gist.github.com/holden/b4721fc798bdaddf52c6

更新 2（在遵循 drorb 提出的好主意之后）

12K ./.profile.d
21M ./app
4.0K    ./log
812K    ./db
8.0K    ./.heroku
236K    ./config
195M    ./public
19M ./.bower-cache
60K ./lib
253M    ./vendor
4.0K    ./.bower-tmp
128K    ./.bower-registry
34M ./bin
30M ./tmp
24M ./node_modules
24K ./features
8.0K    ./.bundle

供应商

12K vendor/assets
193M    vendor/bundle
21M vendor/node
32K vendor/heroku
40M vendor/ruby-2.0.0

公共/资产（很长）

https://gist.github.com/holden/ee67918c79dd3d197a6b

【问题讨论】：

标签： ruby-on-rails ruby-on-rails-4 heroku bower buildpack

【解决方案1】：

vendor/jvm 的大小为 103M。由于您没有使用 JRuby，我能找到使用它的唯一原因是使用 yui-compressor gem。看heroku-buildpack-ruby好像这种情况下安装了JVM：

def post_bundler
  if bundler.has_gem?('yui-compressor') && !ruby_version.jruby?
    install_jvm(true)
    ENV["PATH"] += ":bin"
  end
end

如果您可以避免使用 yui-compressor，您应该可以在 slug 大小上节省 103M。

【讨论】：

我删除了 YUI 并减少了 60MB，谢谢！我的 slug 仍然超重 235MB，还有其他很棒的想法吗？ ;-)
您能分享更新后的文件夹大小吗？下一个候选人将是 public/assets 和 public/assets
已更新。 public/assets 文件夹几乎是所有与 Bower 相关的资产。我遇到的问题是，即使我从 bower.json 中删除了库，它似乎也没有删除它们（例如，Hexaflip 早已死去，但它仍在资产中。）
@ere 您是否限制了预编译的资产类型？您是否尝试过清理资产或分叉应用程序？
是的，我在 application.rb 文件类型和 slugignore 中都限制了它们。我尝试在 slug 编译期间安装后执行 bower prune，更改 bower 包版本号，我还尝试使用插件重新编译 slug，heroku repo:rebuild 似乎无法获得干净的 bower 安装。

【解决方案2】：

FWIW，我们从应用程序中删除了 Bower，并将其替换为 Rails Assets 框架。我们得出的结论是，在 Rails 应用程序中使用 Bower 有点毫无意义，因为 Bundler 本质上提供相同的功能。

【讨论】：

我们在 2 或 3 个月前也尝试过 Rails Assets，但发现我们遇到了与 Bower 相同的问题，但对细节的控制更少。

【解决方案3】：

部分问题可能是指向您 Gemfile 中的 Git 存储库。有一次，我需要指向一个尚未发布的 Rails 提交，它比指向已发布的版本增加了超过 100 MB 的 slug 大小。

【讨论】：