如何对API进行负载测试与调优(2)

声明

本文由Donny译自 3scale.com 的 《How to load test & tune performance on your API》

本文基于Mark在APIStrat/APIDays 柏林站的演讲,视频可以在YouTube上看,如果你可以翻墙的话。

这是如何对API进行负载测试与调优的第2部分。在第1部分中,我们聊了配置测试环境,聊了要测量的指标以及测量这些指标的不同方法。我们还了解了使用哪些测试工具,以获得有关我们的API执行情况的真实数据。

我们现在将研究如何将API安全地暴露给公众,同时确保其性能不受影响。

如何为你的API添加访问控制层

我们已经有了高性能的API了,但如果万一有人以超过16000次请求/秒的速度向服务器发送请求怎么办?你如何能防止API用户向你的API发出爆炸性请求?如果没处理好,将会影响其他用户对API的使用。

解决方法有很多,最简单的就是在你的API服务器建立限速系统。我们认为应该尽可能地降低系统之间的耦合度,所以最好在你的系统中有一个单独的层,这个单独的层专门负责处理限速。

这时候API网关就可以派上用场了。API网关是解决管理API访问问题的通用架构解决方案。它除了用来做访问控制,还可以充当协调与开放内部API不同接口的整合层。

在本文案例中,我们将使用我们自己的API网关,它与3scale平台一起使API提供商能够以安全的方式向外界开放他们的API。它可以很方便地对API接口进行身份验证与设置限速。

有几种方法可以将您的API与3scale集成,我们这里选择基于Nginx的高性能代理部署API网关。我们将会在我们的API服务器之前部署3scale API网关。使用代理的原因不仅仅是性能问题:由于它部署在我们的API之前,那些没经身份验证的或高于我们允许限制的流量请求在到达API服务器之前将会被代理拒绝掉。这让我们可以更专注考虑我们的API服务器,这样我们的API服务器就可以按我们预定的流量负载来设计,不用担心超过这个流量会有什么意外发生,其他的事就交给API网关处理。当然,万一我们的API服务器负荷处理量增加或者是用户数量意外增长时,我们也能在3scale的管理平台上调整限制设置。

作为工程师,在架构中增加扩展层要谨慎。所以我们这里的目标是确保这个扩展性不会对我们的API性能造成影响。

我们会在与我们的API服务器使用相同类型配置的AWS实例上部署网关,一个带有2个虚拟核的c4.large。设置网关很简单,我们可以借用AWS服务市场上我们的AMI映像

在3scale平台上配置好API后,我们会拿到定制的Nginx配置文件,我们用它来启动API网关。第一步将使用默认配置运行我们之前做的相同测试,请求地址要小修改一下,现在多包含了一个带有API 密钥的参数。

GET http://our-api-gateway.com/question?user_key=ABCD123

以10000次请求/秒速度运行和以前相同的测试,我们会命中几个错误。 Loader.io最终由于大量的错误停止测试。

这些都似乎是500状态码内部错误或其他未指定的网络错误。 我们查过API服务器没有返回任何错误,所以问题的源头可能是Nginx,其中日志显示大量的这些:

2015/04/12 23:07:10 [alert] 2573#0: *147508 256 worker_connections are not enough while connecting to upstream, client: …, server: , request: “GET /question HTTP/1.1”, upstream: “http://…/question”, host: “…”

Nginx需要为每个请求至少打开两个连接,一个到客户端,另一个到代理服务器。 它还需要打开连接到3scale,但不是每个请求都要连(我们用的是增强版的3scale API网关,它能批量授权和生成报告)。

考虑到这一点,以10000次请求/秒的速率,Nginx将需要保持的同时打开连接的数量将远高于256。

调整API代理网关以达最大性能

配置nginx的worker_connections可配置配置同时打开的连接数。该设置也高度依赖于底层系统:Nginx不能打开比系统可提供的套接字更多的连接。如果我们想提高数字,有几个设置要修改。

修改文件/etc/security/limits.conf:

# 如果你没配过以下参数,请在文件底部增加以下行,生效需要重启系统

* soft nofile 200000

* hard nofile 200000

修改文件/etc/sysctl.conf:

# 增加打开文件的限制数

# 改完后运行这命令以生效:  sudo sysctl -p /etc/sysctl.conf

fs.file-max = 5000000

