4. 加密性能测试方法与工具：openssl speed、cryptsetup benchmark
性能调优，不能靠猜。
我见过不少团队，一上来就上生产，结果系统跑起来才发现性能瓶颈在加密这环。那时候再回头排查，代价就大了。所以，我个人的习惯是：不管用什么加密方案，先在测试环境压一轮，摸清硬件的底牌。
本章我们就来聊聊两个最常用的加密性能测试工具：openssl speed 和 cryptsetup benchmark。前者适合应用层的对称/非对称算法测试，后者专门看块设备的磁盘加密吞吐。
4.1 openssl speed：应用层加密性能标尺
openssl speed 是 OpenSSL 自带的性能测试工具。说白了，它能告诉你，你的CPU每秒钟能算多少个加密操作。我通常在性能压测前，会先跑一轮看看硬件能到多少。
4.1.1 基本用法
最直接的用法，一行命令就能跑完全部对称算法：
openssl speed -evp aes-256-gcm这里我用 -evp 指定引擎，它会自动启用硬件加速（比如 Intel 的 AES-NI）。如果不加这个参数，openssl 可能会用纯软件实现，结果偏差很大。
我刚开始做性能测试的时候，就踩过这个坑。跑出来的结果惨不忍睹，差点以为硬件坏了。后来发现是没开 -evp。所以，这条参数很重要，我建议你养成习惯。
4.1.2 输出解读
跑完后的输出，重点看 块大小对应的吞吐量。比如：
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-256-gcm 1.2M ops/s 1.1M ops/s 1.0M ops/s 0.9M ops/s 0.8M ops/s这里 ops/s 是每秒操作次数。数据块越小，次数越多。但如果你用 -bytes 参数，openssl 会直接输出兆字节/秒（MB/s）。我个人习惯看 MB/s，更直观一些。
那这个数字怎么用？举个例子：假设你的业务平均每次加密 4KB 数据，那你就在测试结果里找 4096 bytes 那行的吞吐量。如果只有 300 MB/s，而你的业务需要处理 500 MB/s 的流量——嗯，瓶颈就在这了。
核心指标： 对于对称加密，看 MB/s；对于非对称（RSA/ECC），看签名/验签的 ops/s。
4.1.3 多算法对比
我经常用这个场景来评估升级方案。比如，从 AES-128 升级到 AES-256，性能损失多少？一行命令就能看到。
openssl speed -evp aes-128-gcm aes-256-gcm输出会并列对比两个算法。我曾经在一次项目里，需要决定从 ChaCha20 换到 AES-GCM。我跑了一次对比测试，发现 Alder Lake CPU 上 AES-GCM 的吞吐量比 ChaCha20 高了 40%。那方案就定了。
| 算法 | 块大小 1024 bytes | 块大小 8192 bytes |
|---|---|---|
| aes-128-gcm | 2.3 GB/s | 2.1 GB/s |
| aes-256-gcm | 1.7 GB/s | 1.6 GB/s |
| chacha20-poly1305 | 1.2 GB/s | 1.1 GB/s |
你注意看，AES-256 比 AES-128 大概慢 25% 左右。这就是升级安全等级的成本。值不值得，你自己掂量。
4.2 cryptsetup benchmark：磁盘加密的真实验证
如果你做的是磁盘加密（比如 LUKS），光看 openssl 还不够。为什么？因为磁盘加密涉及 I/O 模式、设备驱动、队列深度等复杂因素。cryptsetup benchmark 能直接告诉你，在真实的磁盘加密场景下，你的硬件能扛多少吞吐。
4.2.1 跑一次全量测试
cryptsetup benchmark输出会列出多种 cipher 和 hash 模式。我截一段典型的输出给你看：
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 571.3 MB/s 585.6 MB/s
aes-cbc 256b 448.2 MB/s 461.1 MB/s
aes-xts 256b 518.5 MB/s 518.6 MB/s
aes-xts 512b 436.7 MB/s 435.2 MB/s这里 XTS 模式 是目前磁盘加密的主流。你看 AES-256-XTS 的加解密速度几乎一样，这是因为 XTS 模式下，加密和解密都走同一套 AES 硬件路径。这也是我推荐生产环境用 XTS 的原因之一——对称性好。
我的建议： LUKS2 配 AES-256-XTS 是当前平衡安全和性能的最佳选择。除非你跑在很老的 CPU 上，否则不要为了省一点性能去降级到 AES-128。
4.2.2 实战：对比硬件差异
我记得有一次，帮客户排查 KMS 性能问题。他用的云服务器，加密吞吐一直上不去。我现场跑了 cryptsetup benchmark，发现 AES-256-XTS 只有 120 MB/s。我又跑了一遍 openssl speed 测 AES-GCM，发现纯 CPU 能跑到 800 MB/s。这说明瓶颈不在 CPU，而在磁盘的 I/O 路径或者虚拟机环境。后来调了 VirtIO 队列深度，吞吐才上来。
所以，这两个工具要配合使用。openssl 看 CPU 极限，cryptsetup 看系统整体。
4.3 综合性能评估清单
好了，聊了这么多，我把整个测试流程总结成一张清单。你拿着这张清单去做性能测试，基本不会遗漏什么。
- 第一步：跑 openssl speed -evp aes-256-gcm —— 确定 CPU 的加密上限。
- 第二步：跑 cryptsetup benchmark —— 确认磁盘加密吞吐是否匹配 CPU 能力。
- 第三步：对比差距 —— 如果 cryptsetup 远低于 openssl，说明瓶颈在 I/O 栈，不是 CPU。
- 第四步：调整后复测 —— 每次优化（比如改队列深度、换 cipher 模式）后，重新跑第二、第三步。
注意： 不要在负载高的生产环境跑全量 benchmark。它会把 CPU 和磁盘都打满，可能导致生产业务中断。我建议在预发布环境或者专门的压测机上操作。
4.4 实战：我的一次性能排查经历
有一回，一个线上 KMS 服务突然变慢。排查流程是这样的：
- 我先用
openssl speed -evp aes-256-gcm测 CPU，发现还能跑到 1.2 GB/s，说明 CPU 没问题。 - 然后用
cryptsetup benchmark看磁盘加密，只有 200 MB/s。瓶颈在存储层。 - 我们的加密卷用的是 LUKS2 + AES-256-XTS。后来发现底层用的是 HDD，不是 SSD。换 SSD 之后，吞吐立刻到 600 MB/s。
你看，如果当时只迷信 openssl 的结果，我可能就一直在应用层找问题，根本找不到根因。
加密性能测试不是一次性的事。你每次升级硬件、更换操作系统、调整加密算法，都应该重新跑一遍这两个 benchmark。数据不会骗人。