每秒11,200 TPC-E？四路服务器！

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测试负载模型要点

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）。

如上图，这套平台的数据库服务器为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）才能发挥出与其价格相匹配的价值。