如何获得TPC-C测试第1名？

首先需要找到官方唯一认证的审计员来对测试进行审计监察，他们对这次OceanBase的审计也相当重视，全世界仅有的三个审计员这次就有两个参与到测试审计工作中。

测试系统

目前市面上基本找不到一个能够开箱即用的符合TPC-C标准的测试工具。以目前各个厂商PoC环境最常遇到的benchmarksql为例，可以说只是模拟TPC-C压力模型的压测工具，连最基本的数据导入都不合规，大量的字符串生成未保证全局随机，缺乏压测阶段最基本的think time、keying time这些基本配置导致极小的数据量就能跑出很高的tpmC，最关键的是它将测试模型大大简化为工具直连DB测试，完全没有遵守TPC-C测试标准规范。

在标准定义中，测试系统可以分为RTE(Remote Terminal Emulator)和SUT两部分，但实际上从角色上看SUT可以进一步拆分为两部分：WAS(web application server)和DB Server。

这其中DB Server是每个测试厂商的数据库服务;RTE扮演的角色是测试模型中的客户终端，事务的触发、RT的统计等都在这里完成;标准明确要求每一个用户terminal都必须保持一个长连接，显然在海量Warehouse时DB是无法承受这么多连接的，WAS就是RTE和DB之间桥梁，标准定义可以使用连接池，在保证对应用透明的情况下它可以做所有请求的管理。

这三个角色中，WAS和DB是必须商业化可购买且提供支付服务的，OceanBase这次是使用了OpenResty作为WAS供应商。而RTE则一般由各个参测厂商自行根据标准实现，但所有实现代码必须经过审计的严格审计，OceanBase这次完整的实现了一整套完全合规的RTE，并且支持在大规模测试系统中部署。要知道在实际的TPC-C测试流程中，不只是对DB端能力的考验，RTE端同样存在极大的资源消耗和压力。以这次6088w tpmC测试结果看，我们一共在64台64c128G的云服务器上运行了960个RTE客户端，来模拟总计47942400个用户terminal，最后还需要基于这么多RTE统计结果进行一致性和持久化审计验证。

虽然只是测试客户端，但RTE的中同样有大量的可能导致最后测试失败的小细节，比如大家可能注意不到的所有事务都因为用了web端模拟终端后需要增加的100毫秒rt，又比如为了模拟用户终端输出显示的100毫秒延时。

测试规划

TPC-C从来都不是一个简单的测试，它很科学并没有给出强制的软硬件配置，只是给出测试规范和各种审计检查限制标准，所有数据库厂商可以根据自己的特性充分调优来拿到一个最好的性能或性价比。但这同时也对所有参测厂商提出了一个巨大的难题，如何对已有的资源进行合理规划来保证顺利完成一次对TPC-C榜单的冲

（编辑：怀化站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!