Rails API应用Searchkick关联查询性能异常排查求助

1. 先厘清Searchkick日志耗时与took值的差异原因 #

Searchkick日志里的14602ms是从发起请求到拿到响应的全链路耗时，包含Rails到Opensearch的网络往返、Opensearch内部处理、Searchkick对响应的序列化/反序列化；而took值638ms只是Opensearch内部处理查询的时间。两者差异大，重点排查：

• 网络延迟：直接用curl测试Opensearch接口的响应时间，确认链路耗时：

  curl -XGET 'http://你的Opensearch地址:9200/records_development/_search?q=*&size=10000' -w "%{time_total}\n"
  

• Searchkick反序列化开销：load:false时，Searchkick会把Opensearch返回的JSON转成Searchkick::HashWrapper对象，10000条数据的转换可能产生额外耗时。可以在控制台手动测试这个环节：

  # 直接调用Opensearch客户端获取原始响应
  raw_response = Record.searchkick_client.search(
    index: Record.searchkick_index.name,
    body: {"query":{"bool":{"must":{"match_all":{}},"filter":[{"bool":{"must":[{"bool":{"filter":[{"terms":{"record_type":["repository","knowledgebase","knowledgebase_and_repository"]}}]}}]}}]}},"timeout":"11000ms","size":10000}
  )
  puts "Opensearch内部处理时间: #{raw_response['took']}ms"
  # 测试Searchkick反序列化耗时
  start = Time.now
  Searchkick::Results.new(Record, raw_response, {load: false})
  puts "Searchkick反序列化时间: #{(Time.now - start)*1000}ms"
  

2. 排查总耗时超出各环节之和的原因 #

开发日志显示Opensearch(10ms)+PostgreSQL(7500ms)+JSON渲染(10ms)=7520ms，但总耗时12000ms，差了4480ms，重点查这些点：

• 模型回调与关联加载：load:true时，PostgreSQL查询出Record对象后，可能触发after_find/after_initialize回调，或者JSON序列化时自动加载了未声明的关联（N+1问题）。用Bullet gem检测N+1，或者在序列化器里严格控制返回字段：

  class RecordSerializer < ActiveModel::Serializer
    attributes :id, :abbreviation, :record_type
    # 不要include未用到的关联字段
  end
  

• 冗余中间件开销：纯API应用可能不需要ActionDispatch::Cookies、ActionDispatch::Session::CookieStore等中间件，在config/application.rb中移除：

  config.middleware.delete ActionDispatch::Cookies
  config.middleware.delete ActionDispatch::Session::CookieStore
  

• 全链路性能 profiling：用rack-mini-profiler或ruby-prof定位具体耗时点：
  • 安装rack-mini-profiler后，访问API时查看顶部的profiler数据，明确中间件、控制器、模型方法的耗时占比。
  • 用ruby-prof在控制台生成调用栈分析：

    require 'ruby-prof'
    RubyProf.start
    results = Record.search('*', where: { _and: [{:record_type=>["repository", "knowledgebase", "knowledgebase_and_repository"]}]}, load: false)
    results.to_a # 触发实际查询与反序列化
    profile = RubyProf.stop
    printer = RubyProf::FlatPrinter.new(profile)
    printer.print(STDOUT)
    

3. 解决load:false后耗时暴增到60秒的问题 #

load:false跳过PostgreSQL查询但浏览器端耗时暴增，核心原因是数据处理或传输成本过高：

• 减少返回数据量：在Searchkick查询中指定仅返回业务需要的字段，避免Opensearch返回大量元数据：

  results = Record.search('*', 
    where: { _and: [{:record_type=>["repository", "knowledgebase", "knowledgebase_and_repository"]}]},
    load: false,
    fields: [:id, :abbreviation, :record_type] # 只返回必要字段
  )
  

• 分页返回数据：一次性返回10000条数据会导致网络传输和前端解析耗时飙升，改为分页：

  results = Record.search('*', 
    where: { _and: [{:record_type=>["repository", "knowledgebase", "knowledgebase_and_repository"]}]},
    load: false,
    fields: [:id, :abbreviation, :record_type],
    page: params[:page],
    per_page: 100
  )
  

4. 优化PostgreSQL的IN查询耗时 #

PostgreSQL执行select * from records where id in (...)耗时7500ms，可通过以下方式优化：

• 确认id字段存在主键索引（默认已创建，可通过\d records命令验证）。
• 当IN列表过长（如10000个ID），改用ANY语法提升查询效率：

  ids = results.map(&:id)
  records = Record.where("id = ANY(ARRAY[?])", ids)
  

• 若必须加载ActiveRecord对象，用includes明确预加载关联（无关联则传空数组，避免自动加载）：

  results = Record.search('*', 
    where: { _and: [{:record_type=>["repository", "knowledgebase", "knowledgebase_and_repository"]}]},
    load: true,
    includes: []
  )
  

内容的提问来源于stack exchange，提问作者knirirr