在 ASP.NET Core 中测量异步与同步代码的性能

Question

我正在尝试使用 SQL Server Express 和 EF Core 3.1.3 测量 ASP.NET Core 3.1 中异步与同步的性能，并且有两个功能完全相同，除了一个是异步的，一个是同步的：

[HttpGet("search/description/{searchString}")]
public async Task<ActionResult<IEnumerable<Products>>> SearchForProductsDescription(String searchString) {
    return await _context.Products.Where(p => p.Description == searchString).ToListAsync();
}

还有同步版本：

return _context.Products.Where(p => p.Description == searchString).ToList();

我使用 jmeter 作为基准工具，同步函数比异步函数快（如预期的那样），但是当我增加 jmeter 中的线程数使平均响应时间为 500 毫秒时，同步代码是还是更快。我已经尝试在数据库中使用 1000 行和 20000 行，但它仍然更快。我正在尝试找到一种异步函数比同步函数更快但我遇到问题的场景，是否有什么我弄错或误解的地方？

Answer 1

从 cmets 看来，您似乎知道 async 允许 Web 服务器通过不显式等待响应而不是加快查询速度来保持响应速度更快。在同步和异步调用之间的并列示例中，异步调用会稍微慢一些，因为需要设置来切换和恢复。所以不会有你可以运行的性能测试来显示任何改进。异步是为了让服务器对负载更敏感。

假设一个 Web 服务器有 100 个工作线程处理请求。每次用户连接到您的网站、刷新页面等时，他们都会被交给工作人员。在任何一个时间点，都可以处理 100 个请求。如果第 101 个请求在所有其他线程都忙于处理请求时出现，可能会发生以下两种情况之一：分配了一个额外的线程（与其他 100 个竞争资源和时间，并且需要时间来分配额外的线程）或请求等待线程被释放。由于您可能会有一些可能需要一秒钟左右的请求操作，因此大多数请求可能需要几毫秒才能运行，所以总的来说，当并发请求超过 100 个时，这只是一个值得注意的问题，因为他们坐着等工人。

假设有一个特定的报告会在数百万行和大量表中产生一些非常强大的 SQL 调用。例如 EOFY 类型的报告或季度报告。这些报告通常不会那么频繁地运行，但是当它们运行时，它可能会在特定时间由相当数量的人运行。 （例如财政年度的第一周）每个查询需要 10+ 秒才能运行，数据库本身只能处理这么多请求，所以第一个查询可能是 10 秒，但会阻止其他查询，因此平均它可能会推动 30 甚至 60 秒.现在，当有 100 个请求进来时，每个线程都会被占用 30 多秒。由于线程已用尽，您的网站变得无响应。异步查询有助于适应这一点。请求仍然需要大约 30 秒，但 Web 服务器释放了侦听工作线程，以便它可以响应其他请求，其中许多不会触发报告，但会在线程池填满时等待。

因此，要实际观察这样的事情，您需要一个特别昂贵的操作，固定可用工作线程的数量，并启动超过这些请求数的负载测试。例如，将 Web 服务器限制为 5 个线程，启动 5 个昂贵的请求，然后启动一个额外的“廉价”请求并测量该廉价请求的响应能力。使用同步代码，该廉价请求将等待释放其中一个线程。使用异步代码，最后一个请求的处理速度会快得多。到目前为止，您的尝试看起来有点缺陷，因为您的所有请求都执行相同的调用并期望性能提升。它不会，它是关于更小、更简单的请求被挂起，等待更长的请求完成。如果您的查询太简单（快速），则没有什么可观察的。您需要一个需要几秒钟才能运行的查询，然后将其与通常需要几毫秒的请求混合。

异步不是网站性能的灵丹妙药。调试起来可能会更难，而且它本身就有点慢。通常，您会看到到处都使用它以保持一致性的示例，或者实际上没有任何好处的简单示例。我的一般建议是默认使用同步调用，并为特别昂贵的操作保存异步调用。例如，通过 ID 加载单个记录我的目标是保持同步，但搜索，特别是涉及文本匹配或涉及非索引列或复杂关联，我将进行异步。通常会有一些例子需要不同的实现，我什至不会依赖异步。例如上面的示例，EOFY 类型的报告可能需要几秒钟才能运行：类似这样的事情，我希望为由显式后台工作程序（或池）处理的报告请求实现一个队列，并使用指向报告副本的 DBContext帮助确保不会并行运行太多请求，并且不会阻止对主应用程序数据库的读写访问。如果大多数请求有可能同时触发该操作，那么简单地在昂贵的查询上打 async 并不会减少它。您可以释放您的 Web 服务器线程池，但仍然会在链的下游造成瓶颈。

Answer 2

我正在尝试寻找一种异步函数比同步函数更快但我遇到问题的场景，我是否有什么错误或误解？

是的。异步代码不应该更快。它应该需要更少的线程。如果您有 10000 个并发请求，您可能会在同步过程中看到资源（内存、句柄、线程、CPU）耗尽。但在这发生之前，您的数据库就会崩溃。

EF 异步数据访问本身并不是为了提高数据访问的性能，而是为了符合更喜欢异步 IO 的应用程序框架的要求，例如具有单个 UI 线程的桌面应用程序或使用 ASP 的 Web 应用程序。 NET 核心。

EF 中的异步有时对于并行发送多个查询或在您等待长时间运行的数据库操作时运行一些其他代码也很有用。

这是一个综合演示，对于大量并发调用，当线程池小于并发请求数时，异步可以快得多。

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Threading;
using System.Threading.Tasks;

namespace AsyncDemo
{
    class Program
    {
        static async Task DoStuffAsync()
        {
            await Task.Delay(20);
        }

        static void DoStuffSync()
        {
            Thread.Sleep(20);
        }
        static void Main(string[] args)
        {
            var sw = new Stopwatch();
            List<Task> tasks;
            var iterations = 1000 * 5;

            while (true)
            {
                sw.Restart();
                tasks = new List<Task>();
                for (int i = 0; i < iterations; i++)
                {
                    tasks.Add(Task.Run(() => DoStuffSync()));
                }
                Task.WaitAll(tasks.ToArray());
                Console.WriteLine($"{iterations} sync calls {sw.ElapsedMilliseconds}ms {Process.GetCurrentProcess().Threads.Count} threads");

                tasks = new List<Task>();
                sw.Restart();
                for (int i = 0; i < iterations; i++)
                {
                    tasks.Add(DoStuffAsync());
                }
                Task.WaitAll(tasks.ToArray());
                Console.WriteLine($"{iterations} async calls {sw.ElapsedMilliseconds}ms {Process.GetCurrentProcess().Threads.Count} threads");

            }

        }
    }
}

输出

5000 sync calls 5546ms 35 threads
5000 async calls 29ms 35 threads
5000 sync calls 3951ms 51 threads
5000 async calls 38ms 51 threads
5000 sync calls 3481ms 52 threads
5000 async calls 29ms 52 threads
5000 sync calls 3320ms 53 threads
5000 async calls 34ms 53 threads
5000 sync calls 3259ms 53 threads
5000 async calls 32ms 53 threads
5000 sync calls 3253ms 53 threads
5000 async calls 33ms 53 threads
5000 sync calls 3321ms 53 threads
5000 async calls 31ms 53 threads
5000 sync calls 3275ms 53 threads
5000 async calls 33ms 53 threads
5000 sync calls 3259ms 51 threads
5000 async calls 28ms 51 threads