【问题标题】:Unexpected test results with nginx as load balancer使用 nginx 作为负载均衡器的意外测试结果
【发布时间】:2018-02-08 12:22:03
【问题描述】:

我正在使用以下场景对 nginx/node.js 拓扑进行基准测试:

  1. 直接对单个 node.js 服务器进行基准测试
  2. 在 nginx 后面对 2 个 node.js 服务器进行基准测试(RR 负载平衡)

对于这两个基准,“wrk”与以下配置一起使用:

wrk -t12 -c20 -d20s --timeout 2s

所有 node.js 实例都是相同的。在每个 http GET 请求上,它们迭代给定的数字“n”并在每个循环中增加一个变量。

当我执行测试用例时,我得到了下面概述的有点令人惊讶的结果。我不明白,为什么双 node.js 设置(拓扑 2)在 100 万次迭代中表现更差 - 它甚至比拓扑 1 上相同的 100 万次循环更差。

1037 req/s(单次)与 813 req/s (LB)

我确实预计会有一点开销,因为单个操作在 node.js 实例前面没有 nginx - 但测试结果看起来真的很奇怪。

10 和 500 万次迭代的调用似乎运行良好,因为吞吐量的增加符合预期。

这种行为有合理的解释吗?

测试在单台计算机上执行; 每个 node.js 实例都在监听不同的端口。

Nginx 使用标准配置,除了:

  • 80 端口
  • 2个上游服务器
  • proxy_pass 在“/”路由上
  • 1024(默认)Worker_connections(增加不改变结果)
场景 1(单个 node.js 服务器): n [百万]个请求/秒平均/最大[毫秒]个请求 10 134 87.81/166.28 2633 5 271 44.12/88.48 5413 1 1037 11.48/24.99 20049 场景 2(nginx 作为 2 个 node.js 服务器前面的负载均衡器): n [百万]个请求/秒平均/最大[毫秒]个请求 10 220 51.95/124.87 4512 5 431 27.79/152.93 8376 1 813 6.85/35.64 16156 --> ???

【问题讨论】:

  • 您是否100%确定请求确实在两个实例之间共享? 情况
  • @EMX 是的,我将端口添加到输出并从浏览器测试它......然后,开始 wrk

标签: node.js nginx benchmarking wrk


【解决方案1】:

我一直在挖掘......它可能与 NGINX 默认配置有关。效率不够……

使用 HTTP/1.1 节省了建立连接的开销 在 nginx 和 node.js 之间,每个代理请求都有一个 对响应延迟产生重大影响。

因此,如果您使用的是 HTTP/1.0(NGINX 默认),这可能是原因之一


有趣的功能:Keepalive

设置上游的最大空闲保活连接数 每个工作进程保留在缓存中的服务器


来源:

http://www8.org/w8-papers/5c-protocols/key/key.html#SECTION00050000000000000000

https://engineering.gosquared.com/optimising-nginx-node-js-and-networking-for-heavy-workloads

http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load/

【讨论】:

  • 感谢您的研究。我添加了keepalive 512;到代理部分以及proxy_http_version 1.1;到 nginx.conf 但吞吐量数字只是略微增加到 950 req/s。通过查看 CPU 利用率,我发现有趣的是:运行测试大约 10 秒后,CPU 利用率显着下降到接近于零。在下降之前,涉及 2 个核心的利用率还不错......(使单个 node.js 实例的利用率翻倍)
猜你喜欢
  • 2017-01-17
  • 1970-01-01
  • 2012-11-10
  • 2019-05-09
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-12-14
  • 2019-08-24
相关资源
最近更新 更多