性能测试后要收集哪些参数[关闭]

Posted 2023-03-07

【中文标题】性能测试后要收集哪些参数[关闭]

【英文标题】：What are the parameters to collect after the performance testing [closed]

【发布时间】：2014-03-09 13:01:55

【问题描述】：

我知道这可能是问题的重复，但我开始在我的 Web 项目中使用 WebPerformanceTest 和 LoadTest。我可以运行 WebPerformanceTest 和 Loadttest。

现在我需要与 Dev 团队或 Busniess 团队分享哪些参数/统计数据？我想到了这些。但是如果有人分享我可能需要考虑分享的其他参数，那就太好了。

1.应用可以支持的用户数

2.Reposne时间应用程序在可持续负载下可以给出什么

【问题讨论】：

您的问题与 LoadRunner 有关吗？

它不是特定于我要问这个问题的工具。一般来说，您要收集哪些参数/统计信息？

【参考方案1】：

以下您可以考虑分享的内容，

如果开发团队或利益相关者提到了 SLA，并且如果您的性能测试表明 Web 应用程序与这些 SLA 不匹配，那么您可以分享它 您和他们想到的下一个问题是为什么？ （尝试找出哪个部分/层占用最多时间或瓶颈）。这可以通过分析日志或使用分析器来完成，这会给你带来昂贵的东西，缓慢的组件 下一个问题是性能工程师的工作（如何解决这些问题并提高我的应用程序的性能）。如果您非常了解应用程序，请尝试对其进行调优，并在调优后获得改进结果，并与开发团队或利益相关者分享。

【参考方案2】：

如果您不限制响应时间，最大用户数可能会令人困惑。对于 100 毫秒请求，10 个同时用户意味着 100 rps（每秒请求数），对于 10 秒请求，100 个同时用户意味着只有 10 rps。 如果您使用简单的基于命中的测试（例如测试单页或特定请求性能），最好使用 rps 指标。

对于响应时间 - 平均时间也可能令人困惑，尤其是在响应时间差异很大的情况下，最好提供一些百分位数的响应时间。

即50 毫秒内 50%、55 毫秒内 75%、60 毫秒内 90%、70 毫秒内 95%、90 毫秒内 99% 和 10 秒内 100%。平均时间为 150 毫秒。对于某些服务，150 毫秒是非常好的，但是大约 1% 的非常慢的响应是不可接受的，并且仅使用平均响应时间和中等响应时间几乎找不到该问题。

另外，根据我的经验，收集资源使用情况统计信息（cpu、内存、I/O 强度和网络使用情况）对于确定瓶颈非常有帮助（即由于内存不足导致 I/O 高导致服务变慢）用于缓存）。

【参考方案3】：

你问的问题对吗？

对我来说，负载和性能测试的很大一部分是决定我的客户想要了解关于被测系统的哪些信息。有一个元素是“我可以向客户展示什么数据？”但这是基于解释他们的要求。客户可能不知道该问什么，作为测试人员，您的工作就是了解客户想要什么，并为他们提供他们想要的答案。

您列出的两个主题向用户展示了系统的显示方式：系统何时中断以及响应速度。根据用户负载的变化率和测试的持续时间，这些因素有多种变化。

其他因素包括正在测试的服务器计算机的各个部分的性能。 Visual Studio 负载测试可以在测试运行时从其他计算机收集性能数据。因此，他们可以监控 Web 服务器、数据库服务器、应用程序服务器等。在每台服务器上，可以收集有关 CPU 和内存使用情况、SQL 和 IIS 性能等的数据。所有这些数据都可以（最容易通过图表）与用户负载、错误率和事务时间进行比较，以确定系统的哪些部分有足够的空间、哪些部分很忙以及哪里出现了瓶颈。监控所有这些数据还可能会发现来自各种服务器的阈值警告，应根据 Microsoft 文档以及可能的其他来源检查它们，以确定它们是否会对系统性能产生不利影响，以及是否应该对其进行更详细的调查。

这些和许多其他想法都是可能的，但这一切都可以追溯到制定您的客户想要学习的内容。

same question 是在另一个论坛上被问到的，上面的话和我在那里发布的答案几乎相同。

【参考方案4】：

您可以向您的客户提供以下详细信息：

响应时间 每秒点击次数 吞吐量 每秒连接数 第一次缓冲 错误数 交易图表 CPU、内存和磁盘利用率 网络利用率（如果适用） 数据库插入/更新/删除记录数

【参考方案5】：

听起来您根本没有（或非常差）要求，并且您在性能测试和工程领域没有深入的了解。至于收集什么

测试前：

构成负载的业务功能的完整负载配置文件。

每个业务功能的文档。每个业务职能部门的时间项目。

每个定时业务功能的预期响应时间

特别注意思考时间和迭代节奏

来自当前系统的 Web 日志，因此您可以客观地衡量在任何给定时间有多少人在系统上，而不是有多少会话处于活动状态且尚未超时。

测试环境与生产环境具有一些定义的匹配级别，以适当地扩展您的负载。

在测试中

响应时间与业务功能在需求/用户故事上的时间相匹配

其他枚举数据点的需求（命中、返回量等）

测量被测系统中的任何有限资源，以识别慢速响应时间的瓶颈。您可以从顶层（CPU、磁盘、内存、网络）开始，然后在发现顶层资源受限时逐步了解这些统计信息。

测试后：

执行概述：您是否满足要求（是|否）

详细数据：响应时间、监控峰值

分析：阻碍您前进的可能瓶颈在哪里

如果您试图代表人类行为，那么在任何情况下都不应消除思考时间。思考时间或单个会话上请求之间的时间被纳入客户端-服务器模型的定义中，当您将其减少到零时，您的测试变得越来越不能预测生产中会发生什么

【参考方案6】：

通常，它基于您希望在给定硬件和环境下实现的基准。 以下是关键参数

并发用户数（手动和系统线程） 交易数据和现有数据的加载

响应时间（通常是页面）

CPU、内存和磁盘 IO 以及网络的吞吐量利用率

带宽（适用于与外设集成的情况 系统）

成功百分比