在开始任何严肃的中间件性能评测之前，我们必须先回答一个根本问题：“我们跑测试的这几台机器，本身性能到底怎么样？”

如果连测试环境的性能基准都搞不清楚，那后面所有的 TPS、RT 数据都无异于空中楼阁，缺乏可信度。所以，我们这个系列的第一篇，就是一次彻底的“硬件摸底”，把我们测试环境的磁盘、数据库和网络性能扒个底朝天。

这篇是纯粹的“开胃菜”，但对于理解后续文章中的性能数据至关重要。

1. 磁盘 I/O 性能：fio 压测下的“真面目”

对于 RocketMQ、MySQL 这类 I/O 密集型应用，磁盘性能就是它们的生命线。我们用业界标准的 fio 工具，对四台典型的云服务器进行了残酷的压测，数据非常说明问题。

测试场景：使用 fio，对 30G 大文件进行 16k 数据块的同步 I/O 读写，模拟数据库和消息队列的典型操作。

核心压测数据：

机器 IP 规格 顺序读 顺序写 随机读 随机写
172.16.15.238 16核/64G 673 MB/s 174 MB/s 12.1 MB/s 13.8 MB/s
172.16.15.127 16核/16G 955 MB/s 238 MB/s 38.6 MB/s 19.9 MB/s
172.16.1.11 8核/16G 1201 MB/s 456 MB/s 50.8 MB/s 14.0 MB/s
172.16.1.77 32核/32G 1099.4 MB/s 254.3 MB/s 33.5 MB/s 16.0 MB/s

我们学到了什么？

  1. 别迷信 CPU 核数：最令人惊讶的是，8核 的 172.16.1.11 在顺序读写和随机读性能上，竟然全面碾压了 32核 的 172.16.1.77。这说明决定 I/O 性能的，是磁盘类型和宿主机的 I/O 总线，而不是 CPU 核心数量。
  2. 随机读是性能的“阿喀琉斯之踵”：所有机器的随机读性能都惨不忍睹，最差的只有顺序读的 1/55 (12.1 / 673)。这直观地解释了为什么 RocketMQ 和 MySQL 这类软件要拼了命地利用 mmap、Page Cache 或 Buffer Pool 来将随机读转换为顺序读或内存读。一旦缓存被击穿，触发大量落盘随机读，系统性能就会瞬间崩盘。

2. 数据库性能基准：MySQL 摸高数据

为了建立数据库性能的“背景板”，我们对 MySQL 做了一次简单的摸高测试（系统配置：CPU 4核 / 内存 16G / 磁盘 300G）。数据如下：

测试场景 内存配置 TPS QPS
消息大小为 xbytes 、12个并发连接请求 8G 946 18,927
消息大小为 xbytes 、24个并发连接请求 8G 1,201 24,037
消息大小为 xbytes 、48个并发连接请求 8G 1,286 25,721
消息大小为 xbytes 、64个并发连接请求 8G 1,338 26,773
消息大小为 xbytes 、96个并发连接请求 8G 1,160 23,210
测试场景 内存配置 TPS QPS
只写，64个并发连接请求 8G 5,266 31,600
只读，64个并发连接请求 8G 1,934 30,943
只查，64个并发连接请求 8G — 57,439
只删除，64个并发连接请求 8G 11,011 11,011
只插入，64个并发连接请求 8G 11,841 11,841
只更新，64个并发连接请求 8G 11,160 11,160

3. 网络吞吐能力：VPN 带宽测试

最后，我们看下网络。根据我们的内部网络压测数据，在云环境下的 VPN 下行带宽极限可以达到 250 Mbps 左右。这个数据本身不代表好坏，但它为我们后续分析 Redis、RocketMQ 等网络密集型应用的吞吐量上限，提供了一个重要的网络环境背景板。

本篇小结

这次硬件摸底，让我们对测试环境的“天花板”有了清晰的认识：

  • 磁盘是瓶颈：I/O 性能，特别是随机读性能，是限制大多数数据密集型应用的关键。
  • 硬件决定论：软件层面的优化固然重要，但永远无法突破底层硬件的物理极限。

有了这些坚实的基准数据，我们现在可以充满信心地进入下一篇：消息队列 RocketMQ 的生死对决。届时，我们将看到在这些真实的硬件环境下，自建与云服务的 RocketMQ，会碰撞出怎样激烈的火花。