Shoryuken作为ActiveJob后端入队作业延迟过高问题咨询

Shoryuken本身不会默认存在5秒级别的入队延迟，你遇到的情况属于异常现象，以下是具体的排查方向：

1. AWS SQS底层问题 #

因为Shoryuken依赖AWS SQS，优先排查SQS相关因素：

• 检查应用服务器所在区域与SQS队列的区域是否一致，跨区域访问会带来明显的网络延迟。
• 确认SQS的请求配额是否被触发，若每秒请求数超过队列限制，会导致请求排队等待。
• 测试应用服务器到SQS的网络链路稳定性，比如用AWS CLI执行aws sqs get-queue-url --queue-name test-queue，查看命令的执行耗时，判断是否存在网络层面的延迟。

2. Shoryuken配置问题 #

• 查看config/shoryuken.yml中的client_options，是否设置了不合理的超时、重试参数，比如过多的重试次数会导致请求失败后反复重试，拉长总耗时。
• 检查是否开启了批量入队功能，若配置了批量等待时间（比如batch_delay），Shoryuken会攒够一定数量的作业才发送，这会导致单条作业的入队延迟。

3. ActiveJob集成环节问题 #

• 尝试绕过ActiveJob，直接用Shoryuken原生API入队测试：

  Shoryuken::Client.queues('test-queue').send_message(message_body: 'test')
  

  如果原生API调用延迟正常，说明问题出在ActiveJob的集成或自定义中间件上。
• 检查是否有自定义的ActiveJob中间件在入队前执行了耗时操作，比如复杂的参数校验、数据库查询等。

4. 应用环境性能瓶颈 #

• 测试时应用服务器是否处于高负载状态（CPU、内存使用率过高），进程资源不足会导致入队请求无法及时处理。
• 排查入队代码所在的上下文是否有其他耗时操作，比如同一请求中包含慢数据库查询、外部API调用，这些操作会阻塞入队流程。

5. 日志与精准调试 #

• 开启Shoryuken的debug级日志（在配置文件中设置log_level: debug），查看入队过程中的具体耗时步骤，比如作业序列化、SQS请求的响应时间。
• 用Benchmark工具精准测量入队代码的耗时：

  require 'benchmark'
  
  def self.tryFunc()
    puts Time.now
    duration = Benchmark.measure do
      SecondJob.perform_later('message')
    end
    puts "入队实际耗时: #{duration.real.round(2)} 秒"
    puts Time.now
  end
  

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