在国产CPU环境下验证研发平台性能，关键是把“能不能用”变成“在什么配置、什么并发下达到什么水平”。这需要先固定CPU型号与核数、内存、磁盘、操作系统和中间件版本，再选取研发日常高频场景，用可复算的指标采集数据，并与同配置对照环境或厂商承诺值比对。本文给出一套从目标拆解、指标口径到执行步骤和结果解读的方法，适用于尚未预设具体型号已完成适配的验证阶段。
要点总览（TL;DR）
- 验证性能前先固定CPU型号与核数、内存、磁盘、操作系统和中间件版本，任何一项变化都要重建基线，否则前后数据不可比。
- 场景按研发高频动作选取：登录鉴权、工作项列表与检索、流水线构建、制品上传下载、代码仓库操作、多人并发协作，每个场景配响应时间、吞吐量、错误率、资源占用等指标。
- 指标必须写明公式与分母：响应时间用P50/P95并注明采样窗口与请求总数，吞吐量=成功请求数÷统计时长，错误率=失败请求数÷总请求数。
- 采集按单用户基线、阶梯加压找拐点、长稳运行看退化、混合场景验争抢的顺序推进，对照环境使用相同脚本、数据规模和并发设置。
- 结论写成条件式判断，绑定配置、并发与数据规模；未纳入验证的型号与认证范围不能推断为已适配或未适配。
验证目标：要回答哪些性能问题
功能可用性验证回答的是“平台能否在国产CPU环境上正常启动、登录、打开页面、提交数据”，判定方式是功能是否可用、报错是否可复现。性能验证回答的是另一组问题：在给定硬件和软件版本下，平台的处理能力、响应速度和稳定性处于什么水平。两者不能互相替代，功能跑通不等于性能达标，性能数据也不能说明功能完整。
把验证目标拆成四类可回答的问题，每类配一种判定方式：
| 问题类型 | 具体问题 | 判定方式 |
|---|---|---|
| 功能可用性 | 核心业务流程能否在目标环境完整跑通 | 按用例逐项执行，记录通过/失败与报错信息 |
| 容量是否够用 | 在目标并发用户数下，关键操作响应时间是否落在业务可接受范围 | 对比预设的响应时间阈值（由业务方确认），看P95是否越线 |
| 长稳是否退化 | 持续运行数小时至数天后，响应时间、内存占用、连接数是否持续恶化 | 对比长稳前后同一场景的P95与资源占用曲线 |
| 与对照环境差距 | 同配置下国产CPU环境与对照平台的性能差距有多大，差距集中在哪些场景 | 同口径数据并列比较，按场景给出比值 |
结论应写成条件式判断，例如“在8核、32GB内存、目标并发50的条件下，工作项列表查询P95为X毫秒”，而不是给出“性能合格”这类脱离条件的单一结论。验证开始前先确认这四类问题各自由谁判定、阈值从哪来，避免采完数据才发现没有比较基准。
指标与范围：选哪些场景和度量项
场景选取的原则是贴近研发人员的日常高频动作，覆盖读、写、构建、传输和并发协作五类负载。场景过多会拉长验证周期，过少则容易遗漏瓶颈，建议以下六个场景作为基础集合，再按实际使用情况增删。
| 场景 | 主要指标 | 单位 | 观察目的 |
|---|---|---|---|
| 登录与鉴权 | 响应时间P50/P95、错误率 | 毫秒、% | 认证链路与数据库查询在国产CPU上的基础开销 |
| 工作项列表与检索 | 响应时间P50/P95、吞吐量 | 毫秒、请求/秒 | 列表渲染、条件过滤与全文检索的计算密集程度 |
| 流水线构建 | 构建时长、成功率、CPU占用 | 秒、%、核数占比 | 编译类负载对指令集与多核调度的敏感度 |
| 制品上传下载 | 吞吐量、传输耗时、磁盘IO占用 | MB/秒、秒、% | 大文件传输受磁盘与网络栈影响的程度 |
| 代码仓库操作 | 克隆/拉取耗时、并发操作错误率 | 秒、% | 仓库读写与压缩解压在国产CPU上的表现 |
| 多人并发协作 | 响应时间P95、错误率、连接数 | 毫秒、%、个 | 并发写入、通知推送与锁竞争下的相互影响 |
指标与业务体验的对应关系要写清楚：响应时间对应操作等待感，吞吐量对应单位时间能服务多少请求，错误率对应操作失败概率，资源占用对应扩容需求和成本，构建时长对应研发反馈速度。与这些体验无关的指标，例如单纯的系统调用次数，不必纳入主评估集，可作为排查瓶颈时的辅助数据。
在验证流程中，工作项、流水线、制品和测试记录本身需要由研发平台承载。ONES 信创版适配鲲鹏、飞腾CPU，以及银河麒麟、统信等操作系统和达梦数据库，可作为搭建验证环境时的选型参考起点；具体版本对应关系需向厂商核验。验证过程中产生的用例、执行记录和缺陷可借助 ONES TestCase 与需求、任务、迭代关联，形成可追溯的测试流程，便于把每轮性能数据与对应版本、环境配置绑定归档。
数据口径：公式、分母与采集条件
同一份数据在不同口径下会得出不同结论，因此每个指标都要写明公式、分子分母、时间窗和单位，保证他人能按同样规则复算。
| 指标 | 公式 | 单位 | 必须注明的条件 |
|---|---|---|---|
| 响应时间P50/P95 | 将采样窗口内全部成功请求的耗时升序排列，取第50、95百分位对应值 | 毫秒 | 采样窗口起止时间、请求总数、是否含超时请求 |
| 吞吐量 | 成功请求数 ÷ 统计时长 | 请求/秒 | 统计时长、并发数、是否含预热阶段 |
| 错误率 | 失败请求数 ÷ 总请求数 × 100% | % | 总请求数（分母）、失败判定标准（超时、5xx、业务错误码） |
| 资源占用 | 采样周期内CPU、内存、磁盘IO的平均值与峰值 | %、GB、MB/秒 | 采样间隔、采样工具、是否含其他进程干扰 |
| 构建时长 | 从触发到构建结束的时间差 | 秒 | 代码版本、依赖缓存状态、构建机配置 |
采集条件需要固定并记录：并发数（虚拟用户数或线程数）、压测时长、预热时间、测试数据规模（如工作项条数、仓库大小、制品体积）、缓存状态（冷缓存或热缓存）。预热时间不计入统计窗口，但要单独记录预热阶段的异常。
异常处理规则要事先约定：超时请求计入总请求数和失败请求数，不计入响应时间百分位计算，避免拉高P95造成误读；缺失值按失败处理并在报告中单列数量；分母为零时该指标标记为“不适用”，不写0%或0，防止被误读为表现良好。若某场景请求全部失败，吞吐量为0且错误率100%，此时应优先排查环境问题而非解读性能。
评估步骤：从基线到加压到长稳
采集顺序影响数据可比性，建议按“固定基线—单用户参照—阶梯加压—长稳运行—混合场景”推进，每阶段留存配置快照和原始数据。
- 固定硬件与软件基线。记录CPU型号与核数、内存容量与频率、磁盘类型、操作系统及内核版本、中间件与数据库版本、平台版本号。任何一项变更都要重新建立基线，否则前后数据不可比。
- 单用户基线测试。单用户依次执行各场景操作，每场景重复足够次数（如不少于100次），得到无并发干扰下的响应时间参照点。这一步的产物是各场景的P50/P95基准值和资源占用底数。
- 阶梯加压。从低并发开始按固定步长提升（如10、20、50、100并发），每档稳定运行一段时间后采集数据，观察响应时间随并发上升的曲线，找到响应时间明显抬升的拐点和吞吐量不再增长的饱和点。每档记录并发数、吞吐量、P95、错误率和资源占用。
- 长稳运行。在目标并发下持续运行数小时至数天，按固定间隔采样响应时间、内存占用、连接数和线程数，观察是否出现内存持续增长、连接泄漏或响应时间缓慢抬升。产物是时间序列曲线和首尾时段对比。
- 混合场景。按真实使用比例同时施加多类负载，例如检索、构建、制品传输并行，观察单场景指标在混合负载下是否劣化，识别资源争抢点。
每阶段记录项统一为：环境配置快照、测试脚本版本、数据规模、并发数、起止时间、原始采样文件位置。对照环境使用相同脚本、相同数据规模和相同并发设置，仅替换CPU平台，这样比较才有意义。
算例：一次工作项列表查询的评估
以下为演示情景，数字用于说明计算方法，不代表任何产品的实测结果。
假设环境为8核国产CPU、32GB内存、SSD磁盘，数据库与平台版本固定。测试数据为50万条工作项，冷缓存启动后预热5分钟，正式统计窗口10分钟，并发50，共发出成功请求12000次、失败请求300次，总请求12300次。响应时间采样中，P50为180毫秒，P95为620毫秒。
- 吞吐量 = 12000 ÷ 600秒 = 20请求/秒。
- 错误率 = 300 ÷ 12300 × 100% ≈ 2.44%。
- P95为620毫秒，表示95%的成功请求在620毫秒内完成。
与对照环境比对：同脚本、同数据规模下，对照平台P95为480毫秒、吞吐量26请求/秒、错误率0.8%。则该场景国产CPU环境P95约为对照的1.29倍，吞吐量约为对照的77%。若业务方预设该场景P95阈值为800毫秒、错误率上限1%，则响应时间达标、错误率超出上限，结论应写成“在8核、50并发、50万条数据条件下，P95为620毫秒，满足响应时间阈值；错误率2.44%高于1%上限，需排查失败请求的集中类型后再判断是否可用”。单看P95达标就宣布整体可用，会掩盖错误率问题。
解读与限制：结论能说到什么程度
性能结论必须绑定配置、并发和数据规模三要素，脱离条件的“性能良好”没有信息量。建议使用固定表述模板：“在[CPU型号与核数、内存、操作系统与数据库版本]环境下，[场景]在[并发数]、[数据规模]条件下，P95为[数值]，吞吐量为[数值]，错误率为[数值]，与对照环境相比[比值]。”换一个并发或数据量，结论需要重新验证。
国产CPU与对照平台的差异可能来自多个因素：编译器对目标指令集的优化程度、内存带宽与缓存层次、多核调度策略、数据库和中间件的版本匹配、JIT或解释执行的效率。单次对比只能说明“在该配置组合下观察到差距”，不能直接归因于CPU本身，也不能据此推断其他型号或其他版本的表现。
解读时注意三点限制：其一，单指标不能代表整体绩效，响应时间达标而错误率偏高、或吞吐量接近但长稳退化，都属于需要继续排查的情况，应多场景综合判断；其二，阶梯加压得到的拐点与测试脚本、数据分布强相关，换一套请求比例结果会变化；其三，验证覆盖的是已测试的配置组合，未纳入验证的CPU型号、操作系统版本或认证范围不能推断为已适配或未适配，适配认证的具体清单与版本需以厂商正式材料为准。
把每轮验证的环境快照、原始数据和结论一并归档，并与对应版本关联，后续平台升级或环境变更时可以复用同一口径复测，使性能数据在版本之间保持可比。
常见问题
验证时找不到同配置的对照环境，还能得出有效结论吗？
可以，但结论形式要调整。没有对照环境时，改用两类基准：一是业务方事先确认的响应时间与错误率阈值，二是厂商提供的承诺值或公开的性能说明。此时结论只能回答“是否满足预设阈值”，无法给出与对照平台的差距比值。若两者都没有，建议先做单用户基线和阶梯加压，把拐点、饱和点和长稳曲线作为内部参照，等后续有条件时再补对照数据，并在报告中注明缺少对照这一限制。
阶梯加压时并发步长和每档持续时间怎么定？
步长取决于目标并发量级：目标并发在100以内时，可按10、20、50、100逐档提升；目标更高时按比例放大步长，避免档位过多拉长周期。每档持续时间要覆盖预热和稳定采集两段，常见做法是预热几分钟后正式采集10至15分钟，确保采样请求数足够计算P95。档位过密或每档过短，曲线抖动大，拐点判断容易失真；档位过疏则可能跳过拐点区间。步长与时长确定后写入测试脚本说明，后续复测沿用同一设置。
长稳运行要跑多久，出现内存缓慢增长是否一定算问题？
长稳时长按业务连续使用习惯确定，常见起点是8至24小时，关键系统可延长到数天。判断内存增长要看曲线形态：启动后一段时间内上升并趋于平稳，多与缓存预热和连接池建立有关；持续线性上升且不回落，则需结合垃圾回收日志和连接数排查是否存在泄漏。同时观察响应时间是否随运行时长缓慢抬升、错误率是否上升。单看内存绝对值不足以定性，应把内存、连接数、响应时间三条曲线放在同一时间轴上比对。
混合场景的比例怎么设定才贴近真实使用？
比例应来自实际使用数据，例如从访问日志或平台统计中提取各操作的请求占比，再按比例分配虚拟用户。缺少使用数据时，可按读多写少的常见形态设定初始比例，并在报告中注明这是假设值。混合场景的重点不是复现精确比例，而是观察单场景指标在并行负载下是否明显劣化，以及资源争抢集中在CPU、内存还是磁盘IO。比例变化会改变结果，因此每轮验证都要记录所用比例，保证版本之间可比。
验证结论能否用于判断某个国产CPU型号是否适配平台？
不能。性能验证覆盖的是已测试的配置组合，回答的是该组合下达到什么水平；适配认证涉及兼容性测试与厂商正式材料，两者范围不同。验证中未纳入的CPU型号、操作系统版本或数据库版本，既不能推断为已适配，也不能推断为不适配。若需要确认适配范围，应以厂商正式发布的适配清单与认证信息为准，并把验证所用的具体版本记录在报告中，便于后续核对。
