在《「存储极客」三步完成全闪存选型》一文中，
我们介绍了如何测试存储系统的OLTP性能。
而具体到影响交易系统性能的决定因素——
CPU、内存还是IO子系统?
关于这一点在不同场景下的权重也不一样。
下面从最近的一份TPC-E BenchMark测试结果说起。
11,200 TPS是什么样的性能水平?
由于单个交易的复杂程度不同，TPS(每秒交易数)和TPM(每分钟交易数)
只有在相同测试模型下比较才有意义
如上表，这套被测系统在大负载Profile下表现出11,200 TPS(每秒交易数)的支持能力。
具体来说，就是测试了1-4个虚拟机，每个虚拟机400个用户负载，活跃数据集大约1TB。在4个VM时并发用户数达到1600，活跃数据集总共4TB。性能扩展方面的表现还是不错的。
那么这个TPC-E成绩究竟如何呢?我去TPC官方网站查询了一下发布的结果。
http://www.tpc.org/tpce/results/tpce_perf_results.asp，2017年2月23日
我看到在这里公布的TPC-E测试结果中，排名第一的tpsE(也是指TPC-E的每秒交易数)为11,059。前两名TPS超过一万的都使用了八路(8 CPU插槽)服务器，操作系统、数据库为Windows+SQL Server，提交时间2015年底。
第一点小发现是，TPC-E成绩并不是与CPU核心数量/总计算能力成线性关系。因为就在这个榜单中，四路服务器也能跑出超过9000的TPS。
注：本文以讨论技术为目的，并不关注具体的服务器品牌型号，只看配置和测试表现。
TPC-E测试负载模型要点
引用自《TPC-E Benchmark Overview》
by TPC-PR Subcommittee，2007年2月
上表对比了TPC-E和TPC-C测试的主要区别，我们看到在数据库表、列的数量，数据类型丰富程度，主键/外键等方面都是TPC-E更加复杂，因此它们的测试成绩不能交叉对比。同样的道理，用SwingBench等测试工具配置一个简单交易模型，也很容易跑到更高的TPS值。
这里列出了测试可接受的场景/范围。AQRT(平均查询响应时间)需要低于25ms，这个延时与存储的IO延时不是一回事，因为一次查询操作中可能会包含数量不等的IO，还受应用(数据库)缓存命中率的影响。
关于CPU利用率80%-85%，如果超过这个值意味着CPU可能成为瓶颈，要是较低则表明压力不够，系统计算能力尚有裕量。
同样是“堆”SSD，DAS和全闪存阵列哪个效果好?
由于报告提交时间的原因，这两套TCP-E测试系统的OS、数据库版本，以及CPU都不是最新一代，但Xeon E7-8890 v3的144个核心和4TB内存还是比较豪华了。而更加“变态”的是，上表中的八路服务器使用8块RAID卡加12个JBOD扩展柜，一共连接了104个SAS SSD(包括6组17个SSD的RAID 5)。
尽管在《存储极客：SSD RAID能跑多快?要安全就没性能?》一文中，我们谈到过RAID卡对SSD性能发挥(主要是写性能)的影响，不过上述平台的整体IOPS、带宽还是可以秒杀许多PCIe闪存配置了。
另外一款八路服务器在TPC-E测试中更进一步，配置了15块SAS RAID卡、15个JBOD机箱里面一共210个400GB SSD。我们肯定I/O性能对TPS的影响，但在达到一定程度之后，存储子系统也许就不再是瓶颈了。
本文开头提到的11,200 TPS测试成绩并没有提交到TPC官网，有些测试配置可能存在不同，因此这个对比也只是给大家一个参考。其中有一点差别就是上面2款八路服务器都是在物理机Windows系统中测试的，而下面要介绍的平台使用了虚拟机(Hyper-V)。
引用自《TPC-E testing of Microsoft SQL Server 2016 on Dell PowerEdge R830 Server and Dell SC9000 Storage》
如上图，这套平台的数据库服务器为Dell PowerEdge R830，后端连接SC9000存储阵列，存储网络由2个Brocade 6505 FC交换机构成。万兆以太网交换机型号为Dell S4048-ON，没有看到关于客户端服务器的描述。
具体的服务器配置，是Xeon E5-4600四路平台中的顶配CPU——22核的4669 v4，基础频率2.2GHz，虽然单个CPU性能比Xeon E7 v3强，但四颗的核心总数为88个。满配1.5TB内存也无法与八路平台测试使用的4TB相比。
服务器上操作系统和数据库也使用了微软Windows+SQL Server平台;SC9000存储阵列为全闪存配置，双控制器+2个SC420驱动器机箱，18个写密集型SSD加12个读密集型SSD的分层部署。
服务器2U、存储8U，加上所有交换机也才14U的高度，比前面提到十几个JBOD占满整个机柜在空间上要节省不少，耗电也是一样。
通常意义上，如果只是单纯实现单台服务器的存储性能最大化，不通过存储网络直连SSD是最好的办法。除了无法与其它服务器共享之外，还有故障点增加的问题，虽然驱动器配置了RAID，但任何一块RAID卡或者JBOD故障都会导致部分数据无法访问。在如此规模的DAS环境添加服务器实现共享存储的高可用也不太现实。
相比之下，外部存储阵列中的30个SSD在这里并没有表现出性能不足。我觉得首先是一部分数据请求在应用(数据库)缓存命中了;其次贴近实际应用的TPC测试中每个交易所包含的操作，一部分瓶颈并不在存储(SSD/磁盘)上。在这种情况下，全闪存阵列显得更加均衡——还具备高可用性，从服务器上的HBA卡到光纤交换机，再到控制器都是双份冗余的。如果想进一步规避服务器的单点故障，增加节点配置共享存储的高可用集群也都是成熟方案。
如果应用确实需要极致的存储IOPS或者带宽性能，不太在乎成本，同时想兼顾高可用以及在服务器之间的共享连接能力，其实还有一种选择——EMC DSSD RACK-SCALE 闪存系统。号称超过100GB/s带宽和超过1000万IOPS(实测读写混合129GB/s带宽和1600万IOPS，同时具备双控制器和冗余的PCIe主机连接，只要5U机架空间。
引用自《Modernize your SAS analytics infrastructure
to get smart, timely decisions at scale》，
A Principled Technologies report，2016年9月
SAS属于大数据分析(BI)类应用，上图只是想侧面证明一下DSSD的性能潜力，一台服务器很难把它用满，即使四路、八路服务器也是如此。
更多测试规模、性能平衡点分析
在Dell的这份性能报告中，还有另外两种数据集大小的测试结果，对应虚拟机分配的vCPU和内存资源也不相同。
引用自《TPC-E testing of Microsoft SQL
Server 2016 on Dell PowerEdge R830
Server and Dell SC9000 Storage》
“中等工作负载”测试了1-8个虚拟机(500GB)的压力，每虚拟机300总共2400个并发用户，测试结果为10,967 TPS，比4个“大虚拟机”略低。
引用自《TPC-E testing of Microsoft SQL
Server 2016 on Dell PowerEdge R830
Server and Dell SC9000 Storage》
“小型工作负载”测试了1-8个虚拟机(250GB)的压力，每虚拟机90总共720个并发用户，测试结果为10,300 TPS。
引用自《TPC-E testing of Microsoft SQL
Server 2016 on Dell PowerEdge R830 Server
and Dell SC9000 Storage》
最后看下CPU占用率，三种数据集大小基本都达到80-85%的正常范围。
既然总计算能力(多核)、存储性能都不是决定TPC-E成绩的唯一因素，结合不同虚拟机规模/数量的测试结果，我倾向于认为NUMA优化——CPU访问内存的效率应该也是一个需要优化设计的点。
Dell PowerEdge R830的多处理器互连方式
也属于NUMA(非一致性内存访问)架构
参考我们之前在《几轮PK帮你优选“真四路”!》中所讲的，尽管Xeon E5-4600四路平台在CPU QPI互连方面的能力不如Xeon E7，但如果4个虚拟机恰好跑在每个CPU插槽及其本地内存的话，反而能达到最好的效率(Xeon E5不像E7那样通过SMI缓冲芯片连接内存，延时较低)。
相比之下，八路及以上平台确实可以支持更大的内存和数量更多的PCIe扩展卡，但需要合适的应用(比如SAP HANA)才能发挥出与其价格相匹配的价值。
