服务器TPMC值计算

根据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％。
　　＊ ASR1 GS160（1G HZ） 16CPU 的TPC－C值
　　推算如下：GS320 （1G HZ）32CPU 的测试值为230,000。因此，我们推算其
　　16CPU的TPC－C值=230,000÷70％÷2=164,285
　　＊ ASR2 GS80（1G HZ） 8CPU 的TPC－C值
　　推算如下：GS160 （1G HZ）16CPU 的估算值为164,285。因此，我们推算其8CPU的TPC－C值=164,285÷70％÷2=117,346
　　＊ ASR3 GS80（731G HZ） 4CPU 的TPC－C值
　　推算如下：GS160 （731M HZ）16CPU 的测试值为71,000。因此，我们推算其
　　8CPU的TPC－C值=71,000÷70％÷2=50,714
　　4CPU的TPC－C值=50,714÷70％÷2=36,224
　　同时，大家可以从康柏AlphaServer ES系列小型机的TPC－C值得到应证。 AlphaServer ES 4CPU，731MHZ的TPC－C值为37,274。
　　因此，我们可以得到以下结论：
　　＊ 康柏AlphaServerGS160 16CPU 1GHZ的TPC－C值为164,285左右。
　　＊ 康柏AlphaServerGS80 8CPU 1GHZ的TPC－C值为117,346左右。
　　＊ 康柏AlphaServerGS80 4CPU 731MHZ的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(Transaction Processing Council，事务处理委员会）成立于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(Standard Performane Evaluation Corporation，标准性能评估公司）是由30个左右世界知名计算机大厂商所支持的非盈利的合作组织，其成员包括IBM、AT&T、BULL、CDC、DG、DEC、富士通、HP、Intel、MIPS、摩托罗拉、SGI、SUN、Unisys等。SPEC能够全面反映机器的性能，具有很高的参考价值，当前主要的基准测试程序有SPEC int_base_rate 2000、SPEC fp_base_rate 2000和SPEC JBB 2000等。还有基于某种数据库运行环境下的测试，也是可以参考的数值。在采用通用基准测试程序时，要注意真实的业务流程和使用环境与通用测试基准的业务流程和使用环境的异同，这样，基准测试值才有参考价值。
 
　当前电信业已进入群雄并起、竞争极端激烈的战国时代，在话音、数据和各种增值服务等领域，国内各电信运营商，在高端和低端的不同层次上，展开了大规模的中原逐鹿。在如此复杂的局面下，在众多繁复的业务种类竞争中，如何保证一个电信企业的良好运作，建立一个顺畅的收入现金流至为重要。这也就是为什么电信企业在计费系统上进行了不遗余力的投资。但是，正是业务种类层出不穷的推出、通信模式和接入技术快速进步，使电信计费系统存在着难以满足需要的局面，往往制约了电信的运营和业务的开展。如何建立一套能够满足当前乃至今后一定时间的业务开展，又能够保证安全稳定易管理的电信综合计费系统，是各电信运营商和电信科研单位极为重视的一个课题。下面结合中国网通的计费系统建设经验，为即将建设的计费系统的服务器选型方面提供一些建议和参考。
电信计费系统架构
　　电信计费系统通常有如下种类的服务器：
　　* 接口服务器
　　* 认证服务器
　　* 计费服务器
　　* 采集服务器
　　* 数据库服务器
　　* 管理工作站等
　　其中，核心服务器为计费服务器、认证服务器和数据库服务器。在一些小型的计费系统中，接口服务器可以与采集服务器合一，计费服务器可以与认证服务器，甚至与数据库服务器合一，管理工作站也可以不设置专用工作站，而用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等实现技术。对于Redius Server可以依靠Redius协议采用双机互备，但不需要专门购买的集群软件。
　　* 安全性原则
　　服务器处理的大都是相关系统的核心数据，其上存放和运行着关键的交易和重要的数据。这些交易和数据对于拥有者来说是一笔重要的资产，他们的安全性就非常敏感。
　　服务器的安全性与系统的整体安全性密不可分，如：网络系统的安全、数据加密、密码体制等。　　服务器需要在其自身，包括软硬件，都应该从安全的角度上设计考虑，在借助于外界的安全设施保障下，更要保证本身的高安全性。
　　
　　如图中所示的认证服务器(Redius Server)和AAA Server，保障用户访问的合法性，防火墙和服务器的口令甚至一次性口令系统等则保障着系统和数据的安全，有的系统还采用了数据加密和线路加密等手段。
　　* 可管理性原则
　　服务器既是核心又是系统整体中的一个节点部分，就像网络系统需要进行管理维护一样，也需要对服务器进行有效的管理。这需要服务器的软硬件对标准的管理系统支持，尤其是其上的操作系统，也包括一些重要的系统部件。
　　如Management Station，它既可以是基于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测算
参考以下吧！！
日峰值交易量，即每天业务高峰时的交易量，根据经验以在2小时内完成日均交易量的80%为计算依据。 
        日峰值交易量 = 日均交易量×80% / 2
                     =  104000 （笔/小时）
月峰值日集中系数，即在每月的最忙日最忙时，其峰值交易量要高于根据上式计算出的平均日峰值交易量，为了使主机能够从容处理每月中的最高峰值交易量，在平均日峰值交易量的基础上考虑一个月峰值日集中系数，根据业务繁忙程度取值 1.5 ~ 3，根据###的具体情况，在这里取值1.5 。则:
                                104000×1.5
                                  3600     
                           =    43  （笔/秒）
根据软件的测试结果，软件软件交易处理能力与计算机厂商公布的TPmC值之间的比例关系为1：4 。由此，可得出###需主机系统的TPmC值：
主机系统的处理能力为：43 ×4×60 = 10320 TPmC
综合以上数值，####系统所需最大处理能力约为10320 TPmC 。
nightcat兄，谢了？我也得到一个数据如下：
跟据xx银行提供的数据，目前的业务量为：日均5万笔
日均交易量为5万笔.
设M为每日实际交易量，则M=50,000
设T为每日实际交易时间或实际统计值，我们假设高峰期每日交易量在每天的2小时即120分钟内完成：T=120
标准交易指标值TPC-C对应于实际交易值比例为：M0=15：1
应保证50%(M1)的主机CPU处理余量，用于系统、数据库、工具软件、监控软件或其它应用系统的使用
因此，对应计算得标准TPC-C估计值为：
TPC=M x M0/(T x M1)
=50000 x 15/ (120x50%)
=12500
还应考虑系统业务未来三年的发展，每年增长率按30%计算，得出 的TPC值为：
TPC=12500x 1.3 x 1.3 x 1.3=27462.5
那位还有不同见解，请发表!
1)根据什么得到的结论，是官方的吗？
标准交易指标值TPC-C对应于实际交易值比例为：M0=15：1
2)为什么日交易量/(交易完成时间*冗余)=tpmc，似乎没有这样的计算公式吧,不理解^_^




