Heroku i rozmiar podskoku

Question

Zaczynam uderzać w ścianę za pomocą mojej aplikacji Heroku.

Doskonale zdaję sobie sprawę z normalnych problemów związanych z rozmiarami robaków, obrazów:, plików PDF i innych materiałów, ale mój problem prawdopodobnie obraca się wokół innych aktywów wniesionych przez altankę lub ewentualnie kompilację pakietów.

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

Moja Heroku compliled ślimak wygląda tak:

$ 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 

Zdecydowanie największy jest sprzedawca (355m), ale mój folder lokalny sprzedawca w rzeczywistości jest pusty jak jest publiczny (195M).

Ale Heroku wygląda:

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?) 

Które Zgaduję jest jednym z kilku paczek budowania altany i do generowania PDF.

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

Moja aplikacja wygląda chudego na 22M, ale mój obecny heruk SLUG ma 298,4 MB! a sam katalog dostawców jest większy niż według du, czy nie powinienem używać tych pakietów budujących i zamiast tego migrować do kompilacji zasobów na moim komputerze lokalnym między kompilacjami? Nie jestem pewien, jak powinna wyglądać dobra strategia wdrażania (dieta ślimaka), wszelkie pomysły byłyby mile widziane.

UPDATE:

Próbowałem też przebudowa pocisk z tego co czytałem pracował dla innych, ale bez skutku. Rozmiar po kompilacji pozostał taki sam.

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

GIST budowy: https://gist.github.com/holden/b4721fc798bdaddf52c6

UPDATE 2 (po wykonaniu doskonały pomysł przedstawiony przez 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 

Vendor

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

publiczne/Aktywa (bardzo długi)

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

Answer 1

Rozmiar vendor/jvm to 103M. Ponieważ nie używasz JRuby, jedynym powodem, dla którego mogłem go znaleźć jest użycie klejnotu yui-compressor. Patrząc na heroku-buildpack-ruby wydaje się, że JVM jest zainstalowany w tym przypadku:

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

Jeśli można uniknąć stosując yui-sprężarka powinna być w stanie zaoszczędzić 103m od rozmiaru slug.

Answer 2

Część problemu może wskazywać na repozytoria Git w twoim pliku Gemfile. W pewnym momencie musiałem wskazać na zatwierdzenie Railsów, które nie zostało wydane i dodało> 100 MB do mojego rozmiaru slug, wskazując na wydaną wersję.

Answer 3

FWIW usunęliśmy Bower z naszej aplikacji i zastąpił go z ramami Rails Assets. Doszliśmy do wniosku, że używanie Bowera w aplikacji Railsowej jest nieco bezsensowne, ponieważ Bundler zasadniczo pełni tę samą funkcję.