logo标签列表

如何在一秒钟内准确地发送超过4000个请求？

javajmeterperformance-testingheap-memorystack-memory
17

我有一个HTTP GET请求，需要在1秒钟内精确地将请求发送给应用服务器超过4000次。

我正在使用JMeter发送这些请求。 我每次使用嗅探工具（Wireshark）对每个测试进行网络抓包分析。

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

实际上，JMeter的结果并不是我关心的重点。 这个测试的重点是查看嗅探工具中是否有4000个请求在1秒钟内访问了服务器。

使用以下JMeter测试计划时，在ethereal中发现了近似2500个请求在1秒内。

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

当我使用线程数为2500时，在Ethereal跟踪中，我几乎在一秒钟内收到了2200个请求。

这里我不关心服务器对该请求的响应。我只想确保JMeter发送的4000个请求在一秒钟内命中应用程序服务器。

更新：

情况1：（4000个线程）

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

第1个测试结果：

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

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

enter image description here

第2个测试结果（3000个线程）：

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

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

第3个测试结果（2500个线程）：

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

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

第4个测试结果（2000个线程）：

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

Ethereal跟踪：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结果和ethereal跟踪不同。我已经尝试使用“同步计时器”来实现这个场景。

由于4000个线程太重了，也许我得在分布式模式下测试。我也尝试了分布式模式（1主2从）。也许我的脚本有问题。

在ethereal跟踪中是否可以看到我的4000个请求在1秒钟内命中服务器？

在分布式模式下，如何编写JMeter脚本以实现此场景？

1
4000个线程需要4000个栈。每个栈1MB，仅栈就需要4GB的RAM。 - Fozi
1
请求必须每次都打开新的连接吗？还是已经打开的套接字可以被重复使用？ - Bohemian
我的机器上的file-max参数被设置为500000。我根据此文档中的计算设置了这个值。我的机器内存为16GB。 - Masud Jahan
你是在从零开始尝试做这件事吗？ - Shiraaz.M
1
为什么是“确切的”呢？你的要求是至少能够处理4000个请求每秒。只要你发送了4000个或更多的请求，你就已经测试了你的要求。 - user207421
显示剩余4条评论
4个回答
3
让我们先从服务器是否正确配置开始，以避免这种负载。请求可以是任何类型。如果它们是静态请求，则需要努力确保由于缓存策略或架构（例如）最少数量的这些请求命中您的源服务器：
- 如果您有返回用户且没有CDN，请确保您的缓存策略在客户端中存储，并随着生成时间表过期。这样可以避免重复请求来自返回访问者。 - 如果您没有返回用户和没有CDN，请确保您的缓存策略设置为给定用户集合的最大页面延迟的至少120%。 - 如果您有CDN，请确保所有静态请求标头、301和404标头都设置为允许您的CDN缓存请求，以便随着新生成时间表的推送而过期。 - 如果您没有CDN，请考虑将所有静态资源放置在专用服务器上，该服务器上的所有内容都标记为在高级别上缓存客户端。还可以使用Varnish或Squid作为缓存代理来前置该服务器以承受负载。
最后，我怀疑此高一致的请求水平存在设计问题。每秒4000个请求变成每小时1440万个请求，每24小时345,600,000个请求。
在流程方面，我还建议使用至少三个负载发生器：两个用于主要负载，一个用于业务流程的单个虚拟用户|线程的控制虚拟用户。在您当前的模型中，所有内容都在一个负载发生器上，没有控制元素来确定由于潜在超载而施加的开销。使用控制元素将帮助您确定是否有负载生成器所施加的偏差。实际上，您的负载生成器正在耗尽资源，这会给您的负载生成器增加速度限制。请采取有意的欠载哲学来使用您的负载生成器。添加另一个负载生成器比因缺乏控制元素而攻击您的测试并需要重新运行测试时所产生的政治资本成本要便宜得多。它也比追逐看起来像是系统变慢但实际上是超载负载生成器的工程幽灵便宜得多。
0
我已经更新了我的问题。我尝试过使用同步定时器，但是没有成功。我已经看到你提供的那些建议。 - Masud Jahan
能否从分布式模式中实现？如果可以，JMeter脚本配置将是什么？ - Masud Jahan
同步计时器在分布式模式下无法工作。实际上，它可以工作，但它不知道其他从节点的存在。如果您需要在分布式模式下使用它，您可能需要考虑线程调度（也许结合本地同步计时器和较少的“group by”计数）。 - Dmitri T
0
  1. 如果你的电脑性能不够，建议使用Jmeter进行分布式测试。
  2. 请记住，理论上你可以每秒发送4000个请求，但它们在到达服务器之前需要一些时间，因此有可能不会在1秒内到达。为了避免这种情况，尝试使用高带宽局域网（例如，你可以将服务器托管在Azure云中，并在云中安装Jmeter）。
  3. 如果使用JMeter没有成功，请尝试使用Tank。这个工具专门用于高负载，甚至可以从一台机器发送10k个请求。
0
你想继续使用JMeter吗？ 否则Httperf是一个不错的工具，易于使用：
httperf --server=www.example.com --rate=4000 --num-conns=4000

例如。

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

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接