带有Sidekiq适配器的ActiveJob是否对纯Sidekiq工作者有性能问题？

问题描述

我在Sidekiq官方Wiki中看到this，ActiveJob的运行速度要慢得多。

但是根据issue，它是基于Rails 4.2和Sidekiq 5.1.1在2018年3月提到的，而最新的将是Rails 6和Sidekiq 6。

在这种情况下，仍然比使用带有Sidekiq适配器的ActiveJob更建议使用纯Sidekiq工作者吗？

解决方法

我准备了一个简单的基准测试：https://github.com/mpan-wework/sidekiq-benchmark/actions?query=workflow%3ARSpec

CreateUserJob
  behaves like Benchmark Job
"CreateUserJob-0,1601366451612"
"CreateUserJob-last,500,1601366532766"
    runs for 501 times

PureJob
  behaves like Benchmark Job
"PureJob-0,1601366532791"
"PureJob-last,1601366542691"
    runs for 501 times

CreateUserWorker
  behaves like Benchmark Worker
"CreateUserWorker-0,1601366542695"
"CreateUserWorker-last,1601366621057"
    runs for 501 times

PureWorker
  behaves like Benchmark Worker
"PureWorker-0,1601366621072"
"PureWorker-last,1601366630103"
    runs for 501 times

Finished in 2 minutes 58.5 seconds (files took 1.72 seconds to load)
4 examples,0 failures

基准测试结果通过github操作运行，其中一个postgres容器作为数据库，一个redis容器作为缓存。

Pure作业或工作程序仅包含内存命令，CreateUser作业或工作程序将通过SQL创建100个用户。

0代表要运行的第一个作业/工人的时间戳；当每个工作/工作人员完成时，都会写入其ID和结束时间以进行缓存，因此last代表最后一个工作/工作人员。

对于每种类型的工作/工作者，都有501个项目入队。

从收集的数据中，PureJob花费9.900秒，而PureWorker花费9.031秒； CreateUserJob花费81.154秒，而CreateUserWorker花费78.362秒。 Sidekiq worker比使用Sidekiq适配器的ActiveJob更快，但没有说明的那么快。

我尚未在具有多个滑轨和sidekiq吊舱的kubernetes集群上进行测试，但我想两者之间的差异并不明显。

,

ActiveJob是Sidekiq :: Worker之上的适配器层，它将始终增加开销。也就是说，版本，应用程序和用例特定的开销是多少，因此只有您可以衡量自己的系统以确定所看到的开销的类型。

基准显示，活动作业将作业推送到Redis的速度要慢2-20倍，并且处理开销约为3倍（使用Rails 5.1.4和Sidekiq 5.1.1）。

https://github.com/mperham/sidekiq/wiki/Active-Job#performance