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

Question

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

我使用JMeter发送这些请求。每次使用嗅探器工具（Wireshark）进行每次测试时，我都会采用空灵痕迹。

我试图从一台机器，多台机器（并行）甚至分布式模式实现这一目标。

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

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

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

当我使用线程数2500时，我几乎2200 request在空灵追踪中一秒钟内命中服务器。

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

更新

案例1：（4000个主题）

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

案例1的输出：

  

JMeter（查看表格中的结果）：启动4000个请求的时间为2.225秒。

     

虚拟跟踪：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个线程太重，可能我必须在分布式模式下测试它。我也尝试过分布式模式（1个主人，2个奴隶）。也许我的剧本错了。

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

在分布式模式下实现此方案的JMeter脚本是什么？

Answer 1

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

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

毫无疑问，我会怀疑这个高一致的请求级别的设计问题。每秒4000个请求每小时变为14,400,000个请求，每24小时变为345,600,000个请求。

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

Answer 2

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

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

例如

。

希望这有点帮助，虽然不完全是你所要求的。

Answer 3

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

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

Answer 4

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