load - 负载生成百万http请求

Question

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

Answer 1

我假设您说的是 100 万最终用户。因为，实际上，对于某些应用程序，服务器上的 100 万个请求可以由数量少得多的用户生成。这项研究就是一个很好的例子。他们只有 13000 个同时连接到服务器，但这会在服务器上产生超过一百万条消息/秒的工作负载。

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

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

一百万并发请求是一个更有趣的话题。正如您所指出的，这是不可能从一台机器上实现的，而端口并不是唯一的原因。这就是分布式负载派上用场的地方。如果你有 N 个远程 JMeter 引擎，每个运行 X 个并发请求，你可以传递N * X并发请求。

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

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

编辑：根据评论，您似乎在谈论平行宇宙。在 JMeter 和典型的 Web 应用程序的范围内，用户 = 线程，并且 Web 应用程序的并行性也是基于线程的。如果您放弃了这些限制，并且您的 Web 应用程序支持异步 API（传统的或类似 Quasar），那么情况就不同了。在这种情况下，您可以达到端口数量受到限制的程度，但由于每个网络接口的端口数量，您可以添加网络接口以支持所需数量的端口。在 Linux 上，它可能是一个虚拟接口，但鉴于现在大多数机器都是虚拟的，也可能是虚拟网络适配器。100 万个端口需要其中的 16 个。

Answer 2

在进程的基础上，独立于工具，不建议使用单个负载生成器。几乎不可能包括一个控制组来检查您的测试质量以及由于您的测试设计使用过载生成器而导致的用户降级。

寻找至少三个生成器：两个用于主要负载，一个用于每个测试业务类型的单个虚拟用户的控制组。如果您的控制组和全局组以相同的速度退化，那么您可以确信您的原因是外部的，即正在测试的应用程序。另一方面，如果您的两台主服务器的响应时间下降，但您的控制组没有（甚至变得更快），那么您的测试设计问题显示为降级的应用程序。正如您需要监控被测应用程序/站点的资源挑战一样，您也需要对负载生成器执行相同的操作。

同一请求/响应窗口中的百万并发请求不合理的原因有很多

1. 一个庞大的站点的所有静态组件都将由分布在全球范围内的 CDN 解决方案承担。通过 CDN 到 ORIGIN 服务器的请求的实际数量应该非常少，尤其是当您考虑到页面上的请求主要是静态组件、第三方组件和您的营销部门将痴迷的跟踪小部件时
2. 假设这是一个面向互联网的应用程序，没有任何类型的推送技术来防止大量人口超载，那么您正在查看的人口集是超过 100,000,000 名在线用户当时都在从事一项活动。人类，作为混沌的工具，很难在“现在！！！！！！”的时间里做任何事情 片刻。检查您的 HTTP 访问日志，您应该会看到这种负载实际上是如何分布的。IP 地址还可以在平均用户会话持续时间或五分钟块（以更容易查看的为准）内提供负载的客观视图
3. 我对规模非常大的互联网站点有一些经验。你永远不会测试满载。您针对定义的“模块”或应用程序架构的子集测试扩展负载。请注意，在某些情况下，一个模块是一组 10 个 42u 机架，从生产定义中滚动，用于升级到新版本和性能测试。该模块可能占基础设施的 5%。

因此，最终，当您以 50,000 使用切片/模块/pod 时，您的 1,000,000 并发下降到 5%。接下来，该金额折旧 80%，以说明 CDN 层当前正在捕获或服务的内容（可能高于 80%）。这可以让您获得 10,000 个并发请求。您的 HTTP 日志将能够确认在单个请求/响应窗口内发生的请求的精确时间。所有 10K 人同时出现的几率非常低。