使用涉及 SQL Server 的 API 优化响应时间答案

【问题标题】：Optimize response time from API, with SQL Server involved使用涉及 SQL Server 的 API 优化响应时间
【发布时间】：2019-08-02 08:38:39
【问题描述】：

我有一个项目，要求响应时间在 3000 个并发用户的负载下应低于 0.5 秒；

我很少有使用 SQL Server 聚合的 API。当我们用 3000CCU 测试它时，平均响应时间约为 15 秒。并且由于 SQL 无法处理这么多请求而导致的 500 错误。实际上对 SQL Server 的请求会因超时而中断）我们当前的实例是 r4.2xlarge 8CPU 和 61GB 内存。

所有代码都是异步的，没有阻塞操作。在这种情况下，我们在负载均衡器后面运行我们的应用程序，有 10 个实例，每个实例 300 CCU。实例的利用率约为 30%。目前的瓶颈是SQL server。

我看到几个解决方案。设置一些大的 SQL、集群或分片，我不太确定。我在这方面并不强。

或者对请求使用缓存。我们大多是只读数据，聚合后可以缓存。

更新： 我需要解决方案来准确缓存 sql 响应。使用 LINQ 订购延迟使用它。

但似乎没有现成的解决方案。

我找到了一个很好的尝试，叫做 CacheManager。但这几乎没有问题。

它只能在同步模式下与 Redis 一起使用，这意味着使用同步命令而不是异步。
没有实现并发锁，在我们的例子中可能会发生这种情况，因为我们有 10 个实例。我们需要可用作分布式缓存的解决方案。
很少有错误使用 Redis 多路复用器。而且您经常会遇到连接问题。

请建议如何解决这个问题。你怎么解决的。我相信有些人已经以某种方式解决了它。

【问题讨论】：

如果你在谷歌上搜索ASP.NET Core Response Caching，第一个结果是来自文档的Response caching in ASP.NET Core。
这与响应缓存无关。这是关于来自 SQL 的结果缓存。
SQL Server 也不慢。糟糕的性能通常是由错误的架构、错误的查询或错误的访问代码引起的。例如，transactional 数据库上的聚合会很慢，因为它旨在使单个事务快速进行。一个适当的报告数据库，例如使用星型模式，可以快几个数量级（即快100,100,1000 倍）。 显式事务 也可能导致阻塞和延迟。缺少索引是另一个问题
没有任何连接。只涉及一张桌子。它的时基值，我们将每分钟存储到表中。大约有8个字段。小数和日期。
It's about result cache from SQL 在这种情况下，您应该修复数据库架构。您要实现的缓存将保存 reporting 数据库将保存的相同数据。是的，结果缓存，或者更确切地说，通用缓存也可用，但是为什么可以在内存中缓存几分钟可以存储在数据库中并被每个查询重用的东西？

标签： asp.net-core

【解决方案1】：

我在 sql 上启用查询存储并监视所有丢失的索引。 Ef core 生成一些与预期完全不同的请求。创建缺失索引后，性能变得更好。但我仍然无法处理所需的 CCU。我探索了所有将 ef 核心扩展到缓存的现有解决方案。其中大部分是用同步版本编写的。这不能利用异步的所有好处。我也没有找到任何实现分布式锁的分布式缓存。最后，我创建了这个库，它扩展了 ef 核心和 redis 中的分布式缓存 .cache 允许我们进行更多扩展。现在一切都飞了；）把它留在这里，对于像我这样有性能问题的人。 https://github.com/grinay/Microsoft.EntityFrameworkCore.DistributedCache

【讨论】：