我在 puma 上运行了一个简单的 rails 应用程序，其前面有一个以标准方式配置的 nginx 代理服务器。它们在 aws t2.micro 实例上运行。
mysql db 正在另一个 t2.micro 实例上运行。
如果我对具有 20 个并发登录的简单登录用例运行 jmeter 负载测试，我会得到以下结果：
summary + 1 in 00:00:03 = 0.3/s Avg: 2542 Min: 2542 Max: 2542 Err: 0 (0.00%) Active: 20 Started: 20 Finished: 0
summary + 79 in 00:00:06 = 13.7/s Avg: 1734 Min: 385 Max: 3246 Err: 0 (0.00%) Active: 0 Started: 20 Finished: 20
summary = 80 in 00:00:09 = 9.2/s Avg: 1744 Min: 385 Max: 3246 Err: 0 (0.00%)
当我使用 100 个并发登录运行相同的测试时，我得到以下结果：
summary + 362 in 00:00:14 = 25.0/s Avg: 2081 Min: 381 Max: 9730 Err: 0 (0.00%) Active: 21 Started: 100 Finished: 79
summary + 38 in 00:00:13 = 3.0/s Avg: 4887 Min: 625 Max: 17995 Err: 0 (0.00%) Active: 0 Started: 100 Finished: 100
summary = 400 in 00:00:27 = 14.8/s Avg: 2347 Min: 381 Max: 17995 Err: 0 (0.00%)
平均和最大响应时间增加了 2-5 倍。这并不奇怪，但当我查看服务器 CPU 和内存负载时，我找不到瓶颈。测试时间范围内的最大 CPU 使用率为 36%，内存消耗几乎没有变化（增加了 5MB）。
我的问题是：实际瓶颈在哪里？扩展策略是什么？将美洲豹工作者放在单独的 EC2 实例上？
我对设置这样的服务器不是很有经验，所以欢迎所有提示。
答案1
值得深思的是：
- 您只检查了有限资源模型中的两个项目：CPU 和内存。您忽略了与磁盘和网络相关的项目。
- 如果您在 AWS 内部的虚拟机上运行 JMETER 实例，以避免来自 Amazon 外部的负载产生费用，那么您需要考虑虚拟机上称为“时钟跳跃”的问题，该问题会影响您的响应时间数据。系统时钟在客户操作系统内部虚拟化。当系统使用时，它会变慢，并且必须定期与虚拟机管理程序主机基准时钟重新同步。您既不知道何时发生这种情况，也不知道何时可以控制这种情况。它的表现形式是测试运行中的平均和最大计时记录更长，因为当事件的计时记录打开时，确实会发生此时钟重新同步。您可以使用测试设计中在物理硬件上运行的控制元素（例如控制负载生成器）来检查这一点。控制元素的结果应该有助于说明非控制集的数据偏差量。
- 您正在虚拟机中运行，由于虚拟机管理程序向客户操作系统报告正在使用的内容的方式，因此很难获得实际使用资源的高精度数字。
- 这时代码分析器或深度诊断工具就派上用场了。您需要明确查找资源分配过早、代码调用过于频繁或在代码中释放资源之前时间过长等情况。性能工程师在优化给定业务流程时，会从这种过早、过于频繁和过于漫长的角度来查找代码，因为这些情况在生产中很容易出现响应时间和可扩展性问题。