在 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服务器仅托管了一个应用程序，然后仅通过负载均衡设备公开到互联网。这意味着对端口共享的限制并不适用于我们，开放给外部的服务已经被最小化了。

我们可能要使用代理的一些原因（来自微软的一篇博文），列举如下：

移除Nginx后的业务表现

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

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

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

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

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

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

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

平均响应时间（该值越小性能越好）从1.2ms减少到0.8ms，相当于降低了33％；第99百分位响应时间从6ms减少到4ms，相当于降低了33％。

TPS（该值越大性能越好）从3783个增加到5461个，相当于提升了44％。

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

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

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

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

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

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

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

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

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

原文链接：