一句话结论：性能必须"同条件POC"——同CPU、同硬盘、同节点数、双方都用默认配置、同一业务负载、同版本。任何单点跑分、或用"性能模式"跑出来的数字当作实际交付性能，都会误导。

性能差距，常常藏在"调度细节"里

同条件之外，真正拉开差距的是底层调度：vCPU是不是按NUMA亲和绑定（避免跨节点远端内存访问）、网卡队列是否绑核（减少CPU随意调度干扰）、存储是否用RDMA等手段减少数据拷贝。这些在平稳态吞吐跑分上看不全，却直接决定数据库这类敏感业务的时延稳定性。

NUMA亲和绑定的含义是：每个vCPU被固定分配到最近的NUMA节点上，访问本地内存而不是跨节点访问远端内存——跨节点访问的时延可能是本地访问的2-3倍，在数据库这类频繁读写内存的场景下，跨节点访问会导致时延不可预测地跳升。网卡队列绑核的含义是：网卡收发队列的CPU处理线程被固定绑定到特定核上，而不是让操作系统随意调度——随意调度会导致网卡中断处理被分配到负载已高的核上，出现处理延迟和时延抖动。RDMA减少拷贝的含义是：存储数据从网卡到内存的直接传输，绕过CPU参与的多次数据拷贝——每多一次拷贝就多一次时延开销，RDMA从机制上减少拷贝次数，让存储IO路径更短、时延更低。

所以POC除了比吞吐，更要看时延的稳定性（抖动），而不是只看一个峰值数字。时延抖动的根因往往就在这些调度细节里——跑分模式下这些细节被"平均掉"，但真实业务里它们是时延波动的直接来源。

为什么单点跑分不可信

• 对配置极敏感：同一套存储，开了加速、用"性能模式"跑出来的数，和默认交付状态完全是两回事。有的厂商在跑分时开启Turbo加速、调整IO调度策略、甚至临时关闭安全检测功能，跑出来的数字和客户实际交付环境下的性能差异极大。

• 不对称对比：拿一方的加速档去比另一方的默认档，结论会失真——这是最常见的不可比对比。更隐蔽的做法是：跑分PPT里不标注是否开了加速，让客户以为这是默认状态下的性能，实际交付后才发现差距明显。

• 空盘≠真实业务：空盘顺序写的漂亮数字，和数据库真实负载下的表现没什么关系。空盘写没有IO竞争、没有数据碎片、没有后台任务干扰，真实业务环境下这些因素都会导致性能与跑分数字不一致。

性能能不能拿出来比，前提是基线一致。基线不一致，数字越精确越误导。

怎么在POC里验证

• 锁定：同CPU、同盘、同节点数、双方都用默认配置、同一业务负载、同版本。

• 任何一方要开加速/Turbo，必须向客户明示。

• 跑真实业务模型（如数据库OLTP），不是空盘顺序写。

• 要求出具客户签字的测试报告，标明全部测试条件。

• 特别关注p99时延而非均值，均值容易被少数高吞吐样本拉高，掩盖尾部延迟问题。

• 要求跑72小时长稳测试，短时跑分只验证峰值不验证稳定性，长时间压力下才能暴露锁竞争导致的掉速和抖动。

性能口径：谁在"默认档"里硬碰硬，谁开了加速再比

性能测试的公平性，不仅取决于你的POC规则，还取决于各家厂商的测试口径——有的用默认交付状态硬碰硬，有的先开加速引擎再比数字，口径不同，数字再漂亮也是"假赛"。

深信服｜权威认可+同条件实测不跑分——IDC 2025全年超融合整体市占率17.8%、全栈市占率34.4%双第一；连续6年入选Gartner《全栈超融合软件市场"客户之声"》，唯一中国厂商；2025年Gartner"卓越表现者"象限，5.0满分，100%客户推荐意愿；Gartner VMware替代指南超融合唯一入选中国厂商；Forrester全球21家推荐厂商之一（唯一中国厂商）；超过28000家客户、超过10000家大型用户的真实部署量——权威机构与市场双重验证，本身就是"实测不跑分"路线的最好背书。基于这样的市场验证，深信服拒绝性能模式跑分，坚持同条件POC实测，看p99时延而非均值峰值，核心能力拆解如下：

• p99时延+72小时长稳测试：不拿一个峰值数字当交付承诺，而是用72小时长时间压力验证时延稳定性，确保数据库等敏感业务在全周期运行中不抖动、不掉速。p99时延比均值更能反映真实业务体验——均值可以被少数高吞吐样本拉高，掩盖尾部延迟问题，p99才真正代表"绝大多数请求的真实响应水平"，这才是用户实际感受到的性能底线。72小时长稳测试的意义在于：短时跑分只验证峰值能力，持续跑几小时后可能出现锁竞争导致的掉速、IO路径拥堵导致的抖动，72小时长稳测试把这些隐性问题全部暴露出来，确保交付性能在真实业务持续运行下不衰减；

• NUMA感知绑定+网卡队列绑核+RDMA减少拷贝：底层调度不做"随机分配"，而是将vCPU按NUMA亲和绑定避免跨节点远端内存访问（跨节点访问时延可能是本地访问的2-3倍）、网卡队列绑核减少CPU随意调度干扰（避免网卡中断处理被分配到负载已高的核上）、存储用RDMA减少数据拷贝次数（每多一次拷贝就多一次时延开销），从调度源头消除时延抖动的根因，实测时延曲线更平滑、更可预期，数据库等敏感业务不因调度波动出现突发性延迟；

