epi*_*ian 15 ruby activerecord ruby-on-rails
在我们的Rails应用程序中,我们需要使用不同的数据库,具体取决于请求的子域(每个国家/地区的DB不同).
现在我们正在做类似于这个问题的建议.也就是说,呼叫ActiveRecord::Base.establish_connection
每个请求.
但它似乎 ActiveRecord::Base.establish_connection
丢弃了当前的连接池,并在每次调用时建立新的连接.
我做了这个快速基准测试,看看establish_connection
每次调用和建立连接之间是否有任何显着差异:
require 'benchmark/ips'
$config = Rails.configuration.database_configuration[Rails.env]
$db1_config = $config.dup.update('database' => 'db1')
$db2_config = $config.dup.update('database' => 'db2')
# Method 1: call establish_connection on each "request".
Benchmark.ips do |r|
r.report('establish_connection:') do
# Simulate two requests, one for each DB.
ActiveRecord::Base.establish_connection($db1_config)
MyModel.count # A little query to force the DB connection to establish.
ActiveRecord::Base.establish_connection($db2_config)
MyModel.count
end
end
# Method 2: Have different subclasses of my models, one for each DB, and
# call establish_connection only once
class MyModelDb1 < MyModel
establish_connection($db1_config)
end
class MyModelDb2 < MyModel
establish_connection($db2_config)
end
Benchmark.ips do |r|
r.report('different models:') do
MyModelDb1.count
MyModelDb2.count
end
end
Run Code Online (Sandbox Code Playgroud)
我运行这个脚本rails runner
并指向一个本地mysql,在DB上有几千条记录,结果似乎表明这两种方法之间存在相当大的差异(一个数量级)(BTW,i'我不确定基准是否有效或我搞砸了,结果是误导的):
Calculating -------------------------------------
establish_connection: 8 i/100ms
-------------------------------------------------
establish_connection: 117.9 (±26.3%) i/s - 544 in 5.001575s
Calculating -------------------------------------
different models: 119 i/100ms
-------------------------------------------------
different models: 1299.4 (±22.1%) i/s - 6188 in 5.039483s
Run Code Online (Sandbox Code Playgroud)
所以,基本上,我想知道是否有办法维护每个子域的连接池,然后重新使用这些连接,而不是在每个请求上建立新的连接.为每个子域建立我的模型的子类是不可行的,因为有许多模型; 我只是想改变所有模型的连接(in ActiveRecord::Base
)
epi*_*ian 11
好吧,我一直在深入研究这一点,并设法让一些工作.
看完后tenderlove的帖子有关连接管理ActiveRecord的,这也解释了类层次结构如何被不必要地加上连接管理,我明白了为什么在做什么,我想在没有直接的做正如人们所期望的那样.
我最终做的是继承ActiveRecord的ConnectionHandler并在模型层次结构的顶部使用新的连接处理程序(需要一些摆弄ConnectionHandler 代码才能理解它在内部的工作方式;所以当然这个解决方案可能与Rails非常相关版我正在使用(3.2)).就像是:
# A model class that connects to a different DB depending on the subdomain
# we're in
class ModelBase < ActiveRecord::Base
self.abstract_class = true
self.connection_handler = CustomConnectionHandler.new
end
# ...
class CustomConnectionHandler < ActiveRecord::ConnectionAdapters::ConnectionHandler
def initialize
super
@pools_by_subdomain = {}
end
# Override the behaviour of ActiveRecord's ConnectionHandler to return a
# connection pool for the current domain.
def retrieve_connection_pool(klass)
# Get current subdomain somehow (Maybe store it in a class variable on
# each request or whatever)
subdomain = @@subdomain
@pools_by_subdomain[subdomain] ||= create_pool(subdomain)
end
private
def create_pool(subdomain)
conf = Rails.configuration.database_configuration[Rails.env].dup
# The name of the DB for that subdomain...
conf.update!('database' => "db_#{subdomain}")
resolver = ActiveRecord::Base::ConnectionSpecification::Resolver.new(conf, nil)
# Call ConnectionHandler#establish_connection, which receives a key
# (in this case the subdomain) for the new connection pool
establish_connection(subdomain, resolver.spec)
end
end
Run Code Online (Sandbox Code Playgroud)
这仍然需要一些测试来检查实际上是否有性能提升,但我在本地Unicorn服务器上运行的初始测试表明存在.
归档时间: |
|
查看次数: |
5432 次 |
最近记录: |