总之，计算tpmc的计算过程无法使人信服，如果我是客户，我是不能接受的
 
 
金保工程建设中服务器选型建议
 
李冰松
服务器系统作为劳动和社会保障各级数据中心的核心设备，提供计算处理服务、网络应用服务、劳动保障业务应用服务和其他服务。根据部省市局域网的逻辑构成，劳动保障信息系统的服务器设备包括数据库服务器、应用服务器、WEB服务器、DNS服务器等。服务器的配置应根据各级各类应用的不同规模和特点，并结合处理速度、存储容量、可靠性、系统开放性、性能价格比等因素来进行选择。
数据层服务器作为业务系统的核心，具有业务量大、存储量大等特点。它承担着业务数据的存储和处理任务，因此关键数据库服务器的选择就显得尤为重要。服务器的可靠性和可用性是首要的需求，其次是数据处理能力和安全性，然后是可扩展性和可管理性。为保证劳动保障信息系统持续稳定高效地运行，须保证服务器数据存储系统较高的可靠性、扩展性和灾难恢复能力。基于RISC系统的高中端服务器系统是适用于数据库服务器的选择，可根据具体业务需求和投资情况选择双机集群和单服务器系统。
应用层服务器承担着业务系统的各类应用服务，主要强调其强大的计算能力，能够处理大量的并发连接处理，并能在用户数增加的情况下保持良好的性能平衡。除此之外，能够提供连续可用的可靠性，能够适应各种网络环境的扩展能力也是需要考虑的因素。基于RISC系统的中低端服务器系统或高中端PC服务器系统是适合于应用层服务器的选择，可根据具体业务需求和投资情况选择双机集群和单服务器方案。
其他服务器，如WEB服务器、DNS服务器等，要根据具体应用和投资要求在可靠性和处理能力等方面综合考虑。可采用中低端PC服务器系统。
下面以省级数据中心交换区数据层服务器为例，详细阐述服务器选型的方法。
省级数据中心交换区数据层服务器中作为社会保险关系异地转移、离退休人员异地数据交换和异地就医数据交换的数据库服务器，支持在职人员社会保险关系跨市转移的信息交换，以及异地领取养老金相关信息（如人员的基本状况、支付标准、生存状况等）的交换，同时保存死亡信息和公共服务信息、临时缓存宏观决策上报数据和基金监管信息。考虑其作为中央、省、市三级数据中心信息交换的枢纽，所支撑应用的关键性，应采用基于RISC系统的高端服务器系统，具体配置要求如下：
服务器处理能力
为支持本省的异地转移、异地就医和异地领取养老金等业务，需要较高的交易数据处理能力。
TPC计算如下：
设：   全省参保总人数C=980万
     交易日平均交易人数比例a1=1‰
     每笔交易对应数据库事务数a2=5
