config.assets.compile = true nella produzione di Rails, perché no?

L’app Rails predefinita installata da rails new ha config.assets.compile = false in produzione.

E il modo ordinario per fare le cose è eseguire le rake assets:precompile prima di distribuire la tua app, per assicurarti che tutte le risorse della pipeline degli asset siano compilate.

Quindi cosa succede se imposto config.assets.compile = true in produzione?

Non ho più bisogno di eseguire precompile . Quello che credo succederà è la prima volta che viene richiesta una risorsa, che verrà compilata. Questo sarà un successo per le prestazioni la prima volta (e significa che in genere è necessario un runtime js in produzione per farlo). Ma a parte questi aspetti negativi, dopo che la risorsa è stata compilata pigramente, penso che tutti gli accessi successivi a quell’asset non avranno alcun impatto sulle prestazioni, le prestazioni della app saranno esattamente le stesse di quelle precompilate dopo questa prima compilation lazy iniziale. è vero?

C’è qualcosa che mi manca? Qualche altro motivo per non impostare config.assets.compile = true in produzione? Se ho un runtime JS in produzione e sono disposto a prendere il compromesso di prestazioni degradate per il primo accesso di un asset, in cambio del non dover eseguire il precompile , ha senso?

Ho scritto quel pezzo della guida.

Sicuramente non vuoi vivere compilando in produzione.

Quando ci si è compilati, questo è ciò che accade:

Ogni richiesta di un file in / assets viene passata a Sprockets. Alla prima richiesta per ciascuna risorsa viene compilato e memorizzato nella cache in qualunque Rails sta usando per la cache (di solito il filesystem).

Sulle richieste successive Pignoni riceve la richiesta e deve cercare il nome del file di impronte digitali, controllare che il file (immagine) oi file (css e js) che compongono la risorsa non siano stati modificati, e quindi se c’è una versione memorizzata nella cache che serve.

Questo è tutto nella cartella delle risorse e in tutte le cartelle dei fornitori / risorse utilizzate dai plugin.

Questo è un sovraccarico perché, ad essere onesti, il codice non è ottimizzato per la velocità.

Ciò avrà un impatto sulla velocità con cui la risorsa passerà al cliente e inciderà negativamente sui tempi di caricamento della pagina del tuo sito.

Confronta con il valore predefinito:

Quando le risorse sono precompilate e la compilazione è distriggersta, le risorse vengono compilate e prese di mira sul public/assets . Sprockets restituisce una tabella di mapping dei nomi di file semplici a quelli con impronte digitali in Rails e Rails scrive questo nel filesystem. Il file manifest (YML in Rails 3 o JSON con un nome randomizzato in Rails 4) viene caricato in memoria da Rails all’avvio e memorizzato nella cache per l’utilizzo da parte dei metodi helper dell’asset.

In questo modo la generazione di pagine con le risorse di impronte digitali corrette è molto veloce e il servizio dei file stessi è veloce da server web-da-file. Entrambi drammaticamente più veloci della compilazione dal vivo.

Per ottenere il massimo vantaggio dalla pipeline e dalle impronte digitali, è necessario impostare le intestazioni future sul server Web e abilitare la compressione gzip per i file js e css. Sprockets scrive versioni gzip di asset che è ansible impostare per utilizzare il server, eliminando la necessità di farlo per ogni richiesta.

Questo porta le risorse al cliente il più velocemente ansible, e nella dimensione più piccola ansible, velocizza la visualizzazione lato client delle pagine e riduce le richieste (con intestazione futura).

Quindi se la compilazione live è:

  1. Molto lento
  2. Manca la compressione
  3. Impatterà a rendere il tempo delle pagine

Contro

  1. Più velocemente ansible
  2. compressa
  3. Rimuovere la compressione ascoltata dal server (facoltativamente).
  4. Riduci al minimo il tempo di rendering delle pagine.

Modifica: (rispondi al commento successivo)

La pipeline potrebbe essere modificata in precompilazione alla prima richiesta ma ci sono alcuni ostacoli importanti per farlo. Il primo è che ci deve essere una tabella di ricerca per i nomi delle impronte digitali o che i metodi di supporto sono troppo lenti. Sotto un senario compilato su richiesta, dovrebbe essere necessario un modo per aggiungere alla tabella di ricerca ogni nuova risorsa viene compilata o richiesta.

Inoltre, qualcuno dovrebbe pagare il prezzo della consegna lenta delle risorse per un periodo di tempo sconosciuto fino a quando tutte le risorse sono compilate e installate.

L’impostazione predefinita, in cui il prezzo della compilazione di tutto è pagato offline contemporaneamente, non ha alcun impatto sui visitatori pubblici e garantisce che tutto funzioni prima che le cose vadano in diretta.

L’interruzione delle vendite è che aggiunge molta complessità ai sistemi di produzione.

[Modifica, giugno 2015] Se stai leggendo questo perché stai cercando una soluzione per tempi di compilazione lenti durante una distribuzione, puoi prendere in considerazione la precompilazione delle risorse localmente. Informazioni su questo sono nella guida della pipeline degli asset . Ciò consente di precompilare localmente solo quando è presente una modifica, eseguirne il commit e quindi distribuire rapidamente senza fase di precompilazione.

Per avere meno spese generali con la cosa di pre-compilazione.

 Precompile everything initially with these settings in production.rb # Precompile *all* assets, except those that start with underscore config.assets.precompile << /(^[^_\/]|\/[^_])[^\/]*$/ 

puoi quindi semplicemente utilizzare immagini e fogli di stile come "/assets/stylesheet.css" in * .html.erb o "/assets/web.png"

Per chiunque usi Heroku:

Se si distribuisce su Herkou, eseguirà automaticamente il precompilamento durante la distribuzione se le risorse compilate non sono incluse (cioè public/assets non impegnate), quindi non c’è bisogno di config.assets.compile = true o di commit delle risorse precompilate.

I documenti di Heroku sono qui . Si consiglia un CDN per rimuovere il carico sulla risorsa dyno.

Imposta config.asset.compile = false

Aggiungi al tuo Gemfile

group :assets do gem 'turbo-sprockets-rails3' end

Installa il pacchetto

Esegui rake assets:precompile

Quindi avvia il tuo server

Dalla guida ufficiale:

Alla prima richiesta le risorse sono compilate e memorizzate nella cache come descritto nello sviluppo sopra, ei nomi dei manifest utilizzati negli helper vengono modificati per includere l’hash MD5.

Sprockets imposta anche l’intestazione HTTP Cache-Control su max-age = 31536000. Ciò segnala a tutte le cache tra il server e il browser client che questo contenuto (il file servito) può essere memorizzato nella cache per 1 anno. L’effetto di questo è di ridurre il numero di richieste per questa risorsa dal tuo server; la risorsa ha buone probabilità di trovarsi nella cache del browser locale o in una cache intermedia.

Questa modalità utilizza più memoria, ha un rendimento inferiore a quello predefinito e non è consigliata.

Inoltre, la fase di precompilazione non è affatto un problema se si utilizza Capistrano per i deploy. Si prende cura di te per te. Tu corri

 cap deploy 

o (a seconda della configurazione)

 cap production deploy 

e sei tutto pronto. Se continui a non usarlo, ti consiglio vivamente di verificarlo.

Non sarà la stessa cosa della precompilazione, anche dopo il primo hit: poiché i file non sono scritti nel filesystem, non possono essere serviti direttamente dal server web. Alcuni codici ruby ​​saranno sempre coinvolti, anche se legge solo una voce cache.