杰米web应用性能测试疑惑？

Question

我是jeter的新手，对Web应用程序性能测试有一些疑问。

1. 是否有必要将所有嵌入式资源加载到jmeter中以进行性能测试？
2. 我编写了一个执行所有 REST API 的 Jmeter 脚本。这是否足以在服务器端找到应用程序性能？
3. 爬坡时间如何影响性能测试？
4. 测试需要执行多长时间才能获得准确的性能报告？
5. 负载生成配置 - 从连接到应用程序群集的计算机/从不同的 LAN 生成负载 ？

Answer 1

我想补充一些观点：

问题1

这里也可以应用帕累托原理——这意味着，正确地模拟现实需要付出很多努力，下载浏览器用来呈现页面的所有资源，并给不同的网址赋予适当的“权重”，准确地模拟用户行为。这就是许多负载测试失败的地方，因为准确地模拟现实非常非常困难。正如前面的回复提到的，大多数静态内容通常都是通过CDN或类似的方式提供的，你真正想测试的通常是你自己系统处理流量的能力。

考虑到上述情况，我想说的是，如果您花费20%的精力来设置测试REST API的负载测试，您将获得所需结果的80%。另一方面，如果你进行一个完全真实的测试，你将花费另外80%的努力来获得20%的结果。这样做的效果是，在许多情况下，最好进行更简单的测试，这并不能准确地模拟现实。它为您投入的时间提供了最大的回报。

问题3：完全同意之前的回答。慢慢增加，除非你的特定用例看到非常突然的流量高峰（比如如果你是在线拍卖服务或门票销售或类似服务）。配置测试也是一个好主意，这样它在爬升到峰值负载后就会在“平台”上花费一些时间，而不仅仅是在达到峰值后停止负载测试。

问题 4：我想说的是，您需要运行负载测试足够长的时间才能产生稳定的、具有统计显著性的结果。根据您的方案，这可以是 5 分钟或 5 小时，但在几乎所有情况下，半小时可能是一个很好的最短时间。测试持续时间不应取决于您的网站在现实生活中往往会经历峰值负载的时间 - 除非您正在进行某种浸泡测试。

问题5：流量来源有时值得考虑，因为不同的源位置会导致（模拟）客户端和服务器之间的不同网络延迟，这会影响交易率。如果您在位于纽约的系统上运行具有1,000个VU的负载测试，并从澳大利亚生成流量，由于高网络延迟，您每秒不会获得很多交易。如果您在纽约使用负载生成器运行相同的测试，您的成单率会高得多，因为网络延迟要低得多。当然，您可以随时添加更多并发客户端/VU/连接，并在高延迟网络链路上获得与在低延迟链路上相同的成单率，但代价是强制服务器保持更多（TCP）连接状态，使用更多文件描述符和缓冲内存。也就是说，可能不是一个非常现实的场景。

Answer 2

请找到我对以下问题的看法：

> < li>

我认为负载测试需要尽可能真实，因此必须表现真实的浏览器行为。真正的浏览器下载嵌入式资源，如脚本、图像和样式，此外，它们使用2 - 8个线程的并发线程池来并行完成这项工作。所以你需要类似地配置JMeter。然而，真正的浏览器只下载这些资源一次，在随后的请求中，它们从缓存中返回嵌入的资源。因此，请确保将JMeter配置为:

< li >下载嵌入式资源 < li >对其使用并发池 < li >将HTTP缓存管理器添加到您的测试计划中

从功能角度来看，这应该足够了，因为通常静态内容是单独提供的。然而，请看第1点，如果您有可能模拟真实的用户行为，请尝试一下

最好有合理的上升和下降周期，这样负载可以逐渐增加，这样服务器和负载生成器双方都不会遇到峰值压力负载（除非它是您的测试用例）。请参阅JMeter留档中关于上升的部分

爬坡需要足够长的时间，以避免在测试开始时出现过大的工作负载，并且要足够短，以使最后一个线程在第一个线程完成之前开始运行（除非有人希望这样做）。

从斜升=线程数开始，并根据需要上下调整。

默认情况下，线程组配置为循环一次其元素。

通常，峰值负载遵循一般的帕累托原则，在“峰值”期间，应用程序在1-2小时的时间范围内处理了80%的请求，其余20%的请求或多或少地平均分布在一天中剩余的20个小时之间。因此，测试提供预期峰值负载的应用程序几个小时应该就足够了。同样，如果时间允许，我建议进行Sock测试，看看是否有任何内存泄漏，并进行压力测试以确定应用程序负载边界以及它是否从压力负载中恢复

理论上，应用程序不应该关心请求来源(除非它使用不同的逻辑来处理来自不同地理区域的请求)。有一点很明显:不要在同一台机器上运行负载生成器和被测应用程序。如果一个JMeter实例不能创建足够的负载来实现测试场景，那么就进行分布式测试