Приложение Heroku rails 3.1 - локальная компиляция ресурсов против компиляции ресурсов во время компиляции слагов

Question

Я запускаю приложение rails 3.1 в стеке Heroku Cedar, которое поддерживает конвейер ресурсов. Heroku перечисляет 3 способа для компиляции активов

1. Компиляция ресурсов локально.
2. Компиляция активов во время компиляции слагов.
3. Компиляция ресурсов во время выполнения.

Очевидно, что # 3 плохо сказывается на производительности, и документы Heroku также рекомендуют против этого. Но я не уверен, что лучше между № 1 и № 2.

# 1 требует, чтобы вы запустили rake assets:precompile и включили вашу папку public/assets в git. Ваш слаг будет больше, но я предполагаю, что время на развертывание сайта будет меньше. Но больший размер пули означает более медленный запуск приложения, поэтому, возможно, это мойка.

# 2 для развертывания обновлений потребуется больше времени из-за прекомпиляции, выполняемой на стороне Heroku. Тем не менее, у вас будет меньше пули, а управлять / помнить будет меньше.

У меня вопрос - какой вариант (# 1 или # 2) лучше всего подходит для производства и почему?

Пока что это выглядит как вариант № 2, но я хочу убедиться, что я ничего не пропускаю.

Answer 1

Я обратился к некоторым из этих проблем, и у меня большой вопрос в этом вопросе: Rails 3.1.1 конвейер ресурсов Кэширование Heroku:

Я бы предпочел № 2, если бы это сработало для меняпоэтому мне не нужно регистрировать скомпилированные ресурсы, которые просто раздувают репозиторий git.

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

Мой совет будет №2, если вы сможете заставить его работать на вас.Если вы в конечном итоге пойдете w / # 1, то лучше всего использовать git rm -r public / assets перед рейком активов: прекомпилировать, чтобы убедиться, что ничего не осталось.

Answer 2

Это может зависеть от размера вашей папки активов (и, возможно, долгосрочным решением было бы поместить эти активы за пределы приложения и разместить их на S3 и т. П.)

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

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