Node.js Jmeter web应用程序性能测试质疑？

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

是否需要在jmeter中加载所有嵌入式资源以进行性能测试

我已经编写了一个Jmeter脚本，用于运行所有RESTAPI。这是否足以在服务器端找到应用程序性能

启动时间如何影响性能测试

为了得到准确的性能报告，测试需要执行多长时间

负载生成配置-从连接到应用程序群集的计算机/从不同的LAN生成负载

---

请了解我对以下问题的看法：

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

• 下载嵌入式资源
• 为它使用并发池
• 添加到您的测试计划中

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

最好有合理的上升和下降周期，以便负载可以逐渐增加，这样服务器和负载生成器端都不会经历峰值应力负载（除非是您的测试用例）。看

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

从“上坡=螺纹数”开始，根据需要向上或向下调整

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

通常情况下，峰值负载遵循一般规律，在“峰值”期间，应用程序在1-2小时的时间范围内处理了80%的请求，剩余的20%的请求在一天中剩余的20小时之间大致平均分配。因此，在几个小时内测试您的应用程序并提供预期的峰值负载就足够了。再次，如果时间允许，我建议您查看是否存在内存泄漏，并确定应用程序负载边界，以及它是否从压力负载中恢复

理论上，应用程序不应该关心请求源（除非它使用不同的逻辑来处理来自不同地理区域的请求）。有一点很明显：不要在同一台机器上运行load generator和正在测试的应用程序。如果一个JMeter实例无法创建足够的负载来实现测试场景，请转到

---

我想补充一些观点：

问题1和问题2:

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

考虑到上述情况，我想说，如果您花费20%的精力建立一个测试RESTAPI的负载测试，您将得到80%的结果。另一方面，如果你去做一个完全真实的测试，你将花费另外80%的努力，只会多得到20%的结果。这样做的效果是，在许多情况下，最好采用更简单的测试，即不能准确模拟现实。它能给你投资的时间带来最大的回报

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

问题4:我想说，您需要运行负载测试足够长的时间，以产生稳定的、具有统计意义的结果。这可能是5分钟或5小时，具体取决于您的场景，但在大多数情况下，半小时可能是最短的时间。测试的持续时间不应该取决于你的站点在现实生活中经历峰值负载的时间长短——除非你正在做某种浸泡测试

---

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

我是否需要在两个请求之间添加延迟？模拟负载有两种方法：1。仿效