我是 jmeter 新手，对 Web 应用程序性能测试有一些疑问。
【问题讨论】：
标签： node.js web-applications jmeter performance-testing load-testing
请在以下问题上找到我的看法：
我认为负载测试需要尽可能真实，因此必须代表真实的浏览器行为。真正的浏览器会下载脚本、图像和样式等嵌入式资源，此外，它们使用 2 - 8 个线程的并发线程池并行执行此操作。所以你需要类似地配置JMeter。然而，真正的浏览器只下载这些资产一次，在随后的请求中，它们会从缓存中返回嵌入的资源。因此，请确保将 JMeter 配置为：
从功能的角度来看，这应该足够了，因为通常静态内容是单独提供的。但是请参阅第 1 点，如果您有可能模拟真实的用户行为 - 去吧
最好有合理的加速和减速周期，这样负载可以逐渐增加，这样服务器和负载生成器端都不会遇到峰值压力负载（除非它是您的测试用例）。见the bit on ramp-up from JMeter documentation
加速需要足够长以避免在测试开始时工作负载过大，并且足够短以使最后一个线程在第一个线程完成之前开始运行（除非有人希望发生这种情况）。
从 Ramp-up = 线程数开始，然后根据需要向上或向下调整。
默认情况下，线程组被配置为遍历其元素一次。
通常峰值负载遵循一般Pareto principle，在“峰值”期间，应用程序在 1-2 小时的时间范围内处理了 80% 的请求，其余 20% 的请求或多或少平均分布在一天中剩余的 20 小时内。因此，测试您的应用程序提供几个小时的预期峰值负载就足够了。同样，如果时间允许，我会建议去Soak testing 看看是否有任何内存泄漏，并让Stress testing 确定应用程序负载边界以及它是否从压力负载中恢复
理论上，应用程序不应该关心请求来源（除非它使用不同的逻辑来处理来自不同地理区域的请求）。有一点很明显：不要在同一台机器上运行负载生成器和被测应用程序。如果一个 JMeter 实例无法创建足够的负载来实现测试场景 - 去distributed testing
【讨论】：
我想补充一些观点：
问题 1 和 2：
帕累托原则也可以在这里应用——这意味着，要正确模拟现实需要付出很多努力，下载浏览器用于渲染页面的所有资源，并为不同的 URL 赋予适当的“权重”，模拟用户行为准确。这是许多负载测试失败的地方，因为准确地模拟现实非常非常困难。正如前面的回复所提到的，大多数静态内容通常是通过 CDN 或类似方式提供的，而您真正想要测试的通常是您自己的系统处理流量的能力。
考虑到上述情况，我想说，如果您花费 20% 的精力来设置测试 REST API 的负载测试，您将获得 80% 的结果。另一方面，如果您进行完全真实的测试，您将花费另外 80% 的努力来获得 20% 的结果。这样做的效果是，在许多情况下，最好进行更简单的测试，这不准确地模拟现实。它可以为您提供最大的投资时间回报。
问题 3： 完全同意之前的回答。慢慢增加，除非您的特定用例出现非常突然的流量高峰（例如，如果您是在线拍卖服务或门票销售或类似服务）。配置您的测试也是一个好主意，以便在达到峰值负载后在“平台”上花费一些时间，而不是在达到峰值后停止负载测试。
问题 4： 我想说您需要运行足够长的负载测试才能产生稳定的、具有统计意义的结果。这可能是 5 分钟或 5 小时，具体取决于您的情况，但在大多数情况下，半小时可能是一个很好的最短目标时间。测试持续时间不应取决于您的网站在现实生活中往往会经历多长时间的峰值负载 - 除非您正在进行某种浸泡测试。
问题 5： 流量来源有时值得考虑，因为不同的来源位置会导致（模拟的）客户端和服务器之间的网络延迟不同，从而影响交易率。如果您在位于纽约的系统上运行 1,000 VU 的负载测试，并生成来自澳大利亚的流量，由于网络延迟较高，您每秒不会获得大量事务。如果您改为使用纽约的负载生成器运行相同的测试，您的事务率将高出 很多，因为网络延迟要低得多。当然，您总是可以添加更多并发客户端/VU/连接，并在高延迟网络链路上获得与在低延迟链路上相同的事务率，但代价是迫使服务器保留更多(TCP) 连接状态，使用更多的文件描述符和缓冲内存。 IE。可能不是一个非常现实的场景。
【讨论】：