负载/压力测试方法。预期结果如何以及如何解释结果？

Question

我们有一位新客户，我们正在为其审查我们的服务器基础设施。

我非常了解 Web API，因为我曾参与构建它，现在我自己负责维护和推动它的发展，所以挑战很大而且非常有趣。

它目前基于 Amazon m1.large 实例、nginx（+ssl）、django、amazon RDS（带有 MySQL）和自托管 memcached。

问题是，我们得到了一些来自客户的意见，他们说他们预计最多有 2500 名用户每天至少两次、每次持续四小时地连接 API。

我们不知道这些连接究竟何时会出现，我们也不应该做任何假设，所以我最终想到的是，我们的服务器最好能够同时支持 2500 个连接。

我一直在研究 apache 基准测试，在连接/断开 memcache 或某些 nginx 设置的同时发送 2500 个并发连接，只是为了看看性能的变化。

我得到的最好结果是每秒大约 100 个请求，但最长的请求需要 20 多秒（对于 2500 个并发连接，只有 100 个请求最多需要 1 秒）。从用户的角度来看，我不希望等待超过 1 或 2 秒才能获得结果...

我希望更多地使用我可以调整 nginx、django、mysql 或 memcache 上的所有设置，但此时我认为我需要一种方法论，而且不仅仅是一种方法论，我还需要一个要达到的目标。

在网上搜索时，我看到博客文章谈论每秒可达到数百个请求的服务。我离那还差得很远。

看到 apachebench 得出的所有这些数字只是给我一种印象，即我正在启动测试，查看结果，但我并不真正理解它们，也不知道如何处理它们来改进我们的 API。

那么，什么是好的方法、好的方法，可以实现让 Web API 能够尽快处理如此多的连接这一目标？

如果您需要更多详细信息，请询问！

Answer 1

我从未使用过 Django 设置，因此可能无法了解 Django 的具体细节。如果您可以提供每秒达到 100 个请求时的 CPU、IO、内存统计信息，那就太好了。根据资源紧缺的性质，您可能会因为各种原因而获得 20 秒的延迟。如果不知道系统在压力下的健康状况，您可能无法理解性能统计数据。一个好的起点可能是 Amazon CloudWatch 指标和/或使用 Munin、Nagios 或类似工具以及适当的图形工具（如 Graphite 或 Ganglia）启用监控。即使是跟踪vmstat输出也可以揭示很多东西。

识别问题的关键是收集足够的系统健康数据并跟踪这些数据。您可以简单地在 Graphite 上绘制流量趋势图以及其他统计数据（例如 CPU 使用率、IO 等待、上下文切换、中断数、可用内存），并尝试将这些数据关联起来。您甚至可以将请求周期分为数据库、中间件和渲染阶段，并跟踪每个阶段所花费的时间。

1. 检查数据库查询是否缓慢。我对此不太确定，但 RDS 可能会为您提供有关慢查询的统计数据。您可能需要优化这些统计数据。
2. 如果 CPU 造成瓶颈，并且您在高峰流量期间看到 CPU 峰值，您可能需要在高峰期间检查进程统计信息，并集中精力处理占用 CPU 的进程，从而导致您的 Web 服务器在一段时间内不可用（导致 20 秒延迟）。此外，您可以想出优化该进程的措施，如果这不可能，您可能需要切换到 c1.xlarge 实例。
3. 如果您的服务器在高峰流量期间遇到内存紧缩并显示可用内存不足，您可以检查应用程序中哪些区域占用大量内存。您可能希望优化这些区域和/或通过将实例升级为高内存替代方案来投入更多内存。此外，您甚至可以考虑调整应用程序代码，使内存受限的进程受 CPU 限制。通常在内存紧缩期间 CPU 利用率不足。
4. 如果您的服务器的 CPU 利用率不足，甚至没有看到内存紧缩，那么您的系统很有可能在 IO 等待中花费了大量时间。这可能是由于任何依赖项中的延迟造成的。还要使用 检查峰值负载期间上下文切换和中断的数量vmstat。如果您选择运行的工作进程数量多于可用内核数量，则可能会发生这种情况。服务器也可能正在等待块 IO。有些人在使用 EBS 时经历过块 IO 延迟，但我对此并不介意。

希望这可以帮助。

Answer 2

首先，您需要确定此 Web 服务的瓶颈是什么。可能是数据库查询速度慢和/或 Django 性能差。请注意，大多数用于快速 Web 应用程序开发的框架（Django 性能) 并没有真正针对速度进行优化。除非您能够负担得起使用多台服务器和负载平衡，否则您真的不能指望有出色的性能。

无论如何...首先我会尝试：

1. 检查关键 SQL 查询的速度，并在必要时优化查询。考虑使用 memcached 来缓存 SQL 查询的结果（你可能需要为此对代码进行一些更改）。
2. 测试 django 可以处理多少个请求（有和没有数据库查询）
3. 检查典型请求/响应的大小，并问问自己您的硬盘驱动器/连接是否可以处理这种流量。使用 iotop 等 I/O 监控可能会有所帮助。
4. 检查您的 CPU 是否能处理这种流量 - 使用 top 命令。