openUBMC性能测试指标和标准

QA SIG
1

问题背景

社区当前关于openUBMC性能测试的文档很少，只找到一份QEMU性能测试报告 - CICD SIG - openUBMC 论坛。QA sig会议中有过讨论，但没有开启会议录屏，已经无法查看。

求助内容

想问一下做openUBMC整体性能测试，常用的测试指标包含哪些以及测试通过与否的标准

2

QA SIG答复：
参考QA/Test_Guide/openUBMC SIT DFX测试指导.md

性能测试

1. 定义

性能测试是通过模拟正常、峰值、负载等场景，测试系统的响应速度、处理能力、资源占用等性能指标，验证系统是否满足设计要求和用户使用需求。

2. 测试目的

  • 验证openUBMC的核心操作响应时间、并发处理能力符合性能指标。
  • 监控openUBMC运行时CPU、内存、Flash等资源占用，确保无异常超标。
  • 识别性能瓶颈，确保openUBMC在高负载场景下仍能稳定运行。
  • 保障用户操作体验，避免卡顿、延迟等问题。

3. openUBMC测试场景

  • 响应时间：测试IPMI命令（如读取传感器数值、获取SEL日志）、WebUI操作（如登录、配置修改）、固件升级的平均响应时间，建议确保≤1s（单命令）、≤3s（复杂操作）。
  • 并发处理：模拟10-20个客户端同时通过IPMI/Redfish访问openUBMC、执行命令，验证无请求丢失、无响应超时，openUBMC正常处理所有请求。
  • 资源占用：长期运行openUBMC，监控CPU占用、内存占用率，无持续升高（排除内存泄漏）。
  • 吞吐量：测试单位时间内openUBMC可处理的SEL日志写入数量、传感器数据刷新次数，确保满足设计阈值（如每秒≥10条日志写入）。
  • 固件升级性能：测试各个固件的升级时间。
  • 启动时间：AC上电和openUBMC复位场景，openUBMC的启动时间。
  • 日志收集时间：验证一键收集系统日志的时间

5. 测试通过标准建议（建议，需要根据具体硬件性能来制定）

  • 单条IPMI命令响应时间≤1s，复杂操作（固件升级、批量配置）响应时间≤3s，无超时。
  • 10-20个客户端并发访问时，请求无丢失、无响应超时，命令执行成功率100%。
  • 长期和压力运行openUBMC时，CPU占用≤80%、内存占用≤60%，无持续升高，无内存泄漏。
  • SEL日志写入吞吐量≥10条/秒，传感器数据刷新正常，无数据丢失。
  • 固件升级过程平稳，无卡顿、中断，升级成功率100%，升级后功能正常，升级时间建议小于10min。
  • openUBMC启动时间<2min
  • 一键收集系统日志的时间<6min
3

答案内容由AI生成，仅供参考：
总结

目前，openUBMC 的整体性能测试缺少一份官方的、统一的指标基线来作为明确的“通过”或“失败”标准。常用的测试指标主要关注系统启动耗时和资源利用率。开发者进行性能测试时，可以将性能指标量化，并与历史测试数据或不同运行模式下的性能进行对比，以评估系统的稳定性与效率。

点击此处查看详细分析解答

根据您提供的信息，社区中关于 openUBMC 性能测试的文档确实非常有限。不过，我可以从上下文提供的材料中，为您梳理出与 openUBMC 性能测试相关的指标和标准的参考信息。

openUBMC 性能测试指标

根据上下文，性能测试旨在评估系统的速度、响应性、稳定性和效率。对于 openUBMC 整体性能测试，常见的测试指标包括：

  • 启动阶段耗时 (Boot Phase Time)：这是评估系统初始化速度的关键指标。上下文中的一份 QEMU 性能测试报告 提供了一个具体的测试案例，测量了从启动到不同服务就绪所需的时间，例如：

    • IPMI 就绪时间
    • Redfish 就绪时间
    • SSH 就绪时间
    • Telnet 就绪时间
    • Web 就绪时间

  • 接口响应性能：如 特性测试方案指导 所述，这是评估接口处理请求速度的指标。

  • 数据传输性能：衡量系统在一定时间内传输数据能力的指标。

  • 软硬件加载性能：评估软件或硬件组件加载到系统中所需时间的指标。

  • 资源使用情况：性能测试也应关注系统资源消耗，例如上下文提及的：

    • CPU 使用率（峰值和平均值）
    • 内存使用量（物理内存 RSS 和虚拟内存 VMS）
    • 系统启动时间

性能测试通过/失败标准

关于测试通过与否的标准，上下文信息表明：

  1. 当前缺乏官方基线：根据社区论坛 Topic 1482 的讨论，openUBMC 社区当前并没有正式发布的性能指标基线。社区维护者 Openubmc Liuyujie 曾回应，需要通过在社区版本中提需求，计划在 Q3 或 Q4 规划输出性能基线。

  2. 性能指标应可量化：特性测试方案指导 文档明确指出，在进行性能测试时，性能指标必须可量化，并且要有明确的测试方法和观察方式。这意味着每个测试指标都应对应一个具体的数值预期。

  3. 可参考的对比基准：虽然没有绝对的通过/失败标准，但性能测试通常用于对比。例如，QEMU 性能测试报告 中通过对比 KVM 和 TCG 两种虚拟化模式下的性能数据（如 KVM 的 Web 启动耗时 80.63s 对比 TCG 的 410.03s），来定性评估性能优劣。这种对比测试本身也是一种有效的评价方式。

  4. QA 仓作为参考：社区 Young Yang007 指出，社区版本的测试范围在 QA 组进行过评审，测试结果会归档到 QA 仓 中。这为开发者提供了一个了解过往版本测试结果的参考点。

总结

目前，openUBMC 的整体性能测试缺少一份官方的、统一的指标基线来作为明确的“通过”或“失败”标准。常用的测试指标主要关注系统启动耗时和资源利用率。开发者进行性能测试时，可以将性能指标量化，并与历史测试数据或不同运行模式下的性能进行对比，以评估系统的稳定性与效率。