在Raygun，追求极致性能已经成为公司文化的一部分。在发布本文时，我们在Twitter上被问到一个问题，为什么我们要使用Nginx作为我们的RaygunAPI应用程序的代理。答案是肯定的，这是微软推荐的方法。事实证明，自.NETCore2.1发布以来，情况并非如此。从我们第一次使用.NETCore1.0开始，Kestrel已经成熟了很多，而自从.NETCore2.1发布以来，微软的安全专家对Kestrel在前端服务方面的表现非常满意。1.为什么要删除或使用Nginx？在某些情况下，人们仍然坚持使用像Nginx这样的代理，我在下面为您列出。对于Raygun，我们的API服务器仅托管一个应用程序，然后仅通过负载均衡器将其暴露给互联网。这意味着对端口共享的限制不适用于我们，并且已将对外部服务的暴露降至最低。下面列出了我们可能想要使用代理（来自Microsoft博客文章）的一些原因：平衡和安全通信(HTTPS)配置。只有反向代理服务器需要X.509证书，该服务器可以使用HTTP与内部网络上的应用服务器进行通信。https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#when-to-use-kestrel-with-a-reverse-proxy2。移除Nginx之后对于我们的API节点，从配置中移除Nginx可以让我们处理更多请求而无需额外成本。通过负载测试，我们还发现请求的平均响应时间和第99个百分位数的响应时间有了显着改善。这意味着我们的客户可以更快地请求API服务，并允许他们每单位时间发送更多数据。自从将新服务器配置投入生产后，我们还发现负载均衡器报告的5xx错误数量显着减少。我们现在可以处理更高的客户端负载，并且用户遇到的错误更少。3.我们如何测试.NETCore性能我们在亚马逊的AWSc5.large实例Ubuntu18.04环境中进行了测试。基准服务器运行Nginx和KestrelWeb服务，Nginx充当KestrelWeb服务代理；相比之下，在另一台服务器上，服务请求直接由Kestrel处理。我们使用ApacheJMeter将Raygun崩溃报告示例负载发布到服务API。JMeter可以模拟非常高的并发请求负载。我们在不断调整这个，让每台服务器最大限度地利用CPU，接近服务过载的极限，将无法处理所有请求（但仍然保证100%的请求成功率）。https://raygun.com/platform/crash-reporting使用JMeter运行多个测试，每个测试持续10分钟，在每个测试结束时生成一个保存的测试总结报告。最后，我们将多次测试的结果取平均值，最终得到如下测试结果。4、去掉Nginx后的结果显示responsetime(milliseconds)平均响应时间（数值越小性能越好）从1.2ms减少到0.8ms，相当于减少了33%；第99个百分位数的响应时间从6毫秒减少到4毫秒，相当于减少了33%。TPSTPS（值越大，性能越好）从3783增加到5461，相当于增加了44%。5.在生产中运行新配置的服务的观察内存使用当使用Nginx运行服务实例时，每个实例的平均内存使用非常一致，内存使用率在13%和16%之间。自从移除Nginx后，我们发现服务进程内存使用率上升了15%到30%，平均接近22%。我们认为这是由于Nginx限制了Kestrel处理的请求数量。因此，Kestrel在高并发下会始终以一定的速率处理请求，这意味着内存占用率几乎不会发生太大变化。随着这个瓶颈的消除，我们现在可以看到更多的内存使用和变化，因为Kestrel处理不同数量的请求。Nginx+KestrelKestral仅平均活跃节点数平均活跃节点数从5.35下降到4.66。
