我们正在为一个项目测试不同AWS RDS MySQL示例的性能，重点是处理可能大量的并发连接。我们已经在t2.micro、t3.micro、t2.small和t3.small示例上进行了1、2、5、10、20和30个并发连接的延迟测试。
令人惊讶的是，我们发现在所有示例中20个或更多并发连接时，延迟性能一致下降，并且每个实验的延迟性能在所有示例中相似。我们曾期望从t2升级到t3（使用额外的CPU）以及从微型示例升级到小型示例类型会提高性能，但事实似乎并非如此。
我们现在想知道，除了简单地扩展示例大小之外，是否还有其他因素会影响并发性能。是什么原因导致了这种行为？我们如何提高高并发连接负载的性能？虽然这目前还不是一个紧迫的问题，但我们对这些示例如何工作感到好奇，并希望为任何潜在的未来问题做好准备。
edit：测试设置-使用API创建Lambda函数。lambda函数运行MySQL查询。进行并行API调用，并在每次测试中收集数据。测试用例（10个测试，每个API调用的平均执行时间）-
- 1个并行API调用：0.25平均值/呼叫
- 2并发API调用：0.24平均值/呼叫
- 3并发API调用：0.24平均值/呼叫
- 5并发API调用：0.28平均值/呼叫
- 10并发API调用：0.36平均值/呼叫
- 20个并行API调用：1.16平均/呼叫
- 50并发API调用：2.16平均/呼叫
1条答案
按热度按时间mklgxw1f1#
延迟性能在所有示例上的20个或更多并发连接时一致下降，
这是MySQL的一个事实。
MySQL为每个连接提供了平等的机会。而且，由于这些连接（大概）都在争夺相同的资源和数据，它们会互相绊倒（特别是在人为的基准测试中）。
请注意，现成的基准测试程序往往会准确地查找您发现的内容--产品将在何处中断。一个涉及 * 你的 * 应用程序的基准测试将指出[可能]你没有问题，因为你真的不打算那么努力地磅数据库。1000个用户[通常]没有问题，因为他们以人类的速度运行，而不是基准速度。
例如，一个用户连接，然后在他们按下“提交”按钮之前几秒钟。如果应用程序设计得很好，在返回给用户阅读结果之前，CPU只需要5- 50 ms的工作。也就是说，一个CPU chan可以 * 按顺序 * 处理数百个用户。
“顺序地”比试图实现“并发”的基准更接近现实。