如何在1秒钟内发送4000多个请求？
我有一个HTTP GET request 。 我需要在1秒内将请求发送到应用程序服务器超过4000次。
我正在使用JMeter发送这些请求。 每次使用嗅探器工具（ Wireshark ）进行每次测试时，我都会采用空灵痕迹。
我试图从一台机器，多台机器（并行）甚至分布式模式实现这一目标。
实际上，JMeter的结果不是我关注的问题。 此测试的关注点是在嗅探器工具上看到4000请求在一秒内命中服务器。
在使用以下JMeter测试计划时，我在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秒。
虚拟跟踪 ：4000个请求命中服务器4.12秒。
案例2：（3000个主题）
JMeter（查看表中的结果） ：1.83秒启动3000个请求。
虚拟跟踪 ：3000次请求命中服务器1.57秒。
案例3：（2500个主题）
JMeter（查看表中的结果） ：1.36秒启动2500个请求。
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脚本是什么？
如何正确配置服务器以避免此类负载。 请求可以是任何类型。 如果它们是静态请求，那么请确保由于缓存策略或体系结构而导致源服务器的绝对最小数量达到原始服务器，例如
- 如果您有返回用户且没有CDN，请确保您的缓存策略存储在客户端，并与您的构建计划一起到期。 这可以避免返回访问者的重复请求
- 如果您没有返回用户且没有CDN，请确保您的缓存策略设置为给定用户集的日志中可见的最大页面到页面延迟的至少120％
- 如果您有CDN，请确保设置所有静态请求标头，301和404标头，以允许您的CDN使用新的构建推送计划缓存您的请求到期。
- 如果您没有CDN，请考虑将所有静态资源放在专用服务器上的模型，其中该服务器上的所有内容都标记为在客户端以高级别进行缓存。 您还可以将具有varnish或squid的一台服务器作为缓存代理来承担负载
毫无疑问，我会怀疑这个高度一致的请求级别的设计问题。 每秒4000个请求每小时变为14,400,000个请求，每24小时变为345,600,000个请求。
在进程的基础上，我还建议至少三个负载生成器：两个用于主要负载，一个用于业务流程的单个虚拟用户线程的控制虚拟用户。 在一个负载生成器上的所有当前模型中，您没有控制元素来确定负载生成器潜在过载所带来的开销。 控制元件的使用将帮助您确定在负载驱动中是否存在负载发生器施加的偏斜。 从本质上讲，您的资源耗尽，这会在您的负载生成器上添加速度中断。 在负载生成器上寻找有意识的欠载原理。 当有人因缺少控制元素而攻击您的测试然后您需要重新运行测试时，添加另一个负载生成器比政治资本的费用便宜。 它也比追逐工程重影便宜得多，工程重影看起来像一个慢速系统，但实际上是一个负载过重的负载发生器
你想坚持使用JMeter吗？ 否则Httperf是一个不错的工具，易于使用：
httperf --server=www.example.com --rate=4000 --num-conns=4000
例如。
希望这有点帮助，虽然不完全是你要求的。
考虑将HTTP请求置于同步计时器下 – 这样您就可以确保在完全相同的时刻启动您的请求。
另外4000个线程是一个非常“负载”的负载，因此我建议按照9 Easy Solutions的建议， 进行JMeter负载测试“Out of Memory”失败指南，以便从JMeter实例中获得最佳性能。
- 如果你的电脑还不够，你应该在Jmeter中使用分布式测试
- 请记住，理论上你可以每秒发送4000个请求，他们会花一些时间去服务器的路上，因此有可能它们不会在1秒内到来。 为避免这种情况，请尝试使用高带宽局域网（例如，您可以在Azure云中托管服务器并在云中安装Jmeter。）
- 如果你没有成功使用JMeter尝试使用Tank这个专门用于高负载的工具，应该可以在1秒内从1台机器发送10k请求。