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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

Это много накладных расходов, так как, честно говоря, код не оптимизирован для скорости.

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

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

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

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

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

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

Итак, если вы живое компиляция, это:

  • Очень медленно
  • Отсутствует сжатие
  • Будет влиять время рендеринга страниц

Против

  • Как можно быстрее
  • Сжатый
  • Извлеките компрессию с сервера (необязательно).
  • Минимизировать время рендеринга страниц.

Изменить: (ответьте на комментарий)

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

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

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

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

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

Ответ 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"

Ответ 3

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

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

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

Ответ 4

Установить config.asset.compile = false

Добавить в ваш Gemfile

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

Установите пакет

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

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

Ответ 5

От официального guide:

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

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

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

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

cap deploy

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

cap production deploy

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

Ответ 6

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