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