java - 如何在 1 秒内发送 4000+ 请求？

Question

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

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

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

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

在使用以下 JMeter 测试计划时，我在 1 秒 中发现几乎 2500 请求。

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

当我使用 2500 的线程数时，在 ethereal trace 中，我在一秒钟内收到了将近 2200 个请求 命中服务器。

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

更新:

案例 1:(4000 个线程)

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

案例 1 的输出:

JMeter (View Results in Table): 2.225 seconds to start 4000 requests.

Ethereal trace: 4.12 seconds for 4000 requests to hit the server.

案例 2:(3000 个线程)

JMeter (View Results in Table): 1.83 seconds to start 3000 requests.

Ethereal trace: 1.57 seconds for 3000 requests to hit the server.

案例 3:(2500 个线程)

JMeter (View Results in Table): 1.36 seconds to start 2500 requests.

Ethereal trace: 2.37 seconds for 2500 requests to hit the server.

案例 4:(2000 个线程)

JMeter (View Results in Table): 0.938 seconds to start 2000 requests.

Ethereal trace: 1.031 seconds for 2000 requests to hit the server.

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

所以，我不明白为什么我的 JMeter Results 和 ethereal traces 彼此不同。我也试过 Synchronizing Timer实现这种情况。

由于 4000 个线程太重，也许我必须在分布式模式下进行测试。我也尝试过分布式模式(1 个主站，2 个从站)。也许我的脚本是错误的。

是否可以在 ethereal trace 中看到我的 4000 个请求在 1 秒内到达了服务器？

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

Answer 1

如何从服务器配置是否正确来避免此类负载开始。请求可以是任何类型。如果它们是静态请求，那么请确保由于缓存策略或架构，这些请求的绝对最小数量会命中您的源服务器，例如

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

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

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