当前位置： >
解析大数据基准测试：TPC-H or TPC-DS 17:23:51&|&编辑：hely&|&查看：&|&评论：
本文中，主要讲解了大数据测试基准应该具有的要素，并以此为基础对比了现有的大数据测试基准，然后重点讨论TPC-DS测试基准。
基于业内对大数据技术的需求，各种基于开源技术的商业产品得到了长足的发展。然而对于用户来说，如何才能客观地比较不同的数据管理系统，基准测试的研究也被提了出来。本文中，主要讲解了大数据测试基准应该具有的要素，并以此为基础对比了现有的大数据测试基准，然后重点讨论TPC-DS测试基准。
以下为原文
随着开源Hapdoop、Map/Reduce、Spark、HDFS、HBASE等技术的商用化，大数据管理技术得到了突飞猛进的发展。一般来说，大数据具有3V特性，即Volume(海量)、Velocity(高速)和Variety(多样)[1]。TPC联合主席、Cisco高级工程师Raghunath Nambiar进一步认为大数据还面临Value(价值)和Veracity(精确)的挑战。如何客观地比较不同数据管理系统，即大数据测试基准的选择，成为一个重要的研究课题。
事务性能管理委员会(TPC)是目前最知名的数据管理系统评测基准标准化组织。在过去二十多年间，该机构发布了多款数据库评测基准，如TPC-A、TPC-D、TPC-H和TPC-DS，在业界得到了广泛应用[2]。BigBench和BigFrame是对TPC-DS进行多样化的数据扩充的测试基准。近年来，Apache开源社区针对Map/reduce架构开发了多款性能测试用例，如TestDFSIO、teraSort。国内对大数据测试基准的研究起步较晚，尚未建立起权威的测试基准。目前由中国信息通信研究院牵头，联合中科院计算所及国内外知名公司和机构共同制定的大数据测试基准正在金罗密布的测试中[3]。
为了方便企业选择合适的大数据测试基准，本文将在分析总结现有成果的基础，进一步讨论大数据测试基准应该具有的要素;并以此为基础，对比现有的大数据测试基准;然后重点讨论TPC-DS测试基准。
大数据测试基准的选择
企业在选择大数据测试基准时，首先应考虑基准与其自身业务的相关性。
1. 与其自身业务的相关性
它主要描述测试基准设定的应用场景是否与企业的实际业务场景类似，如基于社交网络应用的评测基准与银行系统的应用场景就没有什么相关性。不相关的基准，测试结果再好，也没有实际意义。相关性还要考虑测试基准所采用的数据模型是否代表数据仓库的发展方向，如基于星型模型的开发要比基于传统的关系模型开发更加有效。
当然，一套行之有效的大数据测试基准包含许多其它要素。Jim Gray及金澈清等学者[4]已经对度量选取、模拟数据生成器、工作负载设定、审计等要素进行了详细论述。除此之外，本文还认为测试基准的健壮性、SQL标准的兼容性和通用性/可移植性也是重要的要素。
2. 模拟数据生成要具有真实性
它描述了测试基准是否仿真真实应用场景，所产生的模拟数据是否与真实数据相似。
3. 工作负载的设定具有可扩展性
它描述该评测基准是否适用于不同规模的计算机系统，许多评测基准会使用标度因子来决定模拟数据的规模，通过调整标度因子来得到不同规模的工作负载。
4. 度量的选取的可理解性
它衡量该评测基准是否易于为用户理解，不易为用户理解的基准的可信程度也较低。
5. 客观性与公正性
众所周知，在竞技比赛中，一个人不能既是运动员又是裁判员。测试基准好比竞技比赛中的裁判员，应该由中立的第三方机构制定。事实也证明，在各个领域最受欢迎的测试基准都是有第三方机构设计的。过去20多年的经历证明TPC系列基准是数据库领域最为广泛接受的基准。除此之外，第三方机构的审计也是保证证评测结果的客观性与公正性的重要手段。
测试基准要足够健壮，不能轻易被&hack&，这对测试结果的公平性非常重要。例如对TPC-H的前身TPC-D，通过物理化视图，Oracle的性能比Micosoft的SQLServer高100倍，这些显然是不公平的。因此TPC组织规定TPC-H测试中物理化视图是不和法的。但是除非是专业人员，一般用户很难判定测试过程中视图有没有被物理化。TPC-DS在健壮行方面要好很多，因为它的SQL本身比较复杂，也比较多，Hack起来相对困难，并且只hack几个SQL对整体性能提高有限。
7. SQL标准兼容性
SQL是ANSI为统一各个数据库厂商之间的编程差异定义的标准，已发布SQL86、SQL92、SQL99、SQL2003等版本。这些标准已经被主流的商用(例如Oracle、DB2、SQL server)以及开源的数据库产品(例如MySQL、mSQL和PostgreSQL)的广泛采用。对整个数据库产业的发展起到了巨大的推动作用。大数据是个新兴的领域，它的发展不能完全抛弃原有的应用。如果不能全面支持SQL标准，现有系统的移植非常困难，学习曲线就会变长。
8. 通用性/可迁移性
通用性描述是否可在不同数据库系统和架构上实现指定的评测基准。测试基准不应该规定实现的细节，而只需要定义测试规范。DBMS只要遵循规范得到正确的结果，就是合理的测试，无论其基于Map/Reduce、Spark还是其他的技术，也不管其底层存储是用HDFS、HBASE还是其他方式。
搜索"raincent"或扫描下面的二维码1000人阅读
mysql-测试（12）
老叶倡议：MySQL压力测试基准值&
存储，学习，共享。。。。。
通常，我们会出于以下几个目的对MySQL进行压力测试：
1、确认新的MySQL版本性能相比之前差异多大，比如从5.6变成5.7，或者从官方版本改成Percona分支版本；
2、确认新的服务器性能是否更高，能高多少，比如CPU升级了、阵列卡cache加大了、从机械盘换成SSD盘了；
3、确认一些新的参数调整后，对性能影响多少，比如 innodb_flush_log_at_trx_commit、sync_binlog 等参数；
4、确认即将上线的新业务对MySQL负载影响多少，是否能承载得住，是否需要对服务器进行扩容或升级配置；
针对上面这几种压测的目的，相应的测试方法也有所不同。
先说第四种，需要和线上业务结合起来，这时候就需要自行开发测试工具，或者利用
tcpcopy 将线上实际用户请求导向测试环境，进行仿真模拟测试。
对于前三种，我们通常采用基准测试就可以。比较常用的MySQL基准压力测试工具有
tpcc-mysql、sysbench、mysqlslap
关于压力测试工具的使用，可以查看我之前在ORACLE技术嘉年华上的分享：MySQL压力测试经验，在这里不再细说。
基于促进同行间的交流，统一MySQL压测标准，并且可以相互分享、对比、借鉴测试结果的目的。因此老叶特别发起MySQL压力测试基准值倡议。建议大家采用以下几种压力测试基准值。
倡议：MySQL压力测试建议基准&#2试行版）
也可以访问老叶网站（）查看本文附件excel文档：压力测试基准建议及数据采集模板，里面已附带了压力测试相关的数据采集点建议，压测结果整理及自动生成对比图表。欢迎各位同行拍砖提出不同的见解和补充意见，先谢过大家。
关于压力测试的其他几个方面：
1、如何避免压测时受到缓存的影响
【老叶建议】有2点建议
a、填充测试数据比物理内存还要大，至少超过
innodb_buffer_pool_size
值，不能将数据全部装载到内存中，除非你的本意就想测试全内存状态下的MySQL性能。
b、每轮测试完成后，都重启mysqld实例，并且用下面的方法删除系统cache，释放swap（如果用到了swap的话），甚至可以重启整个OS。
-- 将脏数据刷新到磁盘
[]# echo 3 & /proc/sys/vm/drop_cache
-- 清除OS Cache
[]# swapoff -a && swapon -a
2、如何尽可能体现线上业务真实特点
【老叶建议】有2点建议
a、其实上面已经说过了，就是自行开发测试工具或者利用
tcpcopy（或类似交换机的mirror功能） 将线上实际用户请求导向测试环境，进行仿真模拟测试。
siege 工具模拟真实的用户请求URL进行压力测试，这方面我不是太专业，可以请教企业内部的压力测试同事。
3、压测结果如何解读
【老叶建议】压测结果除了tps/TpmC指标外，还应该关注压测期间的系统负载数据，尤其是
iops、iowait、svcmtm、%util、每秒I/O字节数(I/O吞吐)、事务响应时间(tpcc-mysql/sysbench 打印的测试记录中均有)。另外，如果I/O设备能提供设备级
IOPS、读写延时 数据的话，也应该一并关注。
加入两次测试的tps/TpmC结果一样的话，那么谁的
事务响应时间、iowait、svctm、%util、读写延时 更低，就表示那个测试模式有更高的性能提升空间。
4、如何加快tpcc_load加载数据的效率
【老叶建议】tpcc_load其实是可以并行加载的，一方面是可以区分
ITEMS、WAREHOUSE、CUSTOMER、ORDERS 四个维度的数据并行加载。
另外，比如最终想加载1000个 warehouse的话，也可以分开成1000个并发并行加载的。看下 tpcc_load 工具的参数就知道了：
usage: tpcc_load [server] [DB] [user] [pass] [warehouse]
tpcc_load [server] [DB] [user] [pass] [warehouse] [part] [min_wh] [max_wh]
* [part]: 1=ITEMS 2=WAREHOUSE 3=CUSTOMER 4=ORDERS
本来想自己写个并行加载脚本的，后来发现万能的github上已经有人做好了，我就直接拿来用了，这是项目链接
tpcc_load_parallel.sh，加载效率至少提升10倍以上。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1131407次
积分：10841
积分：10841
排名：第1220名
原创：153篇
转载：138篇
评论：106条
(6)(2)(5)(4)(5)(4)(2)(4)(2)(1)(3)(1)(2)(2)(7)(13)(3)(1)(2)(3)(14)(8)(23)(3)(1)(5)(19)(7)(3)(1)(2)(2)(6)(14)(13)(1)(4)(9)(10)(3)(7)(7)(20)(24)(21)随着开源Hapdoop、Map/Reduce、Spark、HDFS、HBASE等技术的商用化，大数据管理技术得到了突飞猛进的发展。一般来说，大数据具有3V特性，即Volume（海量）、Velocity（高速）和Variety（多样）[1]。TPC联合主席、Cisco高级工程师Raghunath Nambiar进一步认为大数据还面临Value（价值）和Veracity（精确）的挑战。如何客观地比较不同数据管理系统，即大数据测试基准的选择，成为一个重要的研究课题。
事务性能管理委员会(TPC)是目前最知名的数据管理系统评测基准标准化组织。在过去二十多年间，该机构发布了多款数据库评测基准，如TPC-A、TPC-D、TPC-H和TPC-DS，在业界得到了广泛应用[2]。BigBench和BigFrame是对TPC-DS进行多样化的数据扩充的测试基准。近年来，Apache开源社区针对Map/reduce架构开发了多款性能测试用例，如TestDFSIO、teraSort。国内对大数据测试基准的研究起步较晚，尚未建立起权威的测试基准。目前由中国信息通信研究院牵头，联合中科院计算所及国内外知名公司和机构共同制定的大数据测试基准正在金罗密布的测试中[3]。
为了方便企业选择合适的大数据测试基准，本文将在分析总结现有成果的基础，进一步讨论大数据测试基准应该具有的要素；并以此为基础，对比现有的大数据测试基准；然后重点讨论TPC-DS测试基准。
一、大数据测试基准的选择
企业在选择大数据测试基准时，首先应考虑基准与其自身业务的相关性。
1. 与其自身业务的相关性
它主要描述测试基准设定的应用场景是否与企业的实际业务场景类似，如基于社交网络应用的评测基准与银行系统的应用场景就没有什么相关性。不相关的基准，测试结果再好，也没有实际意义。相关性还要考虑测试基准所采用的数据模型是否代表数据仓库的发展方向，如基于星型模型的开发要比基于传统的关系模型开发更加有效。
当然，一套行之有效的大数据测试基准包含许多其它要素。Jim Gray及金澈清等学者[4]已经对度量选取、模拟数据生成器、工作负载设定、审计等要素进行了详细论述。除此之外，本文还认为测试基准的健壮性、SQL标准的兼容性和通用性/可移植性也是重要的要素。
2. 模拟数据生成要具有真实性
它描述了测试基准是否仿真真实应用场景，所产生的模拟数据是否与真实数据相似。
3. 工作负载的设定具有可扩展性
它描述该评测基准是否适用于不同规模的计算机系统，许多评测基准会使用标度因子来决定模拟数据的规模，通过调整标度因子来得到不同规模的工作负载。
4. 度量的选取的可理解性
它衡量该评测基准是否易于为用户理解，不易为用户理解的基准的可信程度也较低。
5. 客观性与公正性
众所周知，在竞技比赛中，一个人不能既是运动员又是裁判员。测试基准好比竞技比赛中的裁判员，应该由中立的第三方机构制定。事实也证明，在各个领域最受欢迎的测试基准都是有第三方机构设计的。过去20多年的经历证明TPC系列基准是数据库领域最为广泛接受的基准。除此之外，第三方机构的审计也是保证证评测结果的客观性与公正性的重要手段。
测试基准要足够健壮，不能轻易被“hack”，这对测试结果的公平性非常重要。例如对TPC-H的前身TPC-D，通过物理化视图，Oracle的性能比Micosoft的SQLServer高100倍，这些显然是不公平的。因此TPC组织规定TPC-H测试中物理化视图是不和法的。但是除非是专业人员，一般用户很难判定测试过程中视图有没有被物理化。TPC-DS在健壮行方面要好很多，因为它的SQL本身比较复杂，也比较多，Hack起来相对困难，并且只hack几个SQL对整体性能提高有限。
7. SQL标准兼容性
SQL是ANSI为统一各个数据库厂商之间的编程差异定义的标准，已发布SQL86、SQL92、SQL99、SQL2003等版本。这些标准已经被主流的商用（例如Oracle、DB2、SQL server）以及开源的数据库产品（例如MySQL、mSQL和PostgreSQL）的广泛采用。对整个数据库产业的发展起到了巨大的推动作用。大数据是个新兴的领域，它的发展不能完全抛弃原有的应用。如果不能全面支持SQL标准，现有系统的移植非常困难，学习曲线就会变长。
8. 通用性/可迁移性
通用性描述是否可在不同数据库系统和架构上实现指定的评测基准。测试基准不应该规定实现的细节，而只需要定义测试规范。DBMS只要遵循规范得到正确的结果，就是合理的测试，无论其基于Map/Reduce、Spark还是其他的技术，也不管其底层存储是用HDFS、HBASE还是其他方式。
二、大数据测试基准对比
经过30几年的研究，传统数据库测试基准的研究已经相当成熟，在各个领域出现了行之有效的测试基准。随着大数据应用的发展，大数据测试基准的研究最近几年逐渐兴起，但大都是在传统的测试基准的基础进行裁剪、扩充、综合。金澈清等学者[4]对数据库基准的发展概述如图1所示。
本文重点关注被列为大数据测试基准的相关基准、BigFrame[5]以及TPC-DS，对其它的基准本文不再赘述，有兴趣的读者请参阅文[4]。
1. Map/reduce性能测试
如文[4]中所述，MRBench、HiBench、TestDFSIO、Sort/teraSort只是针对Map/Reduce框架，目的是评测运行Map/Reduce框架的集群的性能。CALDA基准尝试比较不同架构在数据管理方面的性能。这些测试过于简单，无法模拟复杂的应用，也不通用。
2. YCSB/YCSB++/LinkBench
这是一组针对网络应用的测试基准。YCSB（Yahoo! Cloud Serving Benchmark）及其扩展YCSB++测试查询回复的延时等云服务系统中云计算的特点，如查询回复的延时、纵向扩展和弹性加速比、并行性测试等。LinkBench是一个基于社交网络应用的评测基准。它仿真Facebook公司的图数据管理应用，包括数据特性、工作负载以及度量等。这些都是公司开发的针对自己特定应用场景的测试基准，很难在整个行业内进行推广。
3. BigBench
BigBench是一款面向商品零售业的基准，它扩展了TPC-DS，综合考虑多种数据模态，增加了半结构化数据Web Log和非结构化数据Reviews。其负载的生成是TPC-DS定制化的版本。BigBench包含30个查询。BigBench基本数据模型如图2所示：
4. BigFrame
BigFrame是一个测试基准生成器[5]，用户可以根据自己的需求定制专有测试基准。在目前实现中，其关系模型与BigBench类似，也是基于TPC-DS。同时它扩展了半结构化和非结构化的数据Tweets以及图形化数据Followee/Follower。BigFrame基本数据模型如图3所示：
如文[5]所述，大数据与决策支持系统（DSS）并不是完全独立的，大数据也不能抛弃传统。DSS系统中，只要数据量足够大，都可以认为是大数据问题。被化为大数据测试基准的BigBench和BigFrame的大部分内容都来自于TPC-DS，从这个意义上讲，TPC-DS不但是一种结构数据的大数据测试基准，而且是其它大数据测试基准的基础。
三、TPC-DS
TPC-DS测试基准是TPC组织推出的用于替代TPC-H的下一代决策支持系统测试基准。因此在讨论TPC-DS之前，先介绍一下TPC-H。
TPC-H是一款面向商品零售业的决策支持系统测试基准，它定义了8张表，22个查询，遵循SQL92。TPC-H的数据模型如图4所示。TPC-H基准的数据库模式遵循第三范式，叶晓俊教授等学者[6]认为“它的数据表数据特征单一(如数据不倾斜) ，其数据维护功能仅仅限制了潜在的对索引的过度使用，而没有测试DBMS 执行真实数据维护操作——数据提取、转换和加载(ETL) 功能的能力”。同时，新兴的数据仓库开始采用新的模型，如星型模型、雪花模型。TPC-H已经不能精准反映当今数据库系统的真实性能。为此，TPC组织推出了新一代的面向决策应用的TPC-DS
TPC-DS采用星型、雪花型等多维数据模式。它包含7张事实表，17张纬度表平均每张表含有18列。其工作负载包含99个SQL查询，覆盖SQL99和2003的核心部分以及OLAP。这个测试集包含对大数据集的统计、报表生成、联机查询、数据挖掘等复杂应用，测试用的数据和值是有倾斜的，与真实数据一致。可以说TPC-DS是与真实场景非常接近的一个测试集，也是难度较大的一个测试集。
TPC-DS的这个特点跟大数据的分析挖掘应用非常类似。Hadoop等大数据分析技术也是对海量数据进行大规模的数据分析和深度挖掘，也包含交互式联机查询和统计报表类应用，同时大数据的数据质量也较低，数据分布是真实而不均匀的。因此TPC-DS成为客观衡量多个不同Hadoop版本以及SQL on Hadoop技术的最佳测试集。这个基准测试有以下几个主要特点：
一共99个测试案例，遵循SQL’99和SQL 2003的语法标准，SQL案例比较复杂分析的数据量大，并且测试案例是在回答真实的商业问题测试案例中包含各种业务模型（如分析报告型，迭代式的联机分析型，数据挖掘型等）几乎所有的测试案例都有很高的IO负载和CPU计算需求
叶晓俊等学者对这些查询的分部总结如表1所示[6]。典型的Store_Sales的数据模型如图5所示。这个基准测试的完整信息请参考。
3. TPC-DS认证现状
TPC-DS以其高标准、高要求得到大家的广泛认知，理应得到广泛的应用，但是到目前为止还没有任何厂商得到TPC官方的认证。究其原因，本文认为：
传统的数据库厂商，DBMS系统比较成熟，SQL的支持也相当完善，但是其分布式、并行处理能力欠缺，导致其性能很差。所以传统的厂商不愿意发布测试结果。
新型的计算模型如Map/Reduce、spark，具有较好的并行处理能力，但是SQL的兼容性比较差，如HiveSQL、SparkSQL只支持40个SQL，从而也无法发布TPC-DS测试报告。尽管如此，各厂商还是通过非TPC官方的途径发布TPC-DS的部分测试结果，以展现其在性能方面的提升。由此可见大家对TPC-DS的程接受度。
四、结束语
大数据评测基准用于公平、客观地评测不同大数据库产品/平台的功能和性能，对人们选择合适的大数据分析决策系统具有重要的参考价值。随着国内外各代表性的Hadoop发行版厂商以TPC-DS为标准测评产品，TPC-DS也就逐渐成为了业界公认的大数据系统测试基准。但是随着大数据应用在各行各业的发展，测试基准也需不断与时俱进。大数据测试基准仍然面临着诸多挑战，还需要政府、学术界和工业界的紧密合作。
[1]Big data: Science in the petabyte era. Nature, : 1-136
[2]www.tpc.org
[4]金澈清, 钱卫宁, 周敏奇, 周傲英，数据管理系统评测基准：从传统数据库到新兴大数据，计算机学报, 2014.
[5]M. Barata, etc, Survey on Big Data and Decision Support Benchmarks, LNCS –182, 2014.
[6]陈旦，叶晓俊，施霖, TPC-DS性能测试工具的实现, 计算机应用，第31 卷，第9期, 2011.
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：74639次
积分：1481
积分：1481
排名：千里之外
原创：52篇
转载：172篇
(5)(5)(7)(5)(1)(1)(3)(7)(3)(7)(6)(1)(3)(2)(4)(3)(9)(8)(1)(13)(17)(3)(18)(20)(5)(2)(6)(7)(9)(2)(11)(26)(6)博客访问： 3974957
博文数量： 190
博客积分： 3600
博客等级： 中校
技术积分： 9397
注册时间：
专注系统运维、网络架构，研究技术解决方案，记录我的思想轨迹、工作学习、生活和关注的领域
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： 系统运维
TPC(Tracsaction&Processing&Performance&Council)&事务处理性能协会是一个评价大型数据库系统软硬件性能的非盈利的组织是协会制定的，用来测试典型的复杂系统的性能。是基于衍生出来的产品，专用于基准测试，其源码放在上，因此需要先安装客户端。
项目地址：
一&下载工具
首先，安装客户端&
# yum -y install bzr
下载过程中遇到的问题
# bzr branch lp:~percona-dev/perconatools/tpcc-mysql
bzr: ERROR: Couldn't import bzrlib and dependencies.
Please check the directory containing bzrlib is on your PYTHONPATH.
Traceback (most recent call last):
File "/usr/bin/bzr", line 102, in
import bzrlibpython
ImportError: No module named bzrlib
提示找不到&模块，因为调用Python，建议升级到版本
# find / -name bzrlib -print
/usr/lib64/python2.4/site-packages/bzrlib
定义环境变量
# export PYTHONPATH=/usr/lib64/python2.4/site-packages
#bzr branch lp:~percona-dev/perconatools/tpcc-mysql
You have not informed bzr of your Launchpad ID, and you must do this to
write to Launchpad or access private data.
See "bzr help launchpad-login".
Branched 48 revision(s).
bzr: warning: some compiled extensions see
二&编译安装
进入源码目录
#cd tpcc-mysql/src
cc -w -O2 -g -I. `mysql_config --include`
cc -w -O2 -g -I. `mysql_config --include`
-c support.c
cc load.o support.o `mysql_config --libs_r` -lrt -o ../tpcc_load
cc -w -O2 -g -I. `mysql_config --include`
cc -w -O2 -g -I. `mysql_config --include`
-c spt_proc.c
cc -w -O2 -g -I. `mysql_config --include`
-c driver.c
cc -w -O2 -g -I. `mysql_config --include`
-c sequence.c
cc -w -O2 -g -I. `mysql_config --include`
-c rthist.c
cc -w -O2 -g -I. `mysql_config --include`
-c neword.c
cc -w -O2 -g -I. `mysql_config --include`
-c payment.c
cc -w -O2 -g -I. `mysql_config --include`
-c ordstat.c
cc -w -O2 -g -I. `mysql_config --include`
-c delivery.c
cc -w -O2 -g -I. `mysql_config --include`
cc main.o spt_proc.o driver.o support.o sequence.o rthist.o neword.o payment.o ordstat.o delivery.o slev.o `mysql_config --libs_r` -lrt -o ../tpcc_start
三&初始化测试库环境
make命令会在目录下生成&命令行工具&
tpcc_load&&提供初始化数据的功能
tpcc_start&进行压力测试
# ./tpcc_load --help
tpcc_load [server] [DB] [user] [pass] [warehouse]
Server: 服务器名
Warehouse:
仓库的数量
#./tpcc_start --help
tpcc_start -h server_host -P port -d database_name -u mysql_user -p mysql_password -w warehouses -c connections -r warmup_time -l running_time -i report_interval -f report_file
介绍一下各个参数的用法
-h server_host:
端口号，默认为3306
-d database_name:
-u mysql_user :
-p mysql_password : 密码
-w warehouses:
仓库的数量
-c connections :
线程数，默认为1
-r warmup_time :
热身时间，单位:s，默认为10s ,热身是为了将数据加载到内存。
-l running_time:
测试时间，单位:s，默认为20s
-i report_interval:
指定生成报告间隔时长
-f report_file:
测试结果输出文件
tpcc&默认会读取这个位置，如果你的测试环境的不在相应路径的话，就需要做个软连接，或者通过的方式连接测试服务器。
准备工作： & & & & &
#mysql -uroot -p -e "create database tpcc"
# 创建测试用的数据库
#mysql -uroot -p tpcc < create_table.sql
# 创建测试用的表
#mysql -uroot -p
tpcc < add_fkey_idx.sql
# 创建FK和索引
1&创建五个数据仓库
#./tpcc_load
localhost tpcc root "
*************************************
*** ###easy### TPC-C Data Loader
*************************************
[server]: localhost
[port]: 3306
[DBname]: tpcc
[user]: root
[pass]: 123456
[warehouse]: 5
TPCC Data Load Started...
Loading Item
.................................................. 5000
.................................................. 10000
忽略部分输出结果
四、进行测试
使用进行个线程的测试热身时间为秒测试时间为小时&！
# ./tpcc_start
-hlocalhost
-p "123456" -w 5
300 - >tpcc-output-log
五、生成图表
首先写一个脚本获取数据源：
# cat tpcc-output-analyze.sh
TIMESLOT=1
if [ -n "$2" ]
TIMESLOT=$2
cat $1 | grep -v HY000 | grep -v payment | grep -v neword | awk -v timeslot=$TIMESLOT 'BEGIN { FS="[,():]"; s=0; cntr=0; aggr=0 } /MEASURING START/ { s=1} /STOPPING THREADS/ {s=0}
/0/ { if (s==1) { cntr++; aggr+=$2; } if ( cntr==timeslot ) { printf ("%d %3d\n",$1,(aggr/timeslot)) ; cntr=0; aggr=0 } }'
# cat tpcc-output-analyze.sh
TIMESLOT=1
if [ -n "$2" ]
TIMESLOT=$2
cat $1 | grep -v HY000 | grep -v payment | grep -v neword | awk -v timeslot=$TIMESLOT 'BEGIN { FS="[,():]"; s=0; cntr=0; aggr=0 } /MEASURING START/ { s=1} /STOPPING THREADS/ {s=0}
/0/ { if (s==1) { cntr++; aggr+=$2; } if ( cntr==timeslot ) { printf ("%d %3d\n",$1,(aggr/timeslot)) ; cntr=0; aggr=0 } }'
这个脚本就是对&的第一列与第二列进行运算。
#./tpcc-output-analyze.sh
tpcc-output-nobinlog > tpcc-graphic-data.txt
绘图过程：
#cat log.conf
set terminal gif small size 480,360
#指定输出成gif图片，且图片大小为550×25
set output "tcpp.gif"
#指定输出gif图片的文件名
set title "MySQL Performance" #图片标题
set style data lines
set xlabel "Time/s"
set ylabel "Data"
"tpcc-graphic-data.txt" using 1:2 title "Total throughput" with lines #从tpcc-graphic-data.txt文件中读取第一列和第二列作为X轴和Y轴数据，示例名"Total throughput"
#cat log.conf
set terminal gif small size 480,360
#指定输出成gif图片，且图片大小为550×25
set output "tcpp.gif"
#指定输出gif图片的文件名
set title "MySQL Performance" #图片标题
set style data lines
set xlabel "Time/s"
set ylabel "Data"
"tpcc-graphic-data.txt" using 1:2 title "Total throughput" with lines #从tpcc-graphic-data.txt文件中读取第一列和第二列作为X轴和Y轴数据，示例名"Total throughput"
运行生成：
#cat log.conf | gnuplot
补充gnuplot绘图，详细可以google下
例如得到文件类似如下：
11:23 28 15
11:24 10 7
11:25 224 37 13
11:26 470 192
11:27 344 187 1
11:28 441 77 2
11:29 419 8
然后创建如下：
set terminal png xFFEEDD size
set output "log.png"
set autoscale
set xdata time
set timefmt "%H:%M"
set format x "%H:%M"
set xtics 10
set mxtics 4
set style data lines
set datafile missing "0″
set xlabel "time per day"
set ylabel "purge"
set title "DPD expires"
plot "log" using 1:2 title "html/min","log" using 1:3 title "js/min","log" using 1:4 title "css/min"
运行就得到了，如下：
参考文章：
阅读(14876) | 评论(1) | 转发(5) |
相关热门文章
给主人留下些什么吧！~~
四、进行测试使用tpcc_start&进行5个线程的测试,热身时间为120秒,&测试时间为1小时&！#&./tpcc_start&-hlocalhost&-d&tpcc&-u&root&-p&&123456&&-w&5&-c&5&-r&120&-l&300&-&&tpcc-output-log测试时间有误，应该是-l&3600吧？
请登录后评论。}