改完以上内容后,你接下来可以修改nginx的配置文件nginx.conf:

worker_rlimit_nofile 100000;

events {

worker_connections  100000;

}

Nginx和系统级的优化还有其他一些方法,你可以在Nginx的官方文档中查阅。

在本文案例中,下面的配置修改,极大提高了网络资源的利用率:

(1)在upstream中启用Keep alive,这个需要将HTTP协议设为1.1版,这也是Node.js默认使用的版本。

(2)减少tcp_fin_timeout以最小化TIME_WAIT状态中的连接数,这样我们就不需要很多过时的连接,记得也要启用tcp_tw_reuse。

(3)将worker_processes设为auto ,这样Nginx就可为每一个可用CPU内核启动一个worker进程。

还有很多设置可以提高Web服务器的性能,特别是在系统级的设置。你可以在这里对照一下更为完整的优化配置列表。建议你要对你的系统环境有足够的了解,才能应用这些优化配置。

还有其他一些配置对负载测试环境的影响比在生产环境中影响更大,比较容易产生误导性的测试结果。比如,增加Nginx中 keepalive_requests 的值可以让一个keep-alive连接发送更多的请求。在我们的测试标准中,所有的负载生成都是从单一源发出了,如果增大这个值,明显会比负载来自多个源更有效率。

检查一下优化设置是否生效,我们可以在Loader.io上以60秒运行10000请求/秒的测试。测试结果如下:

测试结果现在没问题了,没有500错误或网络错误。我们达到了我们预期的速率。不过有点微小的差别,就是曲线在延迟增加的地方有些波峰突起,这些突起点是当Nginx需要向3scale反馈数据时发生的,这也影响了当时正要处理的几个客户端请求。网关中的报告生成是由每个客户端完成的,这就是为什么这里的影响非常明显,因为我们从单个客户端生成大量流量。此外,在测试期间这些报告成生的批处理也是相当频繁地进行。如果我们将周期设置的比测试持续时间更长,基本上我们一访问完API,结果就马上出来。

最后,我们用wrk重新来做和前面同样的测试。结果发现通过API网关的性能和我们直接访问API的性能基本一致。但还是有一个比较大的区别,我们现在在我们的API前面多了一层,这一层让我们可以控制它,可以设定速率限制,可以身份验证,可以看到API的使用情况统计分析。而这一切都不需要再修改我们的API代码。

运行1分钟测试 @ http://api-gateway/question

4 threads and 1000 connections

Thread Stats   Avg      Stdev     Max   +/- Stdev

Latency   85.27ms   90.29ms   1.27s    92.76%

Req/Sec     3.98k   588.91     4.27k    64.50%

Latency Distribution

50%  85.75ms

75%  96.61ms

90%  127.49ms

99%  230.90ms

955320 requests in 1.00m, 194.17MB read

Requests/sec:  15942.54

Transfer/sec:      3.23MB

总结

通过这两篇文章,我们讲述 如何对API进行一个有效的负载测试。我们先要配置好测试环境,为准备好测试提供了一些建议。然后我们介绍了市面上以及开源社区里的几个负载测试工具。我们测算出API能实现的峰值性能,同时在性能不受损的前提下增加了API的访问控制层。

从本文的测试中,我们总结出以几个关键点:

(1)在运行测试之前,你要先定好目标,这些目标最好是基于你目前流量数据来定的。这有助于你确定你的API要达到的性能目标线。

(2)要花点时间准备好一个可测量的稳定基线环境。如果你一开始就没弄好,你的测试结果就毫无价值。

(3)别让测试工具成为你测试的限制因素,要研究了解每个测试工具的特性(比如单线程、多线程),多个测试工具的测试可以让你更全面的了解你的API性能。

(3)当你微调了你架构中某部分组件的性能时,你需要对架构中所有部分进行观测。如果限制因素在系统级别上,那么在API层做优化调整也没用。

(4)有一个API网关管理层可以让你更安心,因为管理层可以安全保护好你的API,API只会获得可预测的流量,不会受爆炸性的意外流量影响。对于非可预测的流量,API网关会处理好。

希望本文能给你带来帮助!

本文来自马克在 APIStrat / APIDays 柏林站的演讲整理。


本文译自:How to load test & tune performance on your API (Part II)


相关评论

暂无评论

我要评论