我想在我的测试网络应用中测量文档的加载时间。我为此使用了 JMeter，但每次运行我都会得到不同的值。我正在总结报告中测量平均时间。
我不确定该值是否正确。这种方法是否正确或是否有可用的插件 JMeter？
我已使用 HTTP watch 来获取渲染时间，但我不能为超过 1 个用户使用该工具（负载测试）。我正在使用 JMeter 2.13。你能帮我解决这个问题吗？
【问题讨论】：
标签： performance time load jmeter performance-testing
借助汇总报告或 csv / xml 结果，您可以获得有关响应时间的所需信息，但
如果您还需要在响应时间中包含渲染时间，请使用 loadrunner（商业）、selenium（开源）等工具。我个人认为客户端渲染不是一个可衡量的值，除非所有访问应用程序的用户都具有相同的硬件、软件和网络访问配置。然而，当 JMeter 测试以系统的峰值负载运行时，您可以使用各种浏览器手动浏览站点，并在开发人员工具的帮助下找到渲染时间。
【讨论】：
当您使用独立于工具（Jmeter、LoadRunner、SOASTA、Grinder 等）的直接 HTTP 协议层虚拟用户时，您将计时的是来自服务器的请求/响应信息，非常客户端本地处理 JavaScript 和最终“在屏幕上绘图”呈现的低着色。
直到服务器由于请求数量或网络限制而降级为止，您可以调整的唯一区域是页面架构，如果您在部署之前等待最后 100 码来解决问题，那么您就是可能有麻烦了。
Steve Souders 在他的著作《高性能网站》和相关著作中写了很多关于页面架构的文章。简而言之，经验法则归结为发出更少的请求、更小的响应并从最接近客户端的位置提供数据。这些具有将 Web 客户端（网络）最昂贵的有限资源最小化的效果。例如，浏览器精灵减少了对图像的调用次数，缩小和压缩减少了传输的大小，而 CDN 将请求项目的跳数更改为更接近最终客户端的位置。
为了影响对页面架构的更改，您需要向上游移动到您的开发周期和功能测试周期。您将需要与开发部门合作以实施硬门，如果没有首先通过与设计相关的性能门，则无法将代码/页面提交给项目。您的开发团队和功能测试成员将需要尊重这些大门。至于大门应该是什么，我建议您参考 Souders 先生的作品，作为构建大门规则的重要数据来源。
这使您达到“为一个人工作：为一个人工作”的水平。然后，您可以将其用作已知产品来回答与服务器可伸缩性相关的问题，以及从请求到客户端的服务何时开始降级。如果您的组织中有 CDN，请务必在您的测试模型中考虑到这一点，因为如果您不这样做，那么您的服务器与生产相比将会超载。
至于“渲染”或在屏幕上绘图的实际速度？您需要购买速度更快的视频卡，除非浏览器制造商进行更改。加速 JavaScript？确保您的所有 JavaScript 尽可能小且精简。让您的功能测试团队在带有大量插件和低功耗硬件的非常脏的浏览器上进行测试，以获得最大的超出规范的响应。如果您需要从客户端（浏览器/操作系统/某些硬件）查看标准硬件模型的外观，则可以处理 HTTP 请求日志中的数据，特别是与客户端配置信息相关的用户代理。
【讨论】：
我怀疑您能否获得 2 个完全相同的测试运行结果，总会有由底层硬件和软件实现引起的某种形式的波动。您应该会收到类似的结果，但会有一些统计噪音。
如果不是这种情况，您的 JMeter 测试可能配置错误。从“真实性”的角度考虑以下配置：
【讨论】：