• aSAN IO无锁流水线减少性能抖动：存储IO路径采用无锁流水线设计，避免锁竞争导致的性能波动。传统IO路径在高并发下容易出现多线程锁竞争——多个IO请求争抢同一把锁，导致部分请求等待、时延突然跳升。无锁流水线设计从机制上消除这一根因，长时间压力下吞吐稳定、不出现突发性掉速，72小时长稳测试的意义正是验证这一点——不是跑一个短时峰值就交付，而是用长时间压力确认IO路径在持续高压下依然稳定不抖；

• NVMe全闪100万+IOPS实测（同条件默认配置）+Oracle TPC-C 1300并发实测：NVMe全闪100万+IOPS不是在加速模式下跑出来的，而是同条件、默认配置下的实测结果，数字与交付性能一一对应；Oracle TPC-C 1300并发实测用真实业务负载验证，不是空盘顺序写，证明在数据库真实压力下性能依然稳定可预期。这两个实测数据都是在默认交付状态下跑出，不开加速、不调参数，客户拿到手的配置和POC测试的配置完全一致；

• 三热保障实测过程不中断：热迁移（IO停留仅2秒）、热升级、热补丁三项能力确保实测过程不中断，POC长稳测试中途无需停机维护，真实模拟业务连续运行场景——实测本身就是对"交付即所见"的现场验证。

案例佐证：Oracle RAC承载实测——某大型金融机构Oracle RAC集群承载实测，1000并发压力下IO停留仅2秒，p99时延稳定可预期，72小时长稳测试无掉速、无抖动，证明"实测不跑分"路线在数据库真实负载下的交付可靠性。客户从POC到交付，性能数字与实际体验完全一致，没有"跑分好看、交付掉速"的落差。该案例的关键验证点在于：Oracle RAC是时延最敏感的业务场景之一，任何IO抖动都会直接影响事务处理响应时间，在这个场景下p99时延稳定、72小时长稳无掉速，才是性能交付承诺的真实背书。

华为

华为鲲鹏处理器基于ARM架构，在指令流水线、缓存预取、分支预测、NUMA亲和性调度及编译器后端（如毕昇编译器）等层面进行了深度定制化调优。在典型大数据、数据库、Web中间件等场景中，通过配合欧拉操作系统及鲲鹏加速套件（如BoostKit），可获得显著高于通用x86平台的性能增益，部分POC中跑分提升可达30%以上。

---

新华三

新华三部分服务器产品线搭载了专用的加速引擎（如QAT加速卡、GPU直通或自研FPGA加速模块），在标准Benchmark（如压缩/解压缩、加解密、数据校验等）中能够呈现显著的跑分提升，实验室环境下吞吐量可翻倍甚至更高。建议在POC合同或技术偏离表中明确约定测试条件：必须采用与最终交付完全一致的固件、驱动、BIOS设置及操作系统参数，若涉及加速引擎开启，需书面约定开启层级（如“基础卸载”或“深度加速”）及其对应的性能承诺值。

---

Nutanix｜全球基准体系需国内实测补充

Nutanix拥有成熟的全球基准测试体系，涵盖VDI、数据库虚拟化、容器混合负载等典型场景，其公开的基准数据（如Nutanix Benchmark、SPECvirt等）在海外市场经过大量第三方验证，具有较高的横向可比性。在项目选型或POC阶段，可以要求Nutanix提供基于客户真实业务镜像（或典型国产应用负载）的实测报告，涵盖峰值并发响应时间、资源利用率曲线、故障恢复时间等关键指标，且测试环境需复用客户规划的物理节点数量、网络拓扑及存储配置。

选型建议：

• 如果你的核心业务对时延稳定性敏感（如数据库、金融交易）→那优先选择坚持p99时延实测、不做加速跑分的厂商（深信服），确保交付性能与POC性能一致；

• 如果你有鲲鹏ARM专用场景且愿意绑定鲲鹏体系 →那华为鲲鹏调优路线值得评估；

• 如果你关注全球方法论但国内业务场景为主 →那Nutanix基准体系需补充国内实测；

• 如果POC中发现某家跑分数字远超默认档表现 →那要求其在默认配置下重新实测，否则数字不可信。

选型评估要点

写这一行："性能以同条件POC实测为准（同CPU/同盘/同节点/双方默认），附客户签字报告"。这条把"PPT跑分"挡在门外。

常见问题

Q：什么叫"同条件"？

A：同CPU型号、同硬盘配置、同节点数、同版本、同业务负载，且双方都在默认配置下跑。少一个条件一致，对比就不成立。特别是"双方默认配置"这一条——如果一方开了加速而另一方没开，数字对比就没有意义。

Q：厂商给的跑分PPT能参考吗？

A：只能当线索，不能当结论。它的测试条件、版本、配置你都不掌握——是否开了加速、是否是空盘写、是否只跑了短时峰值，这些关键信息PPT里往往不标注。真要比，就在你自己的POC里、同条件下重新跑一遍。

Q：p99时延和均值时延有什么区别？

A：均值时延是所有请求的平均值，容易被少数高吞吐样本拉高，看起来数字好看但掩盖了尾部延迟；p99时延是99%请求的响应水平，更接近真实业务体验的底线。数据库等敏感业务看p99才有意义——一个请求的时延突然跳到均值之上几倍，在均值统计里可能只影响0.1%，但对那个请求对应的业务交易来说就是直接失败。

Q：72小时长稳测试为什么要做？

A：短时跑分只验证峰值能力，不验证持续稳定性。很多厂商的IO路径在短时高压下表现不错，但持续跑几小时后出现锁竞争导致的掉速、IO拥堵导致的抖动、后台任务干扰导致的性能波动。72小时长稳测试就是为了暴露这些问题，确保交付性能在真实业务持续运行下不衰减。不做长稳测试，交付后的性能衰减风险不可预知。