天津市建设监理协会网站,app生成器手机版,一个主机 多个网站,建设积分兑换官方网站1 【引题】 但凡写过技术方案的都知道#xff0c;在技术方案最终落实到工程实施部署时#xff0c;必须编制出当前解决方案需要部署的IT设备及环境#xff0c;包括#xff1a;需要的网络环境、端口、带宽、组网方式、网络安全保障措施#xff1b;需配置的服务器设备性能…1 【引题】 但凡写过技术方案的都知道在技术方案最终落实到工程实施部署时必须编制出当前解决方案需要部署的IT设备及环境包括需要的网络环境、端口、带宽、组网方式、网络安全保障措施需配置的服务器设备性能、数量需配置的存储数据存储设备、容量、存储速率甚至还需考虑整个系统的备份设备容量、备份I/O数、速率、备份策略等。 严格说来无论是系统厂商、集成公司、还是研究院、设计公司在最终提供方案的硬件配置时都应该以业务需求为依据、适当考虑客户业务的发展趋势和系统冗余详细估算当前业务需求对网络带宽、对处理能力、对数据存储容量的指标。因此本文以自己的项目案例和经验为基础简述计算机处理能力如何正确估算供大家参考。 2 【性能评测标准】 众所周知事务处理性能委员会的TPC-C标准是测算和衡量计算机硬件设备性能的行业标准。随着B/S技术架构的大行其道SPEC组织专门推出了针对Web服务器响应客户端Web访问请求的性能测算标准即SPEC web系列。因此如果是传统的基于事务处理模式的服务器仍采用TPC-C的方式进行测算如果是Web服务器则需要采用SPEC web系列的标准进行测算。然而很遗憾的看到很多人在测算服务器性能时完全忽视这两种差别。 1.1 TPC-C标准 TPC-C基准是事务处理委员会建立的一个专门演示在线事务处理性能OLTP的性能基准它的测量方法是为了使客户能够评估不同的在线事务处理系统的性能这些事务进程于一个可控制的状态下在一个标准的数据库中运行。 TPC-C的事务处理是在一个9个表的数据库上实现的事务处理过程包括更新、插入、删除、终止以及对主和次级键的访问每种事务处理95%的响应时间应小于或等于5秒其中库存水平的响应时间可以在60秒以内。TPC-C值表示每分钟处理的标准事务量单位是tpmC。 1.2 SPEC web标准 SPEC web99WEB 服务器可以支持的并发接入数。SPECweb99 检测程序模拟客户通过慢Internet 连接向Web 服务器发送HTTP 工作量请求。 SPEC Web2005作为SPECweb99的继承者SPECweb2005延续了SPEC的传统测试的原理通过多台客户机向服务器发出Http Get请求请求调用Web服务器上的网页文件这些文件从数千字节到数兆字节不等。在相同的时间里服务器回答的请求越多就表明服务器对客户端的处理能力越强系统的Web性能就越好。 3 【性能估算公式】 3.1 常见的错误估算方法 在技术方案评审和招投标评标过程中我常常看到这样的评估服务器处理能力的表格 示例一 示例二 不知道这种评估方法是从那里开始的在技术方案文档中曾多次看到这样的评估模型和表格。即不全是TPC-C的评估方法又不全是SPEC Web体系的评估方法。 3.2 TPC-C估算公式 TPC-C是用计算机设备在每分钟内所能处理的标准事务的数量来衡量其处理能力的多少因此估算一个应用场景对处理能力的需求本质上就是估算出每类业务处理事务对应的标准tpc-c事务量然后在适当考虑冗余量。TPC-C的测算结果是每分钟的事务数单位是tpmc。 TPC-C的通用估算公式如下 TPC-C ∑(每分钟业务事务量 * 标准事务量比率)/ (1 — 冗余率)。 例如某业务系统有2类业务处理事务操作业务事务1每分钟30000个每个业务事务1操作相当于0.5个标准tpc-c事务务事务2每分钟20000个每个业务事务2操作相当于2个标准tpc-c事务考虑30%的系统冗余。则该业务应用需要的处理能力为 服务器处理能力(tpmc) ((30000 X0.5) (20000 X 2)) / (1 – 30%) 78581。 3.3 SPEC Web估算公式 SPEC Web2005标准的衡量结果是一台Web服务器能够有效响应客户端的Web请求的最大极限个数。因此测算的结果应该是一个Web请求数字单位是个。 在评估应用服务器的SPEC Web2005值时通常的方法是通过系统的在线用户结合其在线率估算出并发用户数在参照日常业务使用场景中可能发起的http请求来进行估算。 SPEC Web2005的参考估算公式如下(注意公式仅供参考需根据项目的具体情况自行设计估算模型) Web访问响应能力(SPEC Web2005) (在线用户数 * 在线率 * 在线用户平均发起http请求数)/ (1 — 冗余率)。 例如某业务系统的在线用户数为2000在线率10%每在线用户平均发起的http请求数为3考虑30%的系统响应能力冗余。则负责该业务请求的Web服务器的响应能力为 Web访问响应能力(个) 2000 * 10% * 3 / (1 – 30%) 857。 4 【应用实例】 下面以一个实际工程项目的应用服务器(部署Web Service中间件)的性能估算为例进行示范。 应用服务器上运行中间件产品承担系统的各类业务逻辑组件运行计算收敛系统用户对数据库服务器的访问请求集中对外提供应用服务。通过分析应用服务器性能需求在于提供Web应用服务、业务逻辑处理。 Web应用服务方面根据的业务预测数据应用服务器平均在线并发用户按200估算并发在线率20%每用户平均发起3个http链接考虑30%系统响应冗余能力参照SPECweb99的评测标准Web应用服务性能需求Web服务器最大并发连接数(120×20%×3)/(1 - 30%) 103。 业务逻辑处理性能方面主要的应用服务组件性能需求在于集团数据监测分析、省数据监测分析、业务数据查询。据调研统计集团数据为每分钟3585 条省数据平均为每分钟51667条业务信息查询请求平均为每分钟2151次集团数据监测分析每次业务操作约需3个标准tpcc事务省数据监测分析每次业务操作约需2个tpcc事务业务信息查询每次业务操作约需2个tpcc事务则系统主机的处理能力需求TPCC值计算如下 因此应用服务器的处理能力配置不能低于196731tpmc其Web2005配置指标不能低于103个。 5 【经验总结】 针对事务处理型应用场景需要采用TPC-C的估算方法估算出具体需要的总tpmc值而针对Web客户端请求响应型应用场景除了估算其业务处理能力之外还需要评估其对客户端Web请求的响应能力实际配置的服务器一般不能低于估算结果。 除了考虑存业务处理需要的处理能力需求外还需要考虑设备运行环境上其他基础服务运行开销例如操作系统、数据库服务器、Web服务器、应用中间件等。 由于当期硬件设备发展非常迅速一般标配的PC服务器的tpcc值也常常是几十万高配的甚至上百万。因此还有两条经验提醒大家注意 其一如果业务需求的tpcc值测算出来其实很低(绝大部分应用都是如此)配置一台很低端的PC服务器都能够满足处理能力需求不能因为想给客户提供高配置的设备而胡乱的编纂tpcc值而应该从其他方面寻找更加充分有力的理由。 其二、由于PC服务器处理能力的增强tpcc值往往不再成为必须选择小型机的一个比较充分的理由但需要给客户报配小型机方案时可以尝试从稳定性、可靠性、高I/O需求、设备同构需求、外围设备特殊要求等方面多想办法而不能再一味只从tpcc值这个角度去考虑。 引自http://blog.csdn.net/cxxsoft/article/details/7489116
