我们有一个Rails 3.2网站，该网站相当大，有数千个网址。我们为Russian Doll缓存实现了Cache_Digests gem。它运作良好。我们希望通过隔夜加热缓存来进一步优化，以便用户在白天获得更好的体验。我已经看到了这个问题的答案：Rails: Scheduled task to warm up the cache?
是否可以修改大量的网址？
答案 0 :(得分：2)
要使用昂贵的加载时间触发多个页面的缓存命中，只需创建一个rake任务，以迭代方式将网络请求发送到您网站中的所有记录/网址组合。 （Here is one implementation）
Net::HTTP请求所有网站网址/记录：要仅访问每个页面，您可以运行每晚的Rake任务，以确保清晨用户仍然拥有包含刷新内容的快速页面。
LIB /任务/ visit_every_page.rake ：
namespace :visit_every_page do
include Net
include Rails.application.routes.url_helpers
task :specializations => :environment do
puts "Visiting specializations..."
Specialization.all.sort{ |a,b| a.id <=> b.id }.each do |s|
begin
puts "Specialization #{s.id}"
City.all.sort{ |a,b| a.id <=> b.id }.each do |c|
puts "Specialization City #{c.id}"
Net::HTTP.get( URI("http://#{APP_CONFIG[:domain]}/specialties/#{s.id}/#{s.token}/refresh_city_cache/#{c.id}.js") )
end
Division.all.sort{ |a,b| a.id <=> b.id }.each do |d|
puts "Specialization Division #{d.id}"
Net::HTTP.get( URI("http://#{APP_CONFIG[:domain]}/specialties/#{s.id}/#{s.token}/refresh_division_cache/#{d.id}.js") )
end
end
end
end
# The following methods are defined to fake out the ActionController
# requirements of the Rails cache
def cache_store
ActionController::Base.cache_store
end
def self.benchmark( *params )
yield
end
def cache_configured?
true
end
end
如果您需要绕过用户身份验证限制以访问您的网页，并且/或者您不想搞砸（太糟糕）您网站的跟踪分析，您可以创建custom controller action来点击缓存摘要那use tokens to bypass authentication：
应用程序/控制器/ specializations.rb：
class SpecializationsController < ApplicationController
...
before_filter :check_token, :only => [:refresh_cache, :refresh_city_cache, :refresh_division_cache]
skip_authorization_check :only => [:refresh_cache, :refresh_city_cache, :refresh_division_cache]
...
def refresh_cache
@specialization = Specialization.find(params[:id])
@feedback = FeedbackItem.new
render :show, :layout => 'ajax'
end
def refresh_city_cache
@specialization = Specialization.find(params[:id])
@city = City.find(params[:city_id])
render 'refresh_city.js'
end
def refresh_division_cache
@specialization = Specialization.find(params[:id])
@division = Division.find(params[:division_id])
render 'refresh_division.js'
end
end
我们的自定义控制器操作会呈现其他昂贵的视图来加载页面，从而导致对这些页面的缓存命中。例如。 refresh_cache 呈现相同的视图页面＆amp;数据为 controller＃show ，因此对 refresh_cache 的请求将为这些记录预热与 controller＃show 相同的缓存摘要。
出于安全原因，我建议在提供您传递令牌and check it的任何自定义refresh_cache控制器请求之前，以确保it corresponds with a unique token for that record.在提供之前将URL令牌与数据库记录匹配访问（如上所示）是微不足道的，因为您的Rake任务可以访问每条记录的唯一令牌 - 只需将记录的令牌传入每个请求。
要触发数千个网站网址/缓存摘要，请创建一个rake任务，以迭代方式请求您网站中的每个记录/网址组合。您可以通过创建自定义控制器操作来绕过应用程序对此任务的用户身份验证限制，该操作通过令牌验证访问权限。
答案 1 :(得分：0)
我意识到这个问题已经有一年了，但是我在研究了一堆偏僻的问题之后才得出了自己的答案。不正确的解决方案。
希望这会对下一个人有所帮助......
根据我自己的实用程序类，可在此处找到： https://raw.githubusercontent.com/JayTeeSF/cmd_notes/master/automated_action_runner.rb
你可以简单地运行它（按照它的.help方法）并预先缓存你的页面，而不需要在这个过程中绑定你自己的网络服务器。
class AutomatedActionRunner
class StatusObject
def initialize(is_valid, error_obj)
@is_valid = !! is_valid
@error_obj = error_obj
end
def valid?
@is_valid
end
def error
@error_obj
end
end
def self.help
puts <<-EOH
Instead tying-up the frontend of your production site with:
`curl http://your_production_site.com/some_controller/some_action/1234`
`curl http://your_production_site.com/some_controller/some_action/4567`
Try:
`rails r 'AutomatedActionRunner.run(SomeController, "some_action", [{id: "1234"}, {id: "4567"}])'`
EOH
end
def self.common_env
{"rack.input" => "", "SCRIPT_NAME" => "", "HTTP_HOST" => "localhost:3000" }
end
REQUEST_ENV = common_env.freeze
def self.run(controller, controller_action, params_ary=[], user_obj=nil)
success_objects = []
error_objects = []
autorunner = new(controller, controller_action, user_obj)
Rails.logger.warn %Q|[AutomatedAction Kickoff]: Preheating cache for #{params_ary.size} #{autorunner.controller.name}##{controller_action} pages.|
params_ary.each do |params_hash|
status = autorunner.run(params_hash)
if status.valid?
success_objects << params_hash
else
error_objects << status.error
end
end
return process_results(success_objects, error_objects, user_obj.try(:id), autorunner.controller.name, controller_action)
end
def self.process_results(success_objects=[], error_objects=[], user_id, controller_name, controller_action)
message = %Q|AutomatedAction Summary|
backtrace = (error_objects.first.try(:backtrace)||[]).join("\n\t").inspect
num_errors = error_objects.size
num_successes = success_objects.size
log_message = %Q|[#{message}]: Generated #{num_successes} #{controller_name}##{controller_action}, pages; Failed #{num_errors} times; 1st Fail: #{backtrace}|
Rails.logger.warn log_message
# all the local-variables above, are because I typically call Sentry or something with extra parameters!
end
attr_reader :controller
def initialize(controller, controller_action, user_obj)
@controller = controller
@controller = controller.constantize unless controller.respond_to?(:name)
@controller_instance = @controller.new
@controller_action = controller_action
@env_obj = REQUEST_ENV.dup
@user_obj = user_obj
end
def run(params_hash)
Rails.logger.warn %Q|[AutomatedAction]: #{@controller.name}##{@controller_action}(#{params_hash.inspect})|
extend_with_autorun unless @controller_instance.respond_to?(:autorun)
@controller_instance.autorun(@controller_action, params_hash, @env_obj, @user_obj)
end
private
def extend_with_autorun
def @controller_instance.autorun(action_name, action_params, action_env, current_user_value=nil)
self.params = action_params # suppress strong parameters exception
self.request = ActionDispatch::Request.new(action_env)
self.response = ActionDispatch::Response.new
define_singleton_method(:current_user, -> { current_user_value })
send(action_name) # do it
return StatusObject.new(true, nil)
rescue Exception => e
return StatusObject.new(false, e)
end
end
end