通过移除Nginx,Raygun公司怎样将TPS提高了44%?

2020 年 8 月 18 日

通过移除Nginx,Raygun公司怎样将TPS提高了44%?

Raygun,追求极致性能已然成为公司文化的一部分。在此前的博客文章中,我们介绍了如何通过将Raygun的API迁移到.NET Core 3.1,性能提高 12%的方法。


在发布此内容时,我们在 Twitter 上被问到一个问题,为什么我们会使用 Nginx 作为 Raygun API 应用程序的代理。


我们的回答是,这是微软推荐的方法。事实证明,自.NET Core 2.1 发布以来,情况并非如此。从我们第一次使用.NET Core 1.0 到现在,Kestrel 已经成熟很多,并且自.NET Core 2.1 发行以来,微软的安全专家们对 Kestrel 在前端服务的表现感到十分满意。


为什么移除或使用 Nginx?


在某些情况下,大家仍然会坚持使用 Nginx 这样的代理,我会在下面给你列举出来。对于 Raygun,我们的 API 服务器仅托管了一个应用程序,然后仅通过负载均衡设备公开到互联网。这意味着对端口共享的限制并不适用于我们,开放给外部的服务已经被最小化了。


我们可能要使用代理的一些原因(来自微软的一篇博文),列举如下:


  • 限制其托管应用程序的对外公开部分

  • 提供附加的配置和防御层

  • 方便与现有基础架构更好地集成

  • 简化负载平衡和安全通信(HTTPS)配置。只有反向代理服务器需要X.509证书,并且该服务器可以使用HTTP与内部网络上的应用服务器进行通信。


移除 Nginx 后的业务表现


对于我们的 API 节点,从配置中删除 Nginx 可以使我们处理更多的请求而无需额外费用。


通过负载测试,我们还发现请求的平均响应时间和第 99 百分位响应时间得到显著改善。这意味着我们的客户对 API 服务的请求更快,并允许他们在单位时间内发送更多数据。


自从将新的服务器配置投入生产以来,我们的负载均衡设备报告 5xx 错误也大大减少了。现在,我们可以支撑处理更高的客户端负载,而且用户遇到的错误问题也更少了。


我们如何测试.NET Core 性能


我们在亚马逊的 AWS c5.large 实例 Ubuntu 18.04 环境下进行了测试。基准服务器运行了 Nginx 和 Kestrel Web 服务,Nginx 作为 Kestrel Web 服务代理;作为对比,在另一台服务器上,服务请求直接由 Kestrel 处理。


我们使用 Apache JMeter 将 Raygun Crash Reporting 样本有效负载发布到服务 API。JMeter 可以模拟非常高的并发请求负载。我们对此不断进行调整,让每台服务器都最大程度地利用 CPU,逼近服务过载即将不能支撑处理所有请求的极限(但是仍然保证请求的成功率为 100%)。


使用 JMeter 运行多次测试,每个测试持续 10 分钟,每次测试结束时生成保存测试摘要报告。


最后,我们将多次测试的结果取平均值,最终得出下面的测试结果。


移除 Nginx 后的结果展示


响应时间(毫秒)


平均响应时间(该值越小性能越好)从 1.2ms 减少到 0.8ms,相当于降低了 33%;第 99 百分位响应时间从 6ms 减少到 4ms,相当于降低了 33%。



TPS


TPS(该值越大性能越好)从 3783 个增加到 5461 个,相当于提升了 44%。



在生产环境运行新配置服务的观察结果


内存使用情况


使用 Nginx 运行该服务实例时,每个实例使用的平均内存非常一致,内存使用率在 13%和 16%之间。


自从删除 Nginx 以来,我们已经看到服务进程的内存使用率变大,在 15%到 30%之间,平均值趋近为 22%。我们确信这是由于 Nginx 限制了 Kestrel 处理的请求数量。


因此,Kestrel 在高并发下始终会以一定的速率处理请求,这意味着内存使用量几乎没有很大变化。消除这一瓶颈后,由于 Kestrel 会处理数量不等的请求,我们现在可以看到更多的内存使用和变化情况。


Nginx + Kestrel



Kestral only



平均活跃节点数


活跃节点的平均数量从 5.35 下降到 4.66。现在,我们可以看到相当长的时间内仅仅运行着四个服务器;而在同一时段的高峰时期,相比之前使用 Nginx,我们同样运行着更少的服务器。


Nginx + Kestrel



Kestral only



负载均衡设备的 5xx 错误率


一段时间以来,我们发现通过负载均衡设备统计的信息报告中,5xx 错误率很高,如下图所示。这些错误并不是来自我们应用程序,而且在 Raygun 也没有对其认定为故障并进行报告。


原来,这些错误来自 Nginx,并且通过删除此代理,我们现在可以更好地处理满负载,而且大大减少了故障的发生。


总体而言,由于我们服务器处理的请求量很大,即使是以下较高的数量也仅占我们处理的总请求量的很小一部分。 注意到通过删除 Nginx 层可以得到显著的性能提升,这一点是值得肯定的。我们并不是对 Nginx 进行批评和否定,当然也有可能是我们 Nginx 最终的配置问题,但是,简化配置似乎可以更好地解决这个问题。



总结


敢质疑关于性能问题的原始假设非常棒,在 Raygun,我们追根溯源,最终发现问题以及解决了问题。随着我们基础架构的不断拓展,能够以更低成本处理更多的数据,这给我们带来了一些可观的业务收益,而这一切都始于有人问了一个简单的问题:“为什么?”


值得注意的是,.NET 团队一直在努力改善和优化性能。尽管.NET 5 计划于今年 11 月发布,但目前已经有很多重要更新可以使用了。


原文链接:


How Raygun increased transactions per second by 44% by removing Nginx


2020 年 8 月 18 日 11:062253

评论 8 条评论

发布
用户头像
直接访问数据库取数据更快
2020 年 08 月 26 日 14:13
回复
用户头像
我的选择是用维护性更佳的Caddy,替换Nginx。
2020 年 08 月 19 日 19:52
回复
用户头像
这文章也太水了吧 让人怀疑他们不会配Nginx
2020 年 08 月 19 日 09:49
回复
面对的场景不同而已
2020 年 08 月 19 日 13:24
回复
> 我们并不是对 Nginx 进行批评和否定,当然也有可能是我们 Nginx 最终的配置问题,但是,简化配置似乎可以更好地解决这个问题。
2020,标配Nginx才是政治正确?通过实测因地制宜没啥毛病:)
2020 年 08 月 19 日 15:04
回复
任何情况下增加代理都会损失性能,根据代理的不同损失的多少不同而已,而且看他们的数据本身api响应时间就很短,通过剔除代理增加的绝对时间是在合理范围内的,如果他们的api响应是在几十ms,那基本就没啥提升了。
2020 年 08 月 19 日 22:22
回复
查看更多回复
没有更多评论了
发现更多内容
通过移除Nginx,Raygun公司怎样将TPS提高了44%?-InfoQ