Heroku e dimensioni di lumaca

Question

Sto iniziando a colpire un muro con la mia app di Heroku.

Sono ben consapevole dei problemi normali con le dimensioni di slug, re: immagini, PDF e altri materiali, ma il mio problema verte probabilmente su altre risorse introdotte da Bower o eventualmente sui pacchetti.

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

mio Heroku compliled lumaca assomiglia così:

$ 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 

Di gran lunga la più grande è fornitore (355M), ma la mia cartella fornitore locale è infatti vuota come è pubblico (195 milioni).

Ma Heroku Assomiglia:

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

che sto indovinando è uno dei diversi pacchetti di generazione per gazebo e per la generazione di PDF.

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

La mia app sembra magro a 22M, ma il mio attuale SLUG heroku è 298.4 MB! e la directory del fornitore da sola è più di quella secondo du, non dovrei usare questi build pack e migrare invece alla compilazione degli asset sul mio computer locale tra le build? Non sono sicuro di come dovrebbe essere una buona strategia di implementazione (/ dieta slug), qualsiasi idea sarebbe molto apprezzata.

UPDATE:

Ho anche provato a ricostruire la lumaca da quanto ho letto aveva lavorato per gli altri, ma senza alcun effetto. La dimensione di Slug dopo la compilazione è rimasta la stessa.

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

GIST di costruzione: https://gist.github.com/holden/b4721fc798bdaddf52c6

UPDATE 2 (dopo aver seguito l'ottima idea presentata da 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 

Venditore

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

pubblici/Attivo (molto lungo)

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

Answer 1

La dimensione di vendor/jvm è 103M. Dal momento che non stai usando JRuby, l'unica ragione per cui ho potuto trovarlo è usare la gemma yui-compressor. Guardando il heroku-buildpack-ruby sembra che la JVM è installato in questo caso:

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

Se si può evitare di utilizzare Yui-compressore si dovrebbe essere in grado di salvare 103M della dimensione slug.

Answer 2

Parte del problema potrebbe essere indicare repository Git nel tuo Gemfile. A un certo punto ho dovuto puntare a un commit di Rails che non era stato rilasciato e ha aggiunto> 100 MB alla mia dimensione di slug puntando a una versione rilasciata.

Answer 3

FWIW, abbiamo rimosso Bower dalla nostra app e lo abbiamo sostituito con il framework Rails Assets. Siamo giunti alla conclusione che usare Bower in un'app Rails era in qualche modo inutile dato che Bundler essenzialmente serve la stessa funzione.