负载生成百万http请求答案

【问题标题】：Load generation of millions of http requests负载生成百万http请求
【发布时间】：2016-08-24 05:42:18
【问题描述】：

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

【问题讨论】：

我假设每个端口都可以有一个请求队列，例如一个给定的端口可能正在处理一个请求，而其他许多请求都在等待。

【解决方案1】：

我假设您说的是 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 应用程序的范围内，用户 = 线程，并且 Web 应用程序的并行性也是基于线程的。如果您放弃了这些限制，并且您的 Web 应用程序支持异步 API（传统的或类似 Quasar），那么这是一个不同的现实。在这种情况下，您可以达到端口数量受到限制的程度，但由于每个网络接口的端口数量，您可以添加网络接口以支持所需的端口数量。在 Linux 上，它可能是virtual interface，但考虑到现在大多数机器无论如何都是虚拟的，也可能是虚拟网络适配器。 100 万个端口需要 16 个。

【讨论】：

非常感谢您的回复。我说的是 100 万个并发请求。我读过关于轻量级线程的文章，例如 java 纤维，GO 之类的线程。我听说在这些轻量级线程的帮助下，我们可以在没有分布式设置的情况下生成大量并发请求。所以他们声称可以从一个系统中生成大约数百万个并发请求。怎么可能？
我根据评论添加了更多信息

【解决方案2】：

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

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

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

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

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

【讨论】：