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

L'app Rails predefinita installata da rails newha config.assets.compile = falsein produzione.

E il modo normale di fare le cose è eseguire rake assets:precompileprima di distribuire l'app, per assicurarsi che tutte le risorse della pipeline delle risorse siano compilate.

Quindi cosa succede se mi metto config.assets.compile = truein produzione?

Non dovrò precompilepiù correre . Ciò che credo accadrà è la prima volta che un asset viene richiesto, verrà compilato. Questo sarà un successo prestazionale quella 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 pigramente compilata, penso che tutti gli accessi successivi a quella risorsa non avranno alcun riscontro di prestazioni, le prestazioni dell'app saranno esattamente le stesse delle risorse precompilate dopo questa compilazione pigra iniziale al primo colpo. è vero?

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

Ho scritto quel pezzo di guida.

Sicuramente non vuoi vivere compilare in produzione.

Quando hai compilato, ecco cosa succede:

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

Su richieste successive, Sprockets riceve la richiesta e deve cercare il nome del file con impronta digitale, verificare che il file (immagine) o i file (css e js) che compongono l'asset non siano stati modificati, quindi se esiste una versione memorizzata nella cache serve tale.

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

Questo è un sacco di sovraccarico poiché, a dire il vero, il codice non è ottimizzato per la velocità.

Ciò avrà un impatto sulla velocità con cui la risorsa passa attraverso il cavo al cliente e avrà un impatto negativo sui tempi di caricamento della pagina del tuo sito.

Confronta con il valore predefinito:

Quando le risorse sono precompilate e la compilazione è disattivata, le risorse vengono compilate e impronte digitali su public/assets. Sprockets restituisce una tabella di mappatura della pianura a nomi di file con impronte digitali su Rails e Rails la scrive nel filesystem. Il file manifest (YML in Rails 3 o JSON con un nome casuale in Rails 4) viene caricato in Memory da Rails all'avvio e memorizzato nella cache per l'utilizzo con i metodi di supporto dell'asset.

Ciò rende molto veloce la generazione di pagine con le risorse corrette per le impronte digitali e la pubblicazione dei file stessi è veloce dal web server al file system. Entrambi drammaticamente più veloci della compilazione live.

Per ottenere il massimo vantaggio dalla pipeline e dall'impronta digitale, è necessario impostare intestazioni molto future sul server Web e abilitare la compressione gzip per i file js e css. Sprockets scrive le versioni gzip delle risorse che è possibile impostare per l'utilizzo del server, eliminando la necessità di farlo per ogni richiesta.

Questo porta le risorse al cliente il più velocemente possibile e nella dimensione più piccola possibile, accelerando la visualizzazione delle pagine sul lato client e riducendo (con intestazione molto futura) le richieste.

Quindi se stai compilando dal vivo è:

1. Molto lento
2. Manca la compressione
3. Inciderà sul tempo di rendering delle pagine

Contro

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

Modifica: (Risposta a follow-up commento)

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

Inoltre, qualcuno dovrebbe pagare il prezzo della consegna lenta degli asset per un periodo di tempo sconosciuto fino a quando tutti gli asset non vengono compilati e installati.

L'impostazione predefinita, in cui il prezzo di compilazione di tutto ciò che viene pagato off-line in una sola volta, non influisce sui visitatori pubblici e garantisce che tutto funzioni prima che le cose vadano in diretta.

Il punto di rottura è 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, allora potresti considerare di precompilare le risorse localmente. Le informazioni al riguardo sono contenute nella guida alla pipeline degli asset . Ciò consente di precompilare localmente solo quando si verifica una modifica, eseguirne il commit e quindi eseguire una distribuzione rapida senza fase di precompilazione.

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 semplicemente usare immagini e fogli di stile come "/assets/stylesheet.css" in * .html.erb o "/assets/web.png"

Per chiunque usi Heroku:

Se esegui la distribuzione su Herkou, eseguirà la precompilazione automaticamente durante la distribuzione se le risorse compilate non sono incluse (ovvero public/assetsnon impegnate), quindi non è necessario config.assets.compile = trueo impegnano le risorse precompilate.

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

Non sarà lo stesso della precompilazione, anche dopo quel primo hit: poiché i file non sono scritti nel filesystem non possono essere serviti direttamente dal web server. Un po 'di codice ruby ​​sarà sempre coinvolto, anche se legge solo una voce della cache.

Impostato config.asset.compile = false

Aggiungi al tuo Gemfile

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

Installa il pacchetto

Correre rake assets:precompile

Quindi avviare il server

Dalla guida ufficiale :

Alla prima richiesta, le risorse vengono compilate e memorizzate nella cache come indicato nello sviluppo sopra e i nomi manifest utilizzati negli helper vengono modificati per includere l'hash MD5.

I pignoni imposta inoltre 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 offerto) può essere memorizzato nella cache per 1 anno. L'effetto di ciò è di ridurre il numero di richieste per questa risorsa dal tuo server; l'asset ha buone probabilità di trovarsi nella cache del browser locale o in una cache intermedia.

Questa modalità utilizza più memoria, ha prestazioni inferiori a quelle predefinite e non è consigliata.

Inoltre, il passaggio precompilato non è affatto un problema se si utilizza Capistrano per le distribuzioni. Si prende cura di te per te. Corri e basta

cap deploy

o (a seconda della configurazione)

cap production deploy

e sei pronto. Se ancora non lo usi, ti consiglio vivamente di provarlo.

Perché sta aprendo una vulnerabilità di attraversamento di directory - https://blog.heroku.com/rails-asset-pipeline-vulnerability