![1e84e283f9b0d4b36dc8085cfac4b604.png](https://i-blog.csdnimg.cn/blog_migrate/f686ae747d53d489c27405c772db1fab.jpeg)
TPC-H测试标准,以8张表,22个查询作为基础,在一定时间内(通常是1小时),通过7个并发查询,衡量数据库的每秒处理事务数,作为数据库性能度量标准。用一个公式来描述整个过程,就是 QphH@Size.
2018 年,惠普使用 microsoft sql server on linux 作为测试对象,向 TPC 组织, 提交了一次TPC-H性能报告。
在1T的数据量下,花费近47万美金,达到了每小时100万的查询数,即每秒可完成280查询。公式表达,1009065.5 QphH@1000GB.
当然,这还没考虑到查询性能的可接受程度,以27.6s这样的平均速,其实很多用户是会不满意的。
![b47594c76e75c99cee8f8e8bb17059cc.png](https://i-blog.csdnimg.cn/blog_migrate/35437e93948141866672c291a46baf19.png)
这份报告虽然说明一定的问题,比如 Throughput 度量,性价比,但缺少对服务器的性能监控。比如7个并发,1小时连续压测下,服务器的性能监控图。
再者,数据库的最终吞吐量,是否可以再扩大,也没有具体说明白。如果降低并发,是不是能够获得较好的性能?
为了模拟惠普的这次测试,我通读了TPC-H的测试标准,惠普的这份测试报告,还有几篇来自维普的论文。最终找到了模拟的方法。
以下是详细的测试步骤:
1)下载 HammerDB 软件
2)准备 SQL Server 测试环境
3)复现 Power Test
4) 复现 Throughput Test
1) 下载 HammerDB
公众号后台回复 HammerDB,即可得到 zip 版本的 HammerDB 连接。
解压缩后,直接打开,就可以使用
![e8d2d869855ed6bfc83cd0df766575e1.png](https://i-blog.csdnimg.cn/blog_migrate/268c8da228755f5c79c30f2ba9fb6b1e.jpeg)
2)准备 SQL Server 测试环境
这就要自己准备了,到微软的官方网站下载180天的试用版,即可
3)复现 Power Test
由于这次模拟的是 SQL Server TPC-H 测试标准,所以在 HammerDB 中,我们需要预先配置:
第一次打开 HammerDB 是这样的,以 Oracle TPC-C 为默认选中状态:
![28213b662f606ff73b60d7b1e1e12c05.png](https://i-blog.csdnimg.cn/blog_migrate/30deceb31c31d8566434e1f48241d54b.jpeg)
通过菜单 Options, 配置 SQL Server TPC-H 测试标准:
![ced2ce212cc3d8168dbe04271f41cb76.png](https://i-blog.csdnimg.cn/blog_migrate/200807f5956c0499f61a41f17c77ec26.jpeg)
![4005417ebc03cc05a87be2fde1b033cb.png](https://i-blog.csdnimg.cn/blog_migrate/19b703dfc1bf8d6975f128cf27085a28.jpeg)
在 TPC-H 整套测试方案中,指定了8张表,22个查询,配备相应的数据生成程序与查询生成程序,但这两个程序都是使用c/c++写的,必须先通过编译,再通过调用接口来用在自己的测试方案中,我尝试了下,放弃!不仅源码复杂,有些环境还需要额外配置。
在搜索了 n 篇论文以及博文之后,我发现 HammerDB 已经替我们把这些环境配置都搞定了,于是就它了。
有了 HammerDB,我们唯一要做的事情,就是指定一个可用的测试数据库就可以。
![0e410c3725e650b1ab89083cadede472.png](https://i-blog.csdnimg.cn/blog_migrate/6c756846d8092857bed73ac6dcd67762.jpeg)
这里需要说明的是 Scale Factor,也就是扩展因子。说人话,就是数据库大小配置。总共可以分为6级,1GB,10GB,30GB,100GB,300GB,1000GB.
那么既然是自己测试,选择1,即1GB,就可以了
![473b9600a6ed704b1ce946d966174fec.png](https://i-blog.csdnimg.cn/blog_migrate/07d8930348b68e44e6669d58490406c2.jpeg)
点一下 Build,就完成了数据库环境配置。
通过 SQL Server Profiler, 我们可以看到数据库正在发生的一切:
![c1eda0349feac873f6ed025447a4d69e.png](https://i-blog.csdnimg.cn/blog_migrate/fbb981502900f4c175c68b4b997d04d3.jpeg)
通过 HammerDB 的Build界面,可以看到执行状态:
![ebc0cace22668582bb49cf390dc0c2f3.png](https://i-blog.csdnimg.cn/blog_migrate/88e7693942775a0aa76763d73d29b0ce.jpeg)
当然,时间会很久,我们可以去喝一杯咖啡再来,HammerDB会自动报告,数据装载是否完成:
![9acedf4e4aebcd309eb028319719676b.png](https://i-blog.csdnimg.cn/blog_migrate/98649dd57639326a8700c1aade4c3907.jpeg)
由于装载时间非常长,所以一旦数据库建立成功,我们就要对它进行备份:
![e94ae2aecdc50ea5457804a62e845da6.png](https://i-blog.csdnimg.cn/blog_migrate/b3462cc9a910665136e76681024c3005.jpeg)
接下来,我们就要试着运行一次 Power Test:
首先配置 Driver Script:
![d1fd92dc52bd47037871d9b9993d120e.png](https://i-blog.csdnimg.cn/blog_migrate/79618cb52e4458e686e4a28d7ca07dea.jpeg)
Driver Script 做的事情,就是为测试中的虚拟用户,配置执行的操作。比如配置一组22个查询组成的查询流,让虚拟用户在登录数据库,依次执行这22个查询。
配置完 Driver Script, 我们就可以生成指定数量的并发用户。这些用户,可以执行刚才配置的 Driver Script.
Power Test 测试目的,是察看是否有明显的响应时间缺陷,所以设置单个用户:
![b253f4ee184d5efc7774656b68884bed.png](https://i-blog.csdnimg.cn/blog_migrate/bd9a2e23918b117c31d6750549e59632.png)
一旦配置完成,就可以双击 Create 来生成虚拟用户的配置信息:
![ffdd4ea22b5f02123ad53f64e10a68a7.png](https://i-blog.csdnimg.cn/blog_migrate/e6c8a4281186625f2e1350a7b228ceb5.jpeg)
接着,我们点击运行单用户的单次执行:
![d68eb735d74255572f2927ba1d05300c.png](https://i-blog.csdnimg.cn/blog_migrate/3240c2fa35ec2b658b45b2ca1e5e7955.jpeg)
耐心等待测试完成:
![679be4eae369ab988f07973fd2eaacf5.png](https://i-blog.csdnimg.cn/blog_migrate/07dd9987713da176ed7f8fbf1d86386f.jpeg)
单轮测试用了124秒,似乎不够理想。但这是我可怜的笔记本虚拟机服务器啊。
然后,肯定会有读者说,这是数据仓库啊,不能没有写入的操作啊。是的,这个写入,我们也可以模拟,通过开启 Refresh Function:
![c1b9716863958e5ccbd43d921fb69aba.png](https://i-blog.csdnimg.cn/blog_migrate/f475d384473983db8778db638cba2fba.jpeg)
然后再重复新建用户,并开启测试。
4)复现 Throughput Testing
Throughput 是吞吐量的意思,这个概念很有意思。
首先来说说并发用户。当同时有10个用户访问数据库时,假设他们同时执行1条 SELECT 语句。此时,并发数是10,Throughput 也是10,但你能不能说数据库并发度不够呢?不能。因为此时这并发的10个用户,都对速度感到满意,说明完全可以再容纳更多的人来数据库查询。
于是,增加了100个人来,还是运行 一条SELECT语句。那么此时,如果大家还是对响应很满意,说明数据库非常棒,还可以吸纳更多的人。
好,加20倍流量,来了200人。于是,有用户反映,速度慢了,明显慢了一倍以上,当有50%的人都说慢了的时候,显然数据库的吞吐量,要小于 200.
我们往下调调,来150人吧。此时90%以上的人,对速度满意,那么就可以说,数据库的吞吐量在 150左右了。
这,就是 TPC-H 测试标准报告中,要体现的内容了。不过,人家更标准,使用的是 QphH@Size.
所以,我们要使用 hammerDB来模拟这个操作:
首先设置4个并发用户,第一个用户会模拟写入的操作:
![97ce75c17da9d3df866937962d5ded8c.png](https://i-blog.csdnimg.cn/blog_migrate/99c3786530c91e163b26c5c0e4d6ee71.png)
开启 QphH@Size 的统计功能:
![860837d2fe3817b43537d6e7b2549eed.png](https://i-blog.csdnimg.cn/blog_migrate/15a8af5d9d2065bf2d0804cc92104456.png)
等待测试完成
![b2c2aab2a7249e9578f767864360696f.png](https://i-blog.csdnimg.cn/blog_migrate/0195c10caba88d09ae0de36276a80e07.jpeg)
理论上,测试时间越长,测试的准确度越高,但我们只是模拟,所以运行一组 Query Set, 让 HammerDB 帮我们预估就可以了:
![2eb3ad486127ee0bb3afcdf76adc29d7.png](https://i-blog.csdnimg.cn/blog_migrate/9b3491d5ee948a4fb6262c724c051b19.png)
![2a9d32e572c41e1401df58d57614b9e6.png](https://i-blog.csdnimg.cn/blog_migrate/6972b12f01442a84d8dde2be92121a6b.png)
![0bd4a91bc1c3265abfcc9685189b7fd3.png](https://i-blog.csdnimg.cn/blog_migrate/8759322ab88efcd0d0159ab5f800da7b.png)
![56ce648ef90067674ad8d4f857410717.png](https://i-blog.csdnimg.cn/blog_migrate/8ba81d8422d74de434bd298097a3321d.png)
可以看到,4个并发测试下来,大概可以得到每小时近20000个事务处理。也就是每秒钟处理6个事务。
那么是不是 Throughput 为6,就是我的数据库极限了呢,我怀疑,可以更高。于是我调高了用户并发数,加了2个,再来看 QphH:
![091e8410376118030311434831bf88e6.png](https://i-blog.csdnimg.cn/blog_migrate/2922449fef400cd36024e0aabb8126f1.png)
![e41db82c42302a5a13fe1b9dd36c6c92.png](https://i-blog.csdnimg.cn/blog_migrate/9210efff37a5833e5362cfd9c31ec10f.jpeg)
发现,最高的 QphH 虽然比4个用户那次高,但明显已经影响了用户的响应时间,普遍从原来的100s 延长到了160s 以上。说明,已经不能再增加并发查询了,6事务/秒已经是我这台数据库的极限。
很可惜的是,HammerDB 并不能动态增加用户数,导致测试不流畅,不得不说是个遗憾。我看到 oracle 厂商在 demo 他们的系统时,并发用户数,是动态可加的,想加就加,相减就减,操作随意地令人发指。提高了测试的准确度。
说Oracle是世界,乃至宇宙第一,还不得不服。