我听说有些负载生成器会产生数百万个请求的负载，但是当TCP中的端口数量只有65000时，这怎么可能呢？
答案 0 :(得分：2)
我假设您正在谈论100万最终用户。因为，实际上，一些应用程序在服务器上的100万个请求可以由更少数量的用户生成。这方面的好例子是this study。它们只有13000个并发连接到服务器，但是在服务器上产生了超过一百万个消息/秒的工作负载。
此外，这取决于您是在谈论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应用程序的范围内，user = thread，以及Web应用程序的并行性基于线程。如果您放弃这些限制，并且您的Web应用程序也支持异步API（传统或类似Quasar），那么这是一个不同的现实。在这种情况下，您可以达到端口数量限制的程度，但由于每个网络接口的端口数量，您可以添加网络接口以支持所需数量的端口。在Linux上，它可能是virtual interface，但鉴于现在大多数机器都是虚拟的，也可能是虚拟网络适配器。你需要其中16个用于100万个端口。
答案 1 :(得分：1)
在过程的基础上，不建议使用单个负载生成器独立于工具。几乎不可能包含一个控制组来检查测试质量，以及由于您的测试设计导致发生器过载而导致用户退化。
寻找至少三个生成器：两个用于主要负载，一个用于每个经过测试的业务类型的单个虚拟用户的控制组。如果您的控制组和您的全局组以相同的速率降级，那么您可以确信您的原因是外部的，即被测试的应用程序。另一方面，如果您的两个主服务器响应时间降低，但您的控制组没有（甚至变得更快），那么您的测试设计问题就会显示为降级应用程序。正如您需要监控正在测试的应用程序/站点以应对资源挑战一样，您还需要对负载生成器执行相同的操作。
为什么同一请求/响应窗口中的百万个并发请求不合理有很多原因
因此，最终，当您使用50,000个切片/模块/ pod时，您的1,000,000个并发数降至5％。接下来，该金额折旧80％，以考虑CDN层当前捕获或服务的内容（可能高于80％）。这可以让你获得10,000个并发请求。您的HTTP日志将能够确认在单个请求/响应窗口内发生的请求的精确时间。所有10K在同一时间恰好在同一时间的几率非常低。