使用 Apache AB 对 ec2 Node.js 进行负载测试 - 在服务器上运行 6500 QPS，但从远程运行 175 QPS答案

【问题标题】：Load testing ec2 Node.js with Apache AB - 6500 QPS run on server but 175 QPS from remote使用 Apache AB 对 ec2 Node.js 进行负载测试 - 在服务器上运行 6500 QPS，但从远程运行 175 QPS
【发布时间】：2012-05-21 22:22:50
【问题描述】：

我正在尝试在 ubuntu 64 上的 ec2 c1.xlarge 机器上加载测试一个简单的 node.js 和 cyclone hello world 应用程序。它有 8 个内核。我使用 nginx 作为负载均衡器，主管为每个核心启动一个进程。当我在机器上运行以下命令时，node.js 的 qps 约为 6500。

 ab -n 5000 -c 25 http://127.0.0.1

当我从远程机器运行 ab 时，即使是在同一区域中的机器，qps 也会下降到大约 175 qps。如果我从我的开发机器上运行，情况会更糟。

那么，我错过了什么？是否有我必须调整的参数以允许来自远程机器的更多连接？我觉得我错过了什么。我必须调整 sysctl 配置文件吗？它是一台相当原始的机器，但在启动时，以下是我调整的 nobs。

sysctl -w fs.file-max=128000;
sysctl -w net.ipv4.tcp_keepalive_time=300;
sysctl -w net.core.somaxconn=250000;
sysctl -w net.ipv4.tcp_max_syn_backlog=2500;
sysctl -w net.core.netdev_max_backlog=30000;
sysctl -p

【问题讨论】：

难道网络真的是这里的瓶颈？
嗯...175 QPS 在同一归置组中的 ec2 上。这意味着彼此相邻。
高度优化的软件每次可以轻松处理比 100 Mbit/s 以太网互连可以传输的更多请求。您应该估计基准在 localhost 上使用了多少带宽。将此与 EC2 置放群组中节点之间的互连带宽进行比较，可以告诉我们网络是否会成为瓶颈。
嗯，我刚刚阅读了“在置放群组中启动的所有实例都具有低延迟，实例之间完全平分 10 Gbps 带宽”。因此，假设 Amazon 没有网络问题，那么 NIC 不太可能导致性能显着下降。
只是为了确定，对两个节点之间的网络本身进行基准测试。这可以通过多种方式完成。一个非常简单的方法是 dd 和 netcat 的组合，如下所述：wiki.linuxquestions.org/wiki/Benchmark

标签： node.js nginx amazon-ec2 load-testing

【解决方案1】：

延迟会降低测试速度，从而降低吞吐量。几乎在每种情况下，远程请求都会比本地请求花费更长的时间，因此远程运行的单个线程的吞吐量将低于本地运行时的吞吐量，因此，当使用不会调整请求的 Ab 时，总吞吐量必须降低。

例如，您有 25 个线程。假设在本地提出您的请求需要 50 毫秒。对于一个线程，这给出了：

1000（1 秒）/50 = 20 个请求/秒 - 这是一个线程可能的最大吞吐量。

超过 25 个线程，总计 25 * 20 = 500 个请求/秒。

如果您采用该公式并将响应时间更改为 250 毫秒，则线程上的总最大吞吐量将下降到 4 个请求/秒，从而在 25 个线程中 80 个请求的总体最大可能每秒。

更进一步：如果您说使用 25 个线程获得 6000 qps，那么从逻辑上讲，您的应用在本地调用时会在大约 4 毫秒内响应。如果您只能远程获得 175 qps，那是因为响应时间下降到大约 142 毫秒，所以在您的系统中，您有大约 138 毫秒的延迟 - 给予或接受 - 这就是问题所在。

【讨论】：

我还是很困惑。所以..如果我得到例如4000个不同机器的请求，那我还好吗？那么，当人们从 AB 负载测试中报告 qps 时，这就是为什么它在服务器上完成？而不是远程机器？
您在本地获得的结果代表了您的应用可以单独实现的目标。这就是Ab擅长的。如果您想要一个包含系统每一层的更彻底的负载测试，那么，这需要更多的工作。我认为，尽管出于您的目的，您的 4000 值在这种情况下是正确的。您甚至可能会发现使用更多线程可以获得更高的 qps。
如果您确实想扩展负载测试，那么您可能希望从 Ab 升级到 JMeter，这两个都是 Apache 项目，但 JMeter 的功能要多得多。
我不同意你的论点，奥利弗。您对 4 毫秒的本地响应时间是正确的。但只要 Tampa 不提供延迟基准，我强烈怀疑每个请求会因网络延迟而“丢失”超过 100 毫秒：Tampa 的机器具有 10 Gbps 互连。这种以太网中的延迟不应超过几毫秒。
是的，但是 OP 吞吐量较低的原因是他的响应时间较慢。这就是问题的答案。