config.assets.compile = true en la producción de Rails, ¿por qué no?

La aplicación Rails predeterminada instalada por rails new tiene config.assets.compile = false en producción.

Y la forma más común de hacer las cosas es ejecutar rake assets:precompile antes de implementar su aplicación, para asegurarse de que todos los activos de canalización de activos estén comstackdos.

Entonces, ¿qué sucede si configuro config.assets.compile = true en producción?

Ya no necesitaré ejecutar precompile . Lo que creo que sucederá es la primera vez que se solicita un activo, se comstackrá. Este será un golpe de rendimiento la primera vez (y significa que generalmente necesita un tiempo de ejecución js en producción para hacerlo). Pero aparte de estas desventajas, después de que el activo se compiló perezosamente, creo que el acceso posterior a ese activo no tendrá ningún impacto en el rendimiento, el rendimiento de la aplicación será exactamente el mismo que con los activos precomstackdos después de esta comstackción perezosa inicial de primer golpe. ¿Es esto cierto?

¿Hay algo que me estoy perdiendo? ¿Alguna otra razón para no configurar config.assets.compile = true en producción? Si tengo un tiempo de ejecución JS en producción, y estoy dispuesto a tomar la compensación de rendimiento degradado para el primer acceso de un activo, a cambio de no tener que ejecutar precompile , ¿tiene sentido esto?

Escribí ese pedacito de la guía.

Definitivamente no quieres vivir comstackr en producción.

Cuando tienes comstackción, esto es lo que sucede:

Cada solicitud de un archivo en / assets pasa a Sprockets. En la primera solicitud de todos y cada uno de los activos, se comstack y almacena en caché en lo que sea que Rails esté usando para la caché (generalmente el sistema de archivos).

En las solicitudes posteriores, Sprockets recibe la solicitud y debe buscar el nombre de archivo de las huellas dactilares, verificar que el archivo (imagen) o los archivos (css y js) que componen el activo no se hayan modificado, y luego si hay una versión almacenada en memoria caché.

Eso es todo en la carpeta de activos y en las carpetas de proveedores / activos utilizadas por los complementos.

Eso es una gran cantidad de gastos generales, para ser honesto, el código no está optimizado para la velocidad.

Esto tendrá un impacto en la rapidez con que los activos pasan por el cable al cliente y tendrá un impacto negativo en los tiempos de carga de la página de su sitio.

Compare con el valor predeterminado:

Cuando los activos se precomstackn y la comstackción está desactivada, los activos se comstackn y se toman las huellas digitales del public/assets . Piñones devuelve una tabla de mapeo de los nombres de archivo planos a Rails, y Rails lo escribe en el sistema de archivos. El archivo de manifiesto (YML en Rails 3 o JSON con un nombre aleatorio en Rails 4) se carga en Memory by Rails al inicio y se almacena en caché para que lo utilicen los métodos de ayuda de activos.

Esto hace que la generación de páginas con los activos correctos de huellas dactilares sea muy rápida, y el servicio de los archivos en sí mismos es rápido desde el servidor web desde el sistema de archivos. Ambos son mucho más rápidos que la comstackción en vivo.

Para obtener la máxima ventaja de la interconexión y la toma de huellas dactilares, debe establecer encabezados de futuro lejano en su servidor web y habilitar la compresión gzip para los archivos js y css. Piñones escribe versiones comprimidas de activos que puede configurar para usar, eliminando la necesidad de hacerlo para cada solicitud.

Esto permite que los activos lleguen al cliente lo más rápido posible y en el menor tamaño posible, acelerando la visualización de las páginas del lado del cliente y reduciendo (con el encabezado de futuro lejano) las solicitudes.

Entonces, si estás comstackndo en vivo, es:

  1. Muy lento
  2. No tiene compresión
  3. Impactará el tiempo de renderización de las páginas

Versus

  1. Tan rápido como sea posible
  2. Comprimido
  3. Eliminar la compresión oída por el servidor (opcionalmente).
  4. Minimiza el tiempo de renderizado de las páginas.

Editar: (Respuesta al comentario de seguimiento)

La tubería podría cambiarse a precomstackción en la primera solicitud, pero existen algunos obstáculos importantes para hacerlo. La primera es que tiene que haber una tabla de búsqueda para los nombres de huellas dactilares o los métodos de ayuda son demasiado lentos. Bajo un senario de comstackción a pedido, debería haber alguna forma de anexar a la tabla de búsqueda a medida que se comstack o solicita cada activo nuevo.

Además, alguien tendría que pagar el precio de la entrega lenta de los activos durante un período de tiempo desconocido hasta que todos los activos estén comstackdos y en su lugar.

El valor predeterminado, donde el precio de comstackr todo se paga fuera de línea a la vez, no afecta a los visitantes públicos y garantiza que todo funcione antes de que las cosas se activen.

El factor decisivo es que agrega mucha complejidad a los sistemas de producción.

[Editar, junio de 2015] Si está leyendo esto porque está buscando una solución para los tiempos lentos de comstackción durante una implementación, entonces podría considerar precomstackr los activos localmente. La información sobre esto se encuentra en la guía de canalización de activos . Esto le permite precomstackr localmente solo cuando hay un cambio, confirmarlo y luego tener una implementación rápida sin etapa de precomstackción.

Tener menos sobrecarga con la cosa de precomstackción.

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

puede simplemente usar imágenes y hojas de estilo como "/assets/stylesheet.css" en * .html.erb o "/assets/web.png"

Para cualquiera que use Heroku:

Si implementa en Herkou, realizará la precomstackción automáticamente durante la implementación si los activos comstackdos no están incluidos (es decir public/assets no se han comprometido los activos comstackdos public/assets ), por lo que no es necesario config.assets.compile = true o para comprometer los activos precomstackdos.

Los documentos de Heroku están aquí . Se recomienda una CDN para eliminar la carga en el recurso de dinamómetro.

Establecer config.asset.compile = false

Agregar a su Gemfile

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

Instala el paquete

Ejecutar rake assets:precompile

Entonces comienza tu servidor

De la guía oficial:

En la primera solicitud, los activos se comstackn y almacenan en caché como se describe en el desarrollo anterior, y los nombres de manifiesto utilizados en los ayudantes se modifican para incluir el hash MD5.

Piñones también establece el encabezado HTTP Cache-Control a max-age = 31536000. Esto indica todas las cachés entre su servidor y el navegador del cliente que este contenido (el archivo servido) se puede almacenar en caché durante 1 año. El efecto de esto es reducir el número de solicitudes para este activo de su servidor; el activo tiene buenas posibilidades de estar en el caché local del navegador o en algún caché intermedio.

Este modo usa más memoria, funciona peor que el predeterminado y no es recomendable.

Además, el paso de precomstackción no es ningún problema si utiliza Capistrano para sus despliegues. Te lo cuida. Usted acaba de correr

 cap deploy 

o (dependiendo de su configuración)

 cap production deploy 

y estás listo. Si aún no lo usa, le recomiendo que lo revise.

No será lo mismo que precomstackr, incluso después de ese primer golpe: como los archivos no están escritos en el sistema de archivos, no pueden ser servidos directamente por el servidor web. Algún código de Ruby siempre estará involucrado, incluso si solo lee una entrada de caché.