如何在 1 秒内发送 4000 多个请求？答案

【问题标题】：How to send 4000+ requests in exactly 1 second?如何在 1 秒内发送 4000 多个请求？
【发布时间】：2017-01-07 16:00:45
【问题描述】：

我有一个HTTP GET request。我需要在 1 秒内将请求发送到应用程序服务器超过 4000 次。

我正在使用 JMeter 发送这些请求。我每次使用嗅探器工具 (Wireshark) 对每个测试进行空灵的跟踪。

我尝试通过一台机器、多台机器（并行）甚至分布式模式来实现这一点。

实际上，JMeter 结果不是我关心的问题。这个测试的关注点是在嗅探工具上看到4000 请求在一秒钟内到达服务器。

在使用以下 JMeter 测试计划时，我在 ethereal trace 中的 1 sec 中几乎发现了 2500 请求。

Number of Threads= 4000
Ramp-Up Periods = 0 (Though it is depricated)
Loop count= 1

当我使用线程数作为2500 时，我几乎得到2200 request 在空灵跟踪中在一秒钟内访问服务器。

服务器对该请求的响应不是我关心的问题。我只是想确保JMeter 发送的4000 请求在一秒钟内到达应用服务器。

更新：

案例 1：（4000 个线程）

Number of Threads= 4000
Ramp-Up Periods = 0 
Loop count= 1

案例 1 的输出：

JMeter（在表中查看结果）：启动 4000 个请求需要 2.225 秒。

Ethereal trace：4000 个请求到达服务器需要 4.12 秒。

案例 2：（3000 个线程）

JMeter（在表中查看结果）：启动 3000 个请求需要 1.83 秒。

Ethereal trace：3000 个请求到达服务器需要 1.57 秒。

案例 3：（2500 个线程）

JMeter（在表中查看结果）：启动 2500 个请求需要 1.36 秒。

Ethereal trace：2500 个请求到达服务器需要 2.37 秒。

案例 4：（2000 个线程）

JMeter（在表中查看结果）：启动 2000 个请求需要 0.938 秒。

Ethereal trace：2000 个请求到达服务器需要 1.031 秒。

I have run these test from only one machine. 
No listeners added.
Non-Gui mode.
No assertions in my scripts.
Heap size: 8GB

所以，我不明白为什么我的 JMeter 结果和空灵痕迹彼此不同。我也试过用Synchronizing Timer 来实现这个场景。

由于 4000 Threads 太重了，也许我必须在分布式模式下进行测试。我也尝试过分布式模式（1 个主设备，2 个从设备）。也许我的脚本是错误的。

是否可以在空灵的跟踪中看到我的 4000 个请求在 1 秒内到达服务器？

在分布式模式下实现这个场景的 JMeter 脚本是什么？

【问题讨论】：

与任何网络测试一样，总会出现问题，尤其是延迟问题 - 即使您每秒可以发送 4000 个请求，它们也会按顺序发送（这就是数据包的获取方式已发送），并且可能不会在那一秒内全部命中，加上处理时间。
4000 个线程需要 4000 个堆栈。每个 1MB，仅堆栈就有 4GB 的 RAM。
请求必须每次都打开一个新的连接，还是可以重复使用打开的套接字？
这两种情况对我来说都可以。但我需要看到在我的虚幻跟踪中，一次（1 秒）恰好有 4000 个请求到达服务器。
为什么是exactly？如上所述，您的要求是能够处理至少 4000 rps。因此，只要您发送了 4000 或更多 rps，您就已经测试了您的要求。

标签： java jmeter performance-testing heap-memory stack-memory

【解决方案1】：

如何从服务器是否配置正确来避免这种负载开始。请求可以是任何类型。如果它们是静态请求，则努力确保由于缓存策略或体系结构，这些请求的绝对最小数量到达您的源服务器，例如

如果您有返回用户并且没有 CDN，请确保您的缓存策略存储在客户端，并随着您的构建计划到期。这样可以避免回访者的重复请求
如果您没有返回用户且没有 CDN，请确保您的缓存策略设置为给定用户集的日志中可见的最大页面到页面延迟的至少 120%
如果您有 CDN，请确保所有静态请求标头、301 和 404 标头都已设置为允许您的 CDN 缓存您的请求，使其随着新的构建推送计划到期。
如果您没有 CDN，请考虑将所有静态资源放置在专用服务器上的模型，该服务器上的所有内容都标记为在客户端进行高级缓存。您还可以在一台服务器前面使用 varnish 或 squid 作为缓存代理来承担负载

最终我会怀疑在如此高的一致请求级别上存在设计问题。每秒 4000 个请求变为每小时 14,400,000 个请求和每 24 小时周期 345,600,000 个。

在流程的基础上，我还建议至少三个负载生成器：两个用于主要负载，一个用于控制虚拟用户，单个虚拟用户|线程用于您的业务流程。在您当前适用于一台负载生成器的模型中，您没有控制元素来确定负载生成器的潜在过载所带来的开销。控制元素的使用将帮助您确定负载驱动中是否有负载生成器施加了偏斜。从本质上讲，您有一个资源耗尽，它正在为您的负载生成器添加一个速度中断。在您的负载生成器上寻求一个刻意的欠载理念。当有人因缺少控制元素而攻击您的测试，然后您需要重新运行测试时，添加另一个负载生成器比政治资本的花费更便宜。它也比追逐一个看起来很慢但实际上是一个过载的负载生成器的工程幽灵要便宜得多

【讨论】：

【解决方案2】：

你想坚持使用 JMeter 吗？否则Httperf 是一个不错的工具并且易于使用：

httperf --server=www.example.com --rate=4000 --num-conns=4000

例如。

希望这会有所帮助，尽管不完全符合您的要求。

【讨论】：

【解决方案3】：

考虑将您的 HTTP 请求放在 Synchronizing Timer 下 - 这样您就可以确保您的请求在同一时刻启动。

另外 4000 个线程是一个相当“重”的负载，因此我建议遵循 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure 指南中的建议，以从您的 JMeter 实例中获得最大性能。

【讨论】：

我已经更新了我的问题。我尝试过使用同步计时器，但没有运气。我已经看到了你提供的那些建议。
是否可以从分布式模式实现？如果是，JMeter 脚本配置是什么？
同步定时器在分布式模式下不起作用。实际上它可以工作，但它对其他奴隶一无所知。如果您需要在分布式模式下执行此操作 - 您可能需要考虑线程调度（可能与具有较少“分组依据”计数的本地同步计时器结合使用）

【解决方案4】：

如果你的电脑不够用，你应该使用分布式测试 Jmeter
请记住，理论上您每秒可以发送 4000 个请求，他们会在去服务器的路上花一些时间，所以有他们不会在 1 秒内到达的概率。为避免这种情况，请尝试使用高带宽局域网（例如，您可以将服务器托管在 Azure 云并在云中安装 Jmeter。 )
如果您使用 JMeter 没有成功，请尝试使用 Tank 这个专门用于高负载的工具，应该可以发送甚至可以在 1 秒内从 1 台机器发出 10k 个请求。

【讨论】：