聊聊Benchmark测试的一些小技巧

前两天谈到数据库选型的时候也提到了Benchmark测试,这些年作为考生参加过不少Benchmark测试,也作为主考官主持过不少Benchmark测试,对这个测试是感慨颇多。今天我们主要来聊聊作为数据库选型时的Benchmark测试,实际上Benchmark测试是考官和考生之间的一种技术博弈。如果考官的水平远远低于考生,那么被考生玩死也是十分常见的。我参与过一个运营商的类似测试,拿到测试及格线的时候我当时吃了一惊,作为一个有点常识的人,我认为这些所谓的及格指标是目前的技术条件所达不到的。自己在实验室搭了个环境测试了一下,30%都达不到。于是我就请教了一些参与过这个客户测试的朋友,他说,Benchmark测试工具允许用自己的,只要结果数据满足条件就合格,同时客户会采集操作系统中的IO负载,CPU使用率等数据,如果低于正常水平就认为有问题,否则就认可工具输出的结果,你们都是做过系统优化的人,知道该如何去做。这是一个漏洞百出的测试方案,里面有太多的空子可钻了。于是简单的修改了一下Benchmark的源代码,把所有指标都放大数倍,并且在工具里产生一个能够产生大IO和CPU使用的SQL语句,让OS上看到的负载达标,很容易就能达到测试目标。最后的结果不言而喻,我们主要的竞争对手全部达标。
如果Benchmark测试做成我所遇见过的样子,那么就是走一个过场了,做这项测试的业主肯定不愿意面对如此的结果。因此今天,作为考生和考官双重身份的参与者,我和大家分享几个Benchmark测试的技巧。
首先要采用较为公正的测试工具,因为数据库选型涉及的是多种不同的数据库,而Benchmark工具原生态支持的数据库产品并不多,因此要想对大家都比较公正,一定要选择一款认可度比较高的测试工具。现在来看,Benchmark 5.0是被最为广泛接受的工具。通过驱动支持方面的简单修改,可以支持目前几乎所有的国产数据库。不过工具一定要统一由测试方提供,适配改造工作也一定要由测试方自己做。可能工具中存在某些BUG,会影响某个数据库的测试结果,那么数据库厂家可以提出,经过确认可修改后,统一由测试方进行修改。测试的参数文件一般选用测试方提供的公共参数文件,根据并发量不同,形成多个测试用例,取其平均值作为最终结果。厂家如果提出有自己的最优参数,则可以提供独立的参数文件,形成的测试结果作为另外一个测试结果项,单独授予分值。如果某个厂家并未提出最优方案,则从几个测试结果中选取最佳值来作为这个测试用例的结果。
其次是数据库参数设置方面要做一定的限制,很多数据库厂商提供的测试参数是实际上在生产环境中不可能使用的,比如采用异步提交,关闭CHECKPOINT,关闭集群状态检查、使用CPU绑定、开启结果缓冲等,这些配置在实际生产环境中如果永远不会使用,那么就一定要在选型测试的时候禁止掉。否则测试出来的结果会虚高,而且和你今后的应用场景完全无关。另外一旦参数设置完毕,那么在今后的所有测试中,都不能再调整参数。
第三是严禁把WAL/REDO等PERMENT的文件放到内存盘中。Linux上可以把一部分内存设置为内存文件系统。因此有些厂商就会打这个主意。Benchmark测试如果能够提高WAL的写入性能,测试结果提升还是很大的。记得大概是8年前的一个测试,我发现有一个厂商的测试结果鹤立鸡群,当时就怀疑他们用了内存盘。但是那个厂家和业主关系十分好,在没有证据的时候又不好拉下脸去检查。于是我把一个小伙子叫过来,让他过去装着不小心把服务器的电源踢掉。恢复供电后,那个数据库果然就起不起来了。有时候Benchmark测试就是这种猫和老鼠的斗争。
第四是数据的问题。首先Benchmark的表结构允许不允许修改的问题,因为不同数据库对于高并发下的并发控制、热块冲突的解决方法不同,因此在相同的测试场景下会表现出一些差异。如果厂家能够通过表和索引参数,分区等方式来缓解问题,那么是应该允许使用的。我们的建议是允许用户修改建表的数据字典,但是必须是合法的。其脚本的修改必须提交给测试方,最终的建表工作也应该由测试组统一完成。数据字典一旦创建好,在整个测试过程中不能做任何DDL操作。如果有多轮测试,那么在每轮测试结束后,都应该重新初始化数据,否则Benchmark比较高的厂商会在后面的几轮中吃亏。
第五是对资源使用率的限制问题。很多Benchmark测试会把CPU使用率等作为评分依据,测试过程中CPU使用率越低给的分数越高,或者限制CPU使用率不能超过90%,否则扣分。实际上这是没有必要的,Benchmark测试作为极限测试的目的就是为了考察某个数据库能否充分的把系统的资源全部利用好,因此不应该对资源使用情况进行评分。
第六是测试结果的评定。TPMC指标当然是评定中最为主要的结果。不过除了关注TPMC之外,我们还应该关注事务的响应时间。这是因为TPMC只是反映了极限状态的吞吐量,而响应时间反映了单一交易的延时。如果我们的应用系统对于大并发交易的延时十分关注的话,我们还可以加一个评分点,那就是90分位的事务响应延时,这个延时反映出绝大多数用户获得的交易反馈。如果我们需要更严格的相应延时,那么也可以考虑95分位延时指标。
不管如何,Benchmark测试也只是一种简单交易的测试而已,在数据库选型中只能作为一个参考项,而不应该作为数据库选型的全部内容。在技术架构迥异的数据库中做比较公正和科学的分析实际上也是一个十分难的难题。就像我们的高考一样,肯定不可能完全的公正,但是还算是一种相对公平的考核吧,Benchmark测试也是如此。

聊聊Benchmark测试的一些小技巧》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/154.html