如何在1秒内发送4000多个请求？
Jah*_*han 18 java heap stack jmeter performance-testing
我有一个HTTP GET request.我需要4000在1秒内将请求发送到应用程序服务器超过一次.
我正在使用JMeter发送这些请求.每次使用嗅探工具(Wireshark)进行每次测试时,我都会采用空灵痕迹.
我试图从一台机器,多台机器(并行)甚至分布式模式实现这一目标.
实际上,JMeter结果不是我关注的问题.此测试的关注点是4000在嗅探器工具上看到请求在一秒内到达服务器.
在使用以下JMeter测试计划时,我发现在ethereal trace中几乎有2500请求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(查看表中的结果):1.83秒启动3000个请求.
虚拟跟踪:3000次请求命中服务器1.57秒.
案例3:(2500个主题)
JMeter(查看表中的结果):1.36秒开始2500个请求.
虚拟跟踪: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脚本是什么？
小智 3
首先检查服务器是否配置正确以避免此类负载。请求可以是任何类型。如果它们是静态请求，那么由于缓存策略或体系结构，请努力确保这些请求的绝对最小数量到达您的源服务器，例如
- 如果您有回访用户并且没有 CDN，请确保您的缓存策略存储在客户端，并随着构建计划而过期。这可以避免回访者重复请求
- 如果您没有回访用户且没有 CDN，请确保您的缓存策略至少设置为给定用户集日志中可见的最大页面到页面延迟的 120%
- 如果您有 CDN，请确保所有静态请求标头、301 和 404 标头都设置为允许您的 CDN 缓存您的请求，以便在新的构建推送计划中过期。
- 如果您没有 CDN，请考虑一种模型，将所有静态资源放置在专用服务器上，该服务器上的所有内容都被标记为在客户端进行高级缓存。您还可以在一台服务器前面使用清漆或鱿鱼作为缓存代理来承担负载
最终，我怀疑设计问题与如此高的一致请求级别有关。每秒 4000 个请求变为每小时 14,400,000 个请求，每 24 小时变为 345,600,000 个请求。
在流程的基础上，我还建议至少使用三个负载生成器：两个用于主要负载，一个用于业务流程的单个虚拟用户|线程的控制虚拟用户。在当前的多合一负载生成器模型中，您没有控制元素来确定负载生成器的潜在过载所带来的开销。使用控制元件将帮助您确定负载生成器是否在负载驱动中施加了偏差。从本质上讲，您的资源正在耗尽，这会在负载生成器上增加速度限制。在负载生成器上采用故意的欠载理念。当有人因为缺乏控制元素而攻击你的测试，然后你需要重新运行你的测试时，添加另一个负载生成器比政治资本的花费更便宜。它也比追逐一个看似缓慢的系统但实际上是一个过载的负载生成器的工程幽灵要便宜得多