Кэширование статических ресурсов в Heroku с помощью Jammit путем изменения ActionController :: Base # page_cache_directory - PullRequest
Новая
       16

Кэширование статических ресурсов в Heroku с помощью Jammit путем изменения ActionController :: Base # page_cache_directory

3 голосов
/ 12 февраля 2011

Я пытаюсь использовать Jammit для упаковки CSS и JS для приложения Rails, развернутого на Heroku, которое не работает "из коробки" из-за файловой системы Heroku, доступной только для чтения.Каждый пример, который я видел, как это сделать, рекомендует заранее создавать все упакованные файлы ресурсов.Из-за развертывания Heroku на основе Git это означает, что вам нужно делать отдельную фиксацию в вашем хранилище каждый раз, когда эти файлы изменяются, что для меня неприемлемо.Вместо этого я хочу изменить путь, который Jammit использует для записи кэшированных пакетов, на #{Rails.root}/tmp/assets (путем изменения ActionController::Base#page_cache_directory), который доступен для записи в Heroku.

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

Когда вы включаете пакет, используя помощник Jammit, он выглядит примерно так: 

<%= include_javascripts :application %>

, который генерирует этот тег сценария: 

<script src="/assets/application.js" type="text/javascript"></script>

Когда браузер запрашивает этот URL-адрес, на самом деле происходит маршрутизация на Jammit::Controller#package, который передает содержимое пакета в браузер и затем записывает кэшированную копию в #{page_cache_directory}/assets/application.js.Идея состоит в том, что этот кэшированный файл создается по первому запросу, и последующие запросы должны обслуживать кэшированный файл напрямую, не затрагивая стек Rails.Я просмотрел код Jammit и не понимаю, как это должно происходить.Что мешает последующим запросам к /assets/application.js просто снова направить на Jammit::Controller и никогда не использовать кэшированный файл?

Я предполагаю, что где-то есть промежуточное программное обеспечение Rack, которое я не вижу, которое обслуживает файл, если он существуети направляет запрос на контроллер, если это не так.Если это так, где этот код?И как это будет работать при изменении ActionController::Base#page_cache_directory (эффективно, где Jammit записывает кэшированные пакеты)?Поскольку #{Rails.root}/tmp находится над общедоступным корнем документа, URL-адрес, соответствующий этому пути, отсутствует.

Ответы [ 2 ]

5 голосов
/ 13 февраля 2011

Отличный вопрос!Я не настроил это сам, но я хотел это изучить, поэтому вы мне подсказали.Вот что я бы попробовал (скоро я сам сделаю снимок, но вы, вероятно, собираетесь меня опередить). 

config.action_controller.page_cache_directory = "#{Rails.root}/tmp/page_cache"

Теперь измените ваш config.ru на: 

require ::File.expand_path('../config/environment',  __FILE__)
run Rack::URLMap.new(
   "/"       => Your::App.new,
   "/assets" => Rack::Directory.new("tmp/page_cache/assets"))

Просто убедитесь, что в public/assets ничего нет, поскольку это никогда не будет обнаружено.

Примечания:

  • Это для Rails 3. Не уверенрешения под Rails 2.
  • Похоже, что Rack::Directory устанавливает заголовки управления кэшем на 12 часов, поэтому Heroku будет кэшировать ваши активы в Varnish.Не уверен, установит ли Jammit это в своем контроллере, но даже если этого не произойдет, он будет кэширован довольно быстро.
  • Heroku также теперь устанавливает ENV['TMPDIR'], так что вы можете использовать это вместо Rails.root + '/tmp' если хотите.
0 голосов
/ 04 марта 2011

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

http://devcenter.heroku.com/articles/using-compass

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

...