我们正在测试一个项目的不同 AWS RDS MySQL 实例的性能，重点是处理潜在的大量并发连接。我们在 t2.micro、t3.micro、t2.small 和 t3.small 实例上进行了 1、2、5、10、20 和 30 个并发连接的延迟测试。
令人惊讶的是，我们发现所有实例中的延迟性能在 20 个或更多并发连接时持续下降，并且每个实验的延迟性能在所有实例中都相似。我们原本预计从 t2 升级到 t3（带有额外的 CPU）以及从微型实例类型升级到小型实例类型会提高性能，但事实似乎并非如此。
我们现在想知道除了简单地扩大实例大小之外，是否还有其他因素会影响并发性能。是什么原因导致这种行为？我们如何提高高并发连接负载的性能？虽然这目前不是一个紧迫的问题，但我们很好奇这些实例是如何工作的，并希望为未来任何潜在的问题做好准备。
编辑： 测试设置 - Lambda 函数是使用 API 创建的。 lambda 函数运行 MySQL 查询。 每次测试都会进行并发 API 调用并收集数据。 测试用例（10 个测试，每个 API 调用的平均执行时间）-
所有实例中存在 20 个或更多并发连接时，延迟性能持续下降，
这是 MySQL 的事实。
MySQL 为每个连接提供平等的机会。 而且，由于这些连接[可能]迫切需要相同的资源和数据，因此它们会互相绊倒[尤其是在人为的基准测试中]。
请注意，现成的基准测试程序往往会准确地查找您发现的内容——产品将在哪里出现故障。 涉及“您的”应用程序的基准测试将指出[可能]您没有问题，因为您实际上不会那么努力地处理数据库。 一千个用户[通常]没有问题，因为他们以人类速度运行，而不是基准速度。 例如，用户连接后，需要几秒钟才能按下“提交”按钮。 如果应用程序设计良好，则在返回给用户读取结果之前，CPU 工作只需完成 5-50 毫秒。 这就是说，单个 CPU 通道可以
顺序处理数百个用户。“顺序”比试图实现“并发”的基准更接近现实。