![负载/压力测试方法。预期结果如何以及如何解释结果?](https://linux22.com/image/797457/%E8%B4%9F%E8%BD%BD%2F%E5%8E%8B%E5%8A%9B%E6%B5%8B%E8%AF%95%E6%96%B9%E6%B3%95%E3%80%82%E9%A2%84%E6%9C%9F%E7%BB%93%E6%9E%9C%E5%A6%82%E4%BD%95%E4%BB%A5%E5%8F%8A%E5%A6%82%E4%BD%95%E8%A7%A3%E9%87%8A%E7%BB%93%E6%9E%9C%EF%BC%9F.png)
我们有一位新客户,我们正在为其审查我们的服务器基础设施。
我非常了解 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 能够尽快处理如此多的连接这一目标?
如果您需要更多详细信息,请询问!
答案1
我从未使用过 Django 设置,因此可能无法了解 Django 的具体细节。如果您可以提供每秒达到 100 个请求时的 CPU、IO、内存统计信息,那就太好了。根据资源紧缺的性质,您可能会因为各种原因而获得 20 秒的延迟。如果不知道系统在压力下的健康状况,您可能无法理解性能统计数据。一个好的起点可能是 Amazon CloudWatch 指标和/或使用 Munin、Nagios 或类似工具以及适当的图形工具(如 Graphite 或 Ganglia)启用监控。即使是跟踪vmstat
输出也可以揭示很多东西。
识别问题的关键是收集足够的系统健康数据并跟踪这些数据。您可以简单地在 Graphite 上绘制流量趋势图以及其他统计数据(例如 CPU 使用率、IO 等待、上下文切换、中断数、可用内存),并尝试将这些数据关联起来。您甚至可以将请求周期分为数据库、中间件和渲染阶段,并跟踪每个阶段所花费的时间。
- 检查数据库查询是否缓慢。我对此不太确定,但 RDS 可能会为您提供有关慢查询的统计数据。您可能需要优化这些统计数据。
- 如果 CPU 造成瓶颈,并且您在高峰流量期间看到 CPU 峰值,您可能需要在高峰期间检查进程统计信息,并集中精力处理占用 CPU 的进程,从而导致您的 Web 服务器在一段时间内不可用(导致 20 秒延迟)。此外,您可以想出优化该进程的措施,如果这不可能,您可能需要切换到 c1.xlarge 实例。
- 如果您的服务器在高峰流量期间遇到内存紧缩并显示可用内存不足,您可以检查应用程序中哪些区域占用大量内存。您可能希望优化这些区域和/或通过将实例升级为高内存替代方案来投入更多内存。此外,您甚至可以考虑调整应用程序代码,使内存受限的进程受 CPU 限制。通常在内存紧缩期间 CPU 利用率不足。
- 如果您的服务器的 CPU 利用率不足,甚至没有看到内存紧缩,那么您的系统很有可能在 IO 等待中花费了大量时间。这可能是由于任何依赖项中的延迟造成的。还要使用 检查峰值负载期间上下文切换和中断的数量
vmstat
。如果您选择运行的工作进程数量多于可用内核数量,则可能会发生这种情况。服务器也可能正在等待块 IO。有些人在使用 EBS 时经历过块 IO 延迟,但我对此并不介意。
希望这可以帮助。
答案2
首先,您需要确定此 Web 服务的瓶颈是什么。可能是数据库查询速度慢和/或 Django 性能差。请注意,大多数用于快速 Web 应用程序开发的框架(Django 性能) 并没有真正针对速度进行优化。除非您能够负担得起使用多台服务器和负载平衡,否则您真的不能指望有出色的性能。
无论如何...首先我会尝试:
- 检查关键 SQL 查询的速度,并在必要时优化查询。考虑使用 memcached 来缓存 SQL 查询的结果(你可能需要为此对代码进行一些更改)。
- 测试 django 可以处理多少个请求(有和没有数据库查询)
- 检查典型请求/响应的大小,并问问自己您的硬盘驱动器/连接是否可以处理这种流量。使用 iotop 等 I/O 监控可能会有所帮助。
- 检查您的 CPU 是否能处理这种流量 - 使用 top 命令。