数百万个http请求的负载生成

Question

我听说一些负载生成器可以生成数百万个请求的负载，但是当 TCP 端口数只有 65000 个时，这怎么可能？

Answer 1

我假设您谈论的是 100 万最终用户。因为实际上，服务器上对某些应用程序的 100 万个请求可以由少得多的用户生成。很好的例子是 this study 。他们只有 13000 个与服务器的同时连接，但这在服务器上产生了超过 100 万条消息/秒的工作负载。

此外，这还取决于您谈论的是 100 万个并发请求，还是针对给定数量的用户的 100 万个总请求。

第二个很容易实现:对于 X 个并发用户，您需要运行测试 1,000,000/X 次(迭代)，例如对于 100 个并发用户，您需要 10000 次迭代，这实际上并不是很多。

一百万个并发请求是一个更有趣的话题。正如您所指出的，这是不可能从一台机器实现的，并且端口并不是唯一的原因。那就是Distributed load派上用场。如果您有 N 个远程 JMeter 引擎，每个引擎运行 X 个并发请求，则您可以传送 N * X 个并发请求。

所以理论上，如果你只受到端口数量的限制，并且假设你只有大约 64K 端口可以使用(因为端口 0-1024 不应该被使用，并且可能 1024 以上的一些端口也会被占用)您将需要 16 个左右的远程 JMeter 引擎，每个引擎运行 64K 并发用户以同时传送 100 万个请求。然而目前，端口不太可能成为您最大的问题。您可能会受到机器上其他参数的限制:内存、CPU 以及线程数。目前，在一台好的机器上，您可以拥有大约 500 - 2000 个并发 JMeter 线程(取决于机器和测试)。因此，要交付 100 万个并发请求，您需要 500 - 2000 个远程 JMeter 引擎...

甚至不考虑此类测试的管理和结果分析的复杂性，问题是:您真的需要进行全面的测试吗？任何一台服务器永远无法为 100 万并发用户提供服务。它必须是一个集群，如果是这样，您不必针对整个集群进行测试，您可以将其缩小到可管理的比例，并推断更大集群的结果。

编辑:根据评论，似乎您正在谈论 parallel universe 。在JMeter和典型的Web应用程序范围内，用户=线程，并且Web应用程序的并行性是基于线程的。如果您放弃这些限制，并且您的 Web 应用程序支持异步 API(传统的或类似 Quasar 的)，那么现实就不同了。在这种情况下，您可能会遇到端口数量受到限制的情况，但由于端口数量是每个网络接口(interface)的，因此您可以添加网络接口(interface)以支持所需的端口数量。在 Linux 上，它可能是 virtual interface ，但考虑到现在大多数机器都是虚拟的，也可能是虚拟网络适配器。 100 万个端口需要 16 个。