使用 Redis RDB 的 Hangfire 作业创建吞吐量性能答案

【问题标题】：Hangfire job creation throughput performance with Redis RDB使用 Redis RDB 的 Hangfire 作业创建吞吐量性能
【发布时间】：2021-08-22 12:00:14
【问题描述】：

在官方documentation 中，有一张图表显示，使用 Redis RDB 创建作业的吞吐量可能约为每秒 6000 个作业。我尝试过不同的 Hangfire、Redis 和 HW 配置，但我总是每秒最多获得大约 200 个作业。我什至创建了简单的example 来重现它（Hangfire configuration、job creation）。

我做错了吗？您获得的作业创建吞吐量性能如何？

我正在使用最新版本：Hangfire 1.7.24、Hangfire.Pro 2.3.0、Hangfire.Pro.Redis 2.8.10 和 Redis 6.2.1。

【问题讨论】：

标签： redis hangfire

【解决方案1】：

关键是在引用的示例应用程序中，后台作业是按顺序创建的，一个接一个。在这种情况下，由于 I/O 延迟（到存储的往返），后台作业的创建速度不够快，从而导致更好的吞吐量。而且由于还有对 Hangfire.Console 的调用需要更多 I/O，因此创建过程执行得更慢。

尝试在Parallel.For 循环中创建后台作业，以并行创建后台作业并分摊延迟。并尝试在启动服务器之前创建所有后台作业，以明确区分 created/sec 和 performed/sec 指标，如下所示，否则一切都会混淆.

var sw = Stopwatch.StartNew();

Parallel.For(0, 100000, new ParallelOptions { MaxDegreeOfParallelism = Environment.ProcessorCount }, i =>
{
    BackgroundJob.Enqueue(() => Empty());
});

Console.WriteLine(sw.Elapsed);

using (new BackgroundJobServer())
{
    Console.ReadLine();
}

在我的开发机器上，我有 7.7 秒的时间来创建 100,000 个后台作业（约 13,000 个作业/秒），仪表板 UI 告诉我执行速度为约 3,500 个作业/秒，这比图表上显示的要低一些，但是这是因为现在 Hangfire 中的扩展过滤器比 6 年前创建该图表时要多。如果我们用GlobalJobFilters.Filters.Clear() 清除它们，我们将获得大约 4,000 个工作/秒。

为了避免混淆，我今天从这些图表中删除了绝对数字。对于不同的环境，绝对数字是不同的，例如内部部署（可以更快）和云（会更慢）。创建该图表是为了显示 SQL Server 和 Redis 在不同模式下的相对差异，在不同的环境中大致相同，而不是显示取决于很多因素的精确数字，尤其是在涉及网络的情况下。

【讨论】：