服务器TPMC值计算.docx
《服务器TPMC值计算.docx》由会员分享，可在线阅读，更多相关《服务器TPMC值计算.docx（13页珍藏版）》请在冰豆网上搜索。
服务器TPMC值计算
服务器TPMC值计算
TPC基准程序是用来测系统而不是测主机的
目标：
系统性能评估结果<主机性能评估结果
TPC已经推出了四套基准程序，被称为TPC－A、TPC－B、TPC－C和TPC－D。
其中A和B已经过时，不再使用了。
TPC－C是在线事务处理（OLTP）的基准程序，TPC－D是决策支持（DecisionSupport）的基准程序。
TPC即将推TPC－E，作为大型企业（Enterprise）信息服务的基准程序。
TPC－C是在线事务处理（OLTP）的基准程序，性能由TPC－C吞吐率衡量，单位是tpmC（tpm,transactionsperminute）；C指TPC中的C基准程序。
它的定义是每分钟内系统处理新订单个数。
TPC－C还经常以系统性能价格比的方式体现，单位是＄/tpmC，即以系统的总价格（单位是美元）/tpmC数值得出。
每分钟内系统处理的新订单个数
以服务器为例。
在很多厂家的TPC测试系统中，服务器的价格只是系统总价格的25％或更小，而硬盘的价格有可能占到总价格的30％以上，因为TPC－C要求被测系统必须保存180天的事务记录
根据TPC-C的标准，tpmC值是根据标准模型中New-Order事务的处理数目来计算的，一个New-Order事务由平均4-5个SQL语句处理完成，整个测试的执行过程中，New-Order处理占45%。
估算条件：
运行商2003年将达到250万用户数
每天每用户产生5张话单
分析过程：
每分钟处理：
（用户数）250万*5/24/60=9250
峰值处理：
9250*1.5=11350
需执行约6个SQL语句，则估算一个话单汇总处理业务相当的TPC-C值为：
6*0.45/4=0.67Tpmc
话单汇总和分析的TPC-C值要求满足：
11350*0.67Tpmc=9300Tpmc
考虑25%的冗余（系统其它开销）：
主机性能=9300Tpmc*1.25=11000Tpmc
各位，我是因为查TPC-C从谷歌来到这个论坛的。
第一次来，也很喜欢这里。
看来又多了一个基地了。
关于TPC-C值的计算我还有一些问题求助。
--------我这里有从TPC的官方网站上找到的资料，但是他的测试环境是满配置的情况下得出的，在我的方案里面从扩展性和主机具体应用考虑，客户希望我能给他当前配置下的TPC-C的数值。
这个怎么换算？
惯例还是公式？
（我的计算对象包括PC-SERVER应用服务器和HP-动能SD小机，这两个的计算方法一样吗？
）
PS：
这是我从网上查到的资料有关小机的数值估算的方法----表现主机性能的一个重要指标是TPC－C测试。
TPC－C由独立的第三方机构TPC对各厂商主机的交易处理能力进行测试。
由于进行此测试的主机大都采用多CPU、超大规模内存，数据库操作大都在内存中完成，因而，TPC－C主要是针对CPU和内存的处理能力及相互间的交换能力的测试。
理想的单交换机情况下，由于各CPU之间互不干扰，CPU和内存之间交换信息顺畅，主机整体性能随CPU数目呈线性增加。
然而，在两级交换体系结构下，CPU访问本地内存与远端内存时间之比为1:
2.9。
即：
CPU和内存之间的交换能力几乎损失30％。
因此，我们粗略地估计，主机整体性能增长率为CPU数目增长率的70％。
＊ASR1GS160（1GHZ）16CPU的TPC－C值
推算如下：
GS320（1GHZ）32CPU的测试值为230,000。
因此，我们推算其
16CPU的TPC－C值=230,000÷70％÷2=164,285
＊ASR2GS80（1GHZ）8CPU的TPC－C值
推算如下：
GS160（1GHZ）16CPU的估算值为164,285。
因此，我们推算其8CPU的TPC－C值=164,285÷70％÷2=117,346
＊ASR3GS80（731GHZ）4CPU的TPC－C值
推算如下：
GS160（731MHZ）16CPU的测试值为71,000。
因此，我们推算其
8CPU的TPC－C值=71,000÷70％÷2=50,714
4CPU的TPC－C值=50,714÷70％÷2=36,224
同时，大家可以从康柏AlphaServerES系列小型机的TPC－C值得到应证。
AlphaServerES4CPU，731MHZ的TPC－C值为37,274。
因此，我们可以得到以下结论：
＊康柏AlphaServerGS16016CPU1GHZ的TPC－C值为164,285左右。
＊康柏AlphaServerGS808CPU1GHZ的TPC－C值为117,346左右。
＊康柏AlphaServerGS804CPU731MHZ的TPC－C值为36,224左右。
服务器性能评估的实战技巧
服务器在政府信息化项目中的作用不言而喻。
政府信息化需求的内在特性，决定了政府采购服务器须考虑特定的性能依据，由此在实践中衍生出不同的服务器性能评测方法。
政府采购服务器时，通常会从应用系统的基本需求、服务器的性能和价格等方面进行综合考虑。
首先，服务器的性能必须满足系统的基本需求，如海量数据的高速存取、对事务要求的快速响应、以及系统的稳定性等。
其次，考虑服务器的基本指标，如结构、CPU、内存、缓存、通道、磁盘、接口、操作系统、实用软件。
再次，服务器还应当具有较好的性价比。
而且在政府采购中，经常要求对服务器的性能评估有明确的数值要求。
关于服务器性能的评估有一些通常的方法（见相关链接），但这些方法在实际操作中都存在着比较大的困难。
首先，政府采购时往往是应用系统还没建立，因此无从在实际环境中进行测试实施；即使目前有实际的运行环境，也由于考虑到风险性和成本，无法使用新机器进行代替运作。
其次，目前还只有一两个垂直部门有能力建立自己的基准测试程序。
而且由于各政府部门的业务性强，大多数政府部门的用户基准测试程序跟本身的业务关联紧密，一般商用的评测平台也不太适合。
而且基准测试程序又经常与应用系统的设计和编程等密切相关，需要给出一些经验估值。
而政府采购当中对服务器的性能要求有比较明确的数值规定。
那么，如何在实际操作中解决问题呢？
1．比较同类型项目的服务器选型
对于本地系统还没有建立，而外地同类型系统已经建立的情况，通过比较同类型项目的同系列服务器选型不失为一种简单快捷的方式。
由于各地的各政府部门的业务基本类似，如广州市某系统，可以比照同类型项目，如北京、上海、深圳、武汉、重庆、沈阳、天津等地的同类系统的服务器性能，比较这些同类型项目的服务器的TPCC值及CPU的实际占用率等，按相应比例（通常可以根据业务量、人口量）可估算出项目的服务器性能的具体参数。
计算公式
已知A市某系统的数据服务器的TPMC值为K1，而参加A市该系统的人数为P1，而B市同类型系统的参加人群为P2，那么B市该系统的数据服务器的TPMC值为（P2/P1）×K1。
2．将真实需求与基准测试程序结合
在本地系统已经建立的情况下，可以根据历史使用情况和真实的比较明确的需求，结合基准测试程序进行评估。
在有比较明确的业务需求或已经有相应的历史数据的情况下，可以确定整个系统在一个长时间范围内，如1天、1周、或1个月的业务需求，如有x人次的真实OLTP运算（或者逻辑运算，或者复杂数据挖掘查询响应）。
然后把这些长时间内必须完成的宏观真实业务需求，转化某一个特定的时间段内的真实业务需求（如1个小时或1分钟），目的是为了让这些真实需求和基准测试标准对应起来。
这些真实业务处理请求在具体的信息系统实施中可以折算成若干个具体的计算机应用处理。
这些处理根据复杂程度不同，可以和具体的第三方基准测试进行比照，折算成若干个基准测试基本单位。
然后把这些子系统分别对应的基准测试单位需求加起来，就可以得到这些真实的应用所需要的基准测试的需求。
这些真实业务需求和具体计算机应用处理需求的转换，还有具体计算机应用处理需求和第三方基准测试标准单位之间的转换，都需要具体的业务开发部门根据自己的应用代码、应用模式和网上公布的基准测试的测试代码或者数学模型进行比较，以得到转换的参数。
这样才可以根据不同的业务系统，针对不同的专门基准测试进行比照，得出所需要的以专门基准测试标准单位为单位的服务器处理能力需求。
计算公式
在需要处理的各个业务中，选择一项或几项业务量比较大的业务，假设这些业务占总业务量的A%。
对于这些业务，假设每天服务器约处理X人次的业务，每次业务换算成后台业务处理，则大约为Y笔交易，假设每天业务集中在B小时内完成（因早晚业务量较小），而在这段时间内业务量的分布并不均匀，根据经验，确定峰值业务量通常为平均值的C倍。
且根据系统设计和实际经验，估算每个交易相当于D个基准测试程序。
考虑系统的扩展性，平常只使用到系统的E%，因此该服务器的TPMC值为（X×Y×C×D）/（A%）/（E%）/B/60。
3．将设定需求与基准测试程序结合
而对于一些新兴的应用系统来说，基本上没有历史数据和业务量进行参考，而且国内也基本没有同类型项目。
在这种情况下，通常采用设定需求和基准测试程序相结合的方法。
而设定需求可以通过设定业务需求，再根据上述的第2种方法进行计算。
但往往也很难估算具体的业务需求。
我们还可以采用估算连接服务器的终端个数，以及对连接终端可能所作的操作进行分类和统计，从而估算到系统的性能。
计算公式
假定对于某系统，选取连接终端数比较集中的1小时内进行计算，而在这段时间的峰值量为平均值的F倍。
在这1小时内，假定有A、B和C类操作，其中有N1台终端连接进行A操作，一个A操作需要耗时T1分钟；N2台终端进行B操作，一个B操作需要耗时T2分钟；N3台终端进行C操作，一个C操作需要耗时T3分钟。
且根据系统设计和实际经验，A操作的一个操作相当A1个基准测试程序，B操作的一个操作相当B1个基准测试程序，C操作的一个操作相当C1个基准测试程序。
考虑到系统的扩展性，平常只使用到系统的E%，因此该系统的TPMC=（N1×A1/T1+N2×B1/T2+N3×C1/T3）×F/（E%）。
链接
服务器性能常规评估方法
1．在真实环境中运行实际应用
最理想的方式是通过一个试点，要求制造商或系统集成商配合将系统（含平台、软件和操作流程）在一个实际的环境中真正试运行一段时间。
这样，不仅能看到服务器系统的实际性能，也能观察到系统是否稳定可靠、使用是否方便、服务是否周到、配置是否完备、价格是否合理。
如果一个部门或委局需要购买一批同类的系统，可以考虑采用这种方式，用户还可先租一套系统作为试点。
用这种方式得到的度量值比理论推算或摸拟测量更加符合实际，更加可信。
2．使用用户定义的基准程序
用户可以定义一组含有自己实际应用环境特征的应用基准程序。
这对于政府垂直行业应用的服务器有比较好的借鉴作用。
如中国税务总局开发了自己的基准程序，以帮助税务系统进行计算机选型。
3．采用通用基准程序
一般来说，常用的基准测试程序为TPC基准测试程序和SPEC基准测试程序。
TPC（TransactionProcessingCouncil，事务处理委员会）成立于1988年，已有40多个成员，用于评测计算机的事务处理、数据库处理、企业管理与决策支持等方面的性能。
1989年以来相继发表的TPC基准测试程序包括TPC-A、TPC-B、TPC-C、TPC-W、TPC-R和TPC-H等。
其中TPC-A用于在线联机事务处理下更新密集的数据库环境下的性能测试，TPC-B用于数据库系统及运行它的操作系统的核心性能测试，TPC-C则用于在线联机事务处理测试，TPC-D用于决策支持系统测试，TPC-H是基于TPC-D基础上决策支持基准测试，还有TPC-W是用于电子商务应用软件测试。
SPEC（StandardPerformaneEvaluationCorporation，标准性能评估公司）是由30个左右世界知名计算机大厂商所支持的非盈利的合作组织，其成员包括IBM、AT&T、BULL、CDC、DG、DEC、富士通、HP、Intel、MIPS、摩托罗拉、SGI、SUN、Unisys等。
SPEC能够全面反映机器的性能，具有很高的参考价值，当前主要的基准测试程序有SPECint_base_rate2000、SPECfp_base_rate2000和SPECJBB2000等。
还有基于某种数据库运行环境下的测试，也是可以参考的数值。
在采用通用基准测试程序时，要注意真实的业务流程和使用环境与通用测试基准的业务流程和使用环境的异同，这样，基准测试值才有参考价值。
当前电信业已进入群雄并起、竞争极端激烈的战国时代，在话音、数据和各种增值服务等领域，国内各电信运营商，在高端和低端的不同层次上，展开了大规模的中原逐鹿。
在如此复杂的局面下，在众多繁复的业务种类竞争中，如何保证一个电信企业的良好运作，建立一个顺畅的收入现金流至为重要。
这也就是为什么电信企业在计费系统上进行了不遗余力的投资。
但是，正是业务种类层出不穷的推出、通信模式和接入技术快速进步，使电信计费系统存在着难以满足需要的局面，往往制约了电信的运营和业务的开展。
如何建立一套能够满足当前乃至今后一定时间的业务开展，又能够保证安全稳定易管理的电信综合计费系统，是各电信运营商和电信科研单位极为重视的一个课题。
下面结合中国网通的计费系统建设经验，为即将建设的计费系统的服务器选型方面提供一些建议和参考。
电信计费系统架构
电信计费系统通常有如下种类的服务器：
*接口服务器
*认证服务器
*计费服务器
*采集服务器
*数据库服务器
*管理工作站等
其中，核心服务器为计费服务器、认证服务器和数据库服务器。
在一些小型的计费系统中，接口服务器可以与采集服务器合一，计费服务器可以与认证服务器，甚至与数据库服务器合一，管理工作站也可以不设置专用工作站，而用WEB管理方式。
对于这些服务器，用途不同，在不同规模的计费系统方案中的组合也不同，业务规模也对服务器的处理性能、存储性能、开放等性能需求不同。
选择适当的服务器，不仅能够充分满足业务开展所需，而且能够提供为未来业务发展所需的系统扩展能力，这样既保障了运营，又能够节省投资。
下面对计费系统的服务器选型、处理性能换算方法提出一些参考建议。
服务器处理性能计算方法
按照电信计费系统的统计经验值，一般每1万用户配置5个终端，通常同时访问数据库的终端数目概率为20%，每次访问请求需处理1秒，其中平均要完成5个交易，由此需要的服务器处理性能为：
用户数×5×206×5×60/（10000×1）（TpmC）
选型参考建议
*标准化原则
符合ISO和ANSI标准，符合SVRV4标准，符合中国的有关计算机技术标准，选择当今业界较为流行的主要产品。
*高性能原则
保证所选购的服务器，不仅能够满足运营系统的运行和业务处理的需要，而且能够满足一定时期的业务量增长的需要。
采用上面公式，计算出所需的服务器TpmC值，比较IDC公布的权威测算的厂商服务器TpmC值，选择相应的机型。
同时，用服务器的市场价/报价除上计算出来的TpmC值得出单位TpmC值的价格，从而选择高性能价格比的服务器。
*可靠性原则
可靠性原则是所有选择设备和系统中要考虑的，尤其是在大型的、有大量处理要求的、需要长期运行的系统。
考虑服务器系统的可靠性，不仅要考虑服务器单个节点的可靠性或稳定性，而且要考虑服务器与相关辅助系统之间连接的整体可靠性，如：
网络系统、安全系统、远程打印系统等。
在必要时，还应考虑对关键服务器采用集群技术，如：
双机热备份或集群并行访问的N+n技术，甚至采用可能的完全容错机。
保证系统（硬件和操作系统）在99.98%的时间内都能够正常运作（包括维修时间），则故障停机时间六个月不得超过0.5个小时。
服务器需7×24小时连续运行，因而要求其具有很高的安全可靠性。
系统整机平均无故障时间（MTBF）不低于80000小时。
服务器如出现CPU损坏或其它机械故障，都能在20分钟内由备用的CPU和机器自动代替工作，无须人员操作，保证数据完整。
*可扩展性原则
保证所选购的服务器具有优秀的可扩展性原则。
因为服务器是所有系统处理的核心，要求具有大数据吞吐速率，包括：
I/O速率和网络通讯速率，而且服务器需要能够处理一定时期的业务发展所带来的数据量，需要服务器能够在相应时间对其自身根据业务发展的需要进行相应的升级，如：
CPU型号升级、内存扩大、硬盘扩大、更换网卡、增加终端数目、挂接磁盘阵列或与其他服务器组成对集中数据的并发访问的集群系统等。
这都需要所选购的服务器在整体上具有一个良好的可扩充余地。
一般数据库和计费应用服务器在大型计费系统的设计中就会采用集群方式来增加可靠性，其中挂接的磁盘存储系统，根据数据量和投资考虑，可以采用DAS、NAS或SAN等实现技术。
对于RediusServer可以依靠Redius协议采用双机互备，但不需要专门购买的集群软件。
*安全性原则
服务器处理的大都是相关系统的核心数据，其上存放和运行着关键的交易和重要的数据。
这些交易和数据对于拥有者来说是一笔重要的资产，他们的安全性就非常敏感。
服务器的安全性与系统的整体安全性密不可分，如：
网络系统的安全、数据加密、密码体制等。
服务器需要在其自身，包括软硬件，都应该从安全的角度上设计考虑，在借助于外界的安全设施保障下，更要保证本身的高安全性。
如图中所示的认证服务器（RediusServer）和AAAServer，保障用户访问的合法性，防火墙和服务器的口令甚至一次性口令系统等则保障着系统和数据的安全，有的系统还采用了数据加密和线路加密等手段。
*可管理性原则
服务器既是核心又是系统整体中的一个节点部分，就像网络系统需要进行管理维护一样，也需要对服务器进行有效的管理。
这需要服务器的软硬件对标准的管理系统支持，尤其是其上的操作系统，也包括一些重要的系统部件。
如ManagementStation，它既可以是基于B/S结构的专用管理软件系统，也可以是基于SNMP或WEB的通用管理方式的软件系统。
如何规划和选择数据库服务器?
举例说明，使用TPC-C进行数据库服务器评估
下面针对XYZ行的网上银行业务的需求，我们进行数据库服务器的选型分析。
由于目前XYZ行只有17个分行开通了网上银行业务，据我们估计，按照目前的客户数量，全部分行都开通网上银行业务后，总的客户数量可以达到10万。
考虑INTERNET在我国的迅猛发展，客户数量的年增长率按照50%计算，那么，3年后的客户数量将达到10万×（1+50%）3≈34万。
这些客户当中，至少有一半是个人客户，另一半是企业客户。
企业客户的交易频率比较高，我们按平均每个企业客户每天做1.5笔交易计算;个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易;那么，每天的交易量就是:
34万×50%×1.5+34万×50%×（4÷30）≈28万笔
假设网上银行的交易复杂度达到15，那么，每天的数据库操作数达到:
28万×15=420万次
高法诉讼费缴费:
由于诉讼费的增长量不大，我们按年递增率5%计算。
根据XYZ总行的统计，全国共37家分行，缴费量比较大的分行可以达到25000笔每月，占分行总数的20%;缴费量中等的省可达到15000笔每月，占分行总数的30%;缴费量小的省可达到7000笔每月，占分行总数的50%;按一个月20个工作日计算。
这样，三年后每天的交易数量可以达到:
（25000×20%+15000×30%+7000×50%）×37÷20×（1+5%）3≈28740笔
我们假设高法诉讼缴费的交易复杂度达到13，那么每天的数据库操作达到:
28740*13=373620次
整体性能要求:
总的数据库操作次数是:
4200000+373620=4573620
假设每天的交易的80%集中在4小时内发生，那么高峰交易时间内每分钟的数据库联机交易次数为:
4573620×80%÷（4×60）≈15250
要为将来陆续加入的应用预留40%的处理能力;另外，考虑到CPU的繁忙时间低于70%时，系统的性能较好，我们把这个比例定在65%。
所以系统的TPC-C值应达到:
15250÷（1-40%）÷65%≈39000
内存容量需求分析
首先根据数据库容量算出所需的数据库缓存大小，再估计出操作系统、系统软件等所需内存，合计即是所需的内存容量。
网银数据量分析:
XYZ总行网上银行系统的数据库由CIF信息，交易日志、交易流水三部分组成。
其中:
CIF信息包括企业客户和个人客户信息，企业客户信息平均大小为20K左右，个人客户信息平均大小为5K左右;每一笔交易都要记交易日志，日志的平均大小为4K左右;每一笔转帐交易都要记交易流水，交易流水的大小为2K左右。
这些客户当中，至少有一半是个人客户，另一半是企业客户。
企业客户的交易频率比较高，我们按平均每个企业客户每天做1.5笔交易计算;个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易;那么，每天的交易量就是:
所有的交易日志和交易流水都要保留三个月。
由于个人客户的转帐交易非常少，可以忽略不计;假定企业客户的转帐交易占总交易量的70%。
我们就可以计算网上银行对存储系统容量的要求:
CIF信息容量=20K×（34万×50%）+5K×（34万×50%）=3.25GB+421MB≈4GB
交易日志容量=[34万×50%×1.5+34万×50%×（4÷30）]×4K×30×3=277667×4K×30×3≈95GB
交易流水容量=（34万×50%×1.5）×70%×2K×30×3≈30GB
XYZ网上银行总体数据容量要求:
=4GB+95GB+30GB=129GB
高法诉讼费数据量分析:
高法的交易数据按要求要保留三年，每笔交易记录的大小为512字节，总体容量为:
（25000×20%+15000×30%+7000×50%）×37×12×3×0.5K≈8.2GB
因此，数据库的总数据量为:
129GB+8.2GB=137.2GB
数据库系统在缓存容量达到数据库总容量的5%时性能较好，因此，数据库缓存大小为:
6.86GB。
从而计算出系统内存需求为:
1.AIX操作系统所占的内存128MB
2.数据库管理系统所占的内存256MB
3.双机热备等系统软件所占的内存128MB
4.应用程序所占的内存256MB
5.数据库缓存6.86GB
6.合理的内存利用率75%
总计10GB
存储容量需求分析
除了上述的XYZ网上银行系统和高法诉讼费缴费系统的存储容量要求之外，还有异步查询下载服务的存储要求。
异步查询下载服务每隔1小时生成一个下载数据包，每个数据包的大小为3MB，需要下载的数据包是上午十点生成的数据包，这个数据包需要保存2年，其它数据包只要保存3个月。
因此，存储容量为:
23×3M×30×3+1×3M×365*2=6GB+2GB=8GB
为避免存储系统成为系统性能的瓶颈，系统存储系统的使用率应小于40%，建议采用镜像方式存储数据，因此总的存储容量为:
（137.2GB+8GB）÷40%×2=766GB
HP银行参考TPC-C测算
参考以下吧！
！
日峰值交易量，即每天业务高峰时的交易
升级会员 