config.assets.compile = true в производстве Rails, почему бы и нет?

Question

Приложение Rails по умолчанию, установленное rails new, имеет config.assets.compile = false в рабочем состоянии.

И обычный способ сделать это - запустить rake assets:precompile перед развертыванием приложения, чтобы убедиться, что все активы конвейера активов скомпилированы.

Так что же произойдет, если я установлю config.assets.compile = true в производство?

Мне больше не нужно запускать precompile. Я верю, что произойдет при первом запросе актива, он будет скомпилирован. Это будет удар по производительности в первый раз (и это означает, что для этого обычно требуется среда выполнения js). Но, кроме этих недостатков, после того, как актив был лениво скомпилирован, я думаю весь последующий доступ к этому активу будет иметь нет снижение производительности, производительность приложения будет точно такой же как с предварительно скомпилированными активами после первоначальной ленивой компиляции первого попадания. это правда?

Есть что-то, что я пропускаю? Любые другие причины не устанавливать config.assets.compile = true в производство? Если у меня есть JS runtime в процессе производства и я готов взять компромисс с ухудшением производительности для доступа first актива в обмен на отсутствие необходимости запуска precompile, имеет ли это смысл

Answer 1

Я написал этот бит руководства.

Вы определенно не хотите жить в процессе компиляции.

Когда у вас есть компиляция, вот что происходит:

Каждый запрос файла в / assets передается в Sprockets. По запросу first для каждого актива, который он компилирует и кэширует во всем, что Rails использует для кэширования (обычно в файловой системе).

При последующих запросах Sprockets получает запрос и должен найти имя файла с отпечатками пальцев, проверить, что файл (изображение) или файлы (css и js), составляющие ресурс, не были изменены, а затем, если существует кэшированная версия служить этому.

То есть все в папке ресурсов и в любых папках поставщиков / ресурсов, используемых плагинами.

Это большие издержки, так как, если честно, код не оптимизирован для скорости.

Это повлияет на скорость передачи активов клиенту и негативно скажется на времени загрузки страницы вашего сайта.

Сравните со значением по умолчанию:

Когда ресурсы предварительно скомпилированы, а компиляция отключена, активы скомпилированы и имеют отпечатки пальцев до public/assets. Sprockets возвращает таблицу сопоставления имен файлов с простым отпечатком в Rails, а Rails записывает это в файловую систему. Файл манифеста (YML в Rails 3 или JSON со случайным именем в Rails 4) загружается в Memory при помощи Rails при запуске и кэшируется для использования вспомогательными методами ресурса.

Это позволяет очень быстро генерировать страницы с правильными отпечатками, а сами файлы обрабатываются как веб-сервер из-за-файловой системы. Оба значительно быстрее, чем живая компиляция.

Чтобы получить максимальную выгоду от конвейера и дактилоскопии, вам нужно установить заголовки в далеком будущем на вашем веб-сервере и включить сжатие gzip для файлов js и css. Sprockets записывает сжатые версии ресурсов, которые вы можете настроить на использование своего сервера, избавляя от необходимости делать это для каждого запроса.

Это позволяет клиенту получать активы как можно быстрее и в наименьшем возможном размере, ускоряя отображение страниц на стороне клиента и сокращая (с заголовком в далеком будущем) запросы.

Итак, если вы работаете с компиляцией вживую, это:

1. Очень медленно
2. Не хватает компрессии
3. Будет влиять на время рендеринга страниц

Versus

1. Как можно быстрее
2. Сжатый
3. Удаление несанкционированного сжатия с сервера (опционально).
4. Минимизируйте время рендеринга страниц.

Редактировать: (Ответ для последующего комментария)

Конвейер можно изменить на прекомпиляцию при первом запросе , но для этого есть некоторые серьезные препятствия. Во-первых, должна существовать таблица поиска имен с отпечатками пальцев, или вспомогательные методы слишком медленные. В соответствии с senario по компиляции по требованию должен быть какой-то способ добавить таблицу поиска при компиляции или запросе каждого нового ресурса.

Кроме того, кто-то должен будет заплатить цену медленной доставки активов в течение неизвестного периода времени, пока все активы не будут собраны и размещены.

Значение по умолчанию, при котором цена компиляции всего за один раз оплачивается в автономном режиме, не влияет на общедоступных посетителей и гарантирует, что все работает до того, как все заработает.

Суть сделки заключается в том, что она добавляет много сложности производственным системам.

[Редактировать, июнь 2015 г.] Если вы читаете это, потому что ищете решение для медленного времени компиляции во время развертывания, то вы можете рассмотреть возможность предварительной компиляции ресурсов локально. Информация об этом содержится в руководстве по конвейеру активов . Это позволяет вам прекомпилировать локально только при наличии изменений, зафиксировать их, а затем выполнить быстрое развертывание без этапа прекомпиляции.

Answer 2

Чтобы сократить затраты на предварительную компиляцию.

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

тогда вы можете просто использовать изображения и таблицы стилей как "/assets/stylesheet.css" в * .html.erb или "/assets/web.png"

Answer 3

Для тех, кто использует Heroku:

Если вы развернете в Herkou, он будет выполнять прекомпиляцию автоматически во время развертывания, если скомпилированные ресурсы не включены (то есть public/assets не зафиксировано), поэтому нет необходимости1004 *, или для фиксации предварительно скомпилированных активов.

Документы Heroku здесь . CDN рекомендуется для удаления нагрузки на ресурс dyno.

Answer 4

Набор config.asset.compile = false

Добавить в свой Gemfile

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

Установить комплект

Выполнить rake assets:precompile

Затем запустите ваш сервер

Answer 5

Это не то же самое, что прекомпиляция, даже после первого попадания: поскольку файлы не записываются в файловую систему, они не могут обслуживаться непосредственно веб-сервером.Всегда будет задействован некоторый код ruby, даже если он просто читает запись в кэше.

Answer 6

Потому что это открывает уязвимость обхода каталога - https://blog.heroku.com/rails-asset-pipeline-vulnerability

Answer 7

Из официального руководства :

По первому запросу ресурсы компилируются и кэшируются, как описано выше в разработке, а имена манифестов, используемые в помощниках, изменяются навключает хеш MD5.

Звездочки также устанавливают HTTP-заголовок Cache-Control на max-age = 31536000.Это сигнализирует всем кэшам между вашим сервером и браузером клиента, что этот контент (обслуживаемый файл) может быть кэширован в течение 1 года.Результатом этого является уменьшение количества запросов на этот ресурс с вашего сервера;актив имеет хорошие шансы оказаться в локальном кэше браузера или в некотором промежуточном кэше.

В этом режиме используется больше памяти, он работает хуже, чем по умолчанию, и не рекомендуется.

Также, шаг прекомпиляции совсем не проблема, если вы используете Capistrano для своих развертываний.Это позаботится об этом для вас.Вы просто запускаете

cap deploy

или (в зависимости от настроек)

cap production deploy

и все готово.Если вы все еще не используете его, я настоятельно рекомендую проверить его.