1

我在以下场景中对 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 --> ???
4

1 回答 1

0

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

使用 HTTP/1.1 可以节省在 nginx 和 node.js 之间为每个代理请求建立连接的开销，并且对响应延迟有显着影响。

因此，如果您使用的是 HTTP/1.0（NGINX 默认），这可能是原因之一

有趣的功能：保活

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

资料来源：

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/

于 2017-08-30T20:06:15.277 回答