则： 每日实际交易量M= C×a1×a2
     交易日集中交易时间T=120分钟
     交易日集中期内交易量比例Ct=80%
     基准TPC指标值对应实际交易值的比例M0=6:1
CPU处理能力余量M1=30%-45%，取35%
3年内每年处理能力增长率P=30%
根据经验公式TPC＝(M×M0×Ct/(T×(1-M1)) ×(1+30%)3=89,435
服务器选型考虑采用TPC值不低于100,000的高端服务器系统配置。
内存容量
根据经验和类似业务量和环境，内存容量应为1G/CPU×CPU数，从目前主流硬件厂商的指标来看，TPC值要达到100，000，一般需要配置8个CPU，因此内存建议配置8GB。
总线带宽
在高CPU、大容量内存的配置下，必须要求主机系统总线带宽、I/O总线带宽都达到很高，否则，系统性能将形成瓶颈。
存储容量
交换区平均数据量为164.8GB，峰值数据量为164.8GB×1.5，考虑0.2倍的数据库索引和系统占用空间；作RAID保护后60％存储利用率；以后数据增长，需提供30％的数据扩充能力等因素，总存储容量约为：164.8×1.5×1.2/60%/70%=706GB，采用SAN中的光纤通道阵列作为数据存储。
可靠性、扩展性等
由于作为生产型数据库服务器，支持异地经办业务，属于实时性服务，该服务器系统在可靠性方面要求较高，可靠性必须达到99.99%以上，提供全年7×24的可用性，配置为双机集群方式。系统采用多部件的冗余结构设计，具有高速差错校验和纠错的存储器，并有监控和诊断功能。
综上所述，对于在金保工程建设中服务器的选型，首先需对其业务系统的业务类型、业务复杂度等方面做系统的需求分析，其后根据需求在数据容量、数据处理的强度等方面进行估算，并兼顾服务器的可靠性、扩展性、安全性、可管理性等方面综合考虑，完成最终的产